Internet DRAFT - draft-ietf-idr-add-paths-implementation
draft-ietf-idr-add-paths-implementation
Network Working Group A. Retana
Internet-Draft Cisco Systems, Inc.
Intended status: Informational February 2, 2015
Expires: August 6, 2015
Advertisement of Multiple Paths in BGP: Implementation Report
draft-ietf-idr-add-paths-implementation-00
Abstract
This document reports the results of an ADD-PATH implementation
survey. The survey had 22 questions about implementations' support
for advertising multiple paths in BGP. After a brief summary of the
results, each response is listed. This document contains responses
from six implementers who completed the survey.
The editor did not use external means to verify the accuracy of the
information submitted by the respondents. The respondents are
considered experts on the products they reported on.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 6, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Retana Expires August 6, 2015 [Page 1]
Internet-Draft ADD-PATH Implementation Report February 2015
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Results of the Survey . . . . . . . . . . . . . . . . . . . . 3
3.1. Overview of Differences . . . . . . . . . . . . . . . . . 3
3.2. Implementation Identification . . . . . . . . . . . . . . 4
3.3. Implementations and Interoperability . . . . . . . . . . 5
4. Implementation Report . . . . . . . . . . . . . . . . . . . . 5
4.1. Section 2: How to Identify a Path . . . . . . . . . . . . 6
4.1.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Path Identifier Assignment . . . . . . . . . . . . . 6
4.1.3. Path Identifier Assignment (2) . . . . . . . . . . . 6
4.1.4. Route Re-advertisement . . . . . . . . . . . . . . . 7
4.1.5. Received Path Identifier . . . . . . . . . . . . . . 7
4.2. Section 3: Extended NLRI Encodings . . . . . . . . . . . 8
4.2.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 8
4.3. Section 4: ADD-PATH Capability . . . . . . . . . . . . . 8
4.3.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 8
4.4. Section 5: Operation . . . . . . . . . . . . . . . . . . 9
4.4.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 9
4.4.2. Implicit Replacement . . . . . . . . . . . . . . . . 9
4.4.3. Silently Ignore . . . . . . . . . . . . . . . . . . . 9
4.4.4. Send/Receive Logic . . . . . . . . . . . . . . . . . 10
4.4.5. Update Procedure . . . . . . . . . . . . . . . . . . 10
4.4.6. Update Generation with Encoding . . . . . . . . . . . 11
4.4.7. Multiple Address Family Support . . . . . . . . . . . 11
4.4.8. Multiple Address Family Support (2) . . . . . . . . . 12
4.4.9. Bestpath . . . . . . . . . . . . . . . . . . . . . . 12
4.4.10. Path Identifier Persistency . . . . . . . . . . . . . 13
4.4.11. Graceful Restart . . . . . . . . . . . . . . . . . . 13
4.5. Section 6: Applications . . . . . . . . . . . . . . . . . 14
4.5.1. Applications . . . . . . . . . . . . . . . . . . . . 14
4.6. Section 7: Deployment Considerations . . . . . . . . . . 15
4.6.1. Deployment Experience . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
Retana Expires August 6, 2015 [Page 2]
Internet-Draft ADD-PATH Implementation Report February 2015
1. Introduction
This document reports results from a survey of implementations of the
Advertisement of Multiple Paths in BGP [I-D.ietf-idr-add-paths],
where a BGP [RFC4271] extension that allows the advertisement of
multiple paths for the same address prefix without the new paths
implicitly replacing any previous ones is defined. The essence of
the extension is that each path is identified by a path identifier in
addition to the address prefix.
The ADD-PATH implementation survey had 22 detailed questions about
compliance with [I-D.ietf-idr-add-paths]. Six implementers (Cumulus
Networks, Cisco Systems, Exa Networks, Juniper Networks, Alcatel-
Lucent and CZ.NIC) completed the survey. Section 3.1 provides an
overview of the differences between the implementations. Section 4
provides a compilation of the results.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Results of the Survey
The respondents replied "Yes" or "No" to the survey's questions to
indicate whether their implementation supports the Functionality/
Description of the [RFC2119] language in [I-D.ietf-idr-add-paths].
The respondents replied "Other" to indicate an alternate behavior and
had the opportunity to provide comments in all cases. Some questions
were informative.
3.1. Overview of Differences
This section provides the reader with a shortcut to the points where
the implementations differ.
Two of the implementations work only in receive-mode; they don't
implement any advertisement of routes. Obviously, those
implementations are not compliant with the sections related to the
advertisement of routes. Taking that fact into account, all the
responders had consistent and compliant answers to all the sections
of the survey.
Retana Expires August 6, 2015 [Page 3]
Internet-Draft ADD-PATH Implementation Report February 2015
3.2. Implementation Identification
3.3.1. Cumulus
Company/Organization Name: Cumulus Networks
Implementation Name/Version: quagga
Date: 11/3/2014
Contact Name: Daniel Walton
Contact e-mail: dwalton@cumulusnetworks.com
3.3.2. Cisco
Company/Organization Name: Cisco Systems
Implementation Name/Version: IOS-XE
Date: 11/03/2014
Contact Name: Mohammed Mirza
Contact e-mail: mohamirz@cisco.com
3.3.3. Exa
Company/Organization Name: Exa Networks
Implementation Name/Version: ExaBGP
Date: 01/11/2014
Contact Name: Thomas Mangin
Contact e-mail: thomas.mangin@exa-networks.co.uk
3.3.4. Juniper
Company/Organization Name: Juniper Networks
Implementation Name/Version: JUNOS 11.3 and later
Date: August 2011
Contact Name: Jeff Haas
Retana Expires August 6, 2015 [Page 4]
Internet-Draft ADD-PATH Implementation Report February 2015
Contact e-mail: jhaas@juniper.net
3.3.5. ALU
Company/Organization Name: Alcatel-Lucent
Implementation Name/Version: SROS
Date: 11/10/2014
Contact Name: Adam Simpson
Contact e-mail: adam.simpson@alcatel-lucent.com
3.3.6. CZ.NIC
Company/Organization Name: CZ.NIC
Implementation Name/Version: BIRD
Date: 2014-11-12
Contact Name: Ondrej Zajicek
Contact e-mail: santiago@crfreenet.org
3.3. Implementations and Interoperability
+---------+---------+-------+-----+---------+-----+--------+
| | Cumulus | Cisco | Exa | Juniper | ALU | CZ.NIC |
| Cumulus | | Yes | | | | Yes |
| Cisco | | Yes | | | | |
| Exa | | Yes | | | | |
| Juniper | | | | | | |
| ALU | | Yes | | | | |
| CZ.NIC | | | | | | |
+---------+---------+-------+-----+---------+-----+--------+
4. Implementation Report
For every item listed, the respondents indicated whether their
implementation supports the Functionality/Description or not (Yes/No)
according to the [RFC2119] language indicated. Any comments are
included. If appropriate, the respondents indicated with "Other" the
fact that the support is neither Yes/No (an alternate behavior, for
example). Refer to the appropriate sections in
[I-D.ietf-idr-add-paths] for additional details.
Retana Expires August 6, 2015 [Page 5]
Internet-Draft ADD-PATH Implementation Report February 2015
4.1. Section 2: How to Identify a Path
4.1.1. Base Behavior
Functionality/Description: Is your implementation compatible with the
use of the Path Identifier as described in this section?
[RFC2119]: N/A
Implementation Yes/No/Other Comments
-------------- ------------ --------
Cumulus Yes
Cisco Yes
Exa Yes
Juniper Yes
ALU Yes
CZ.NIC Yes
4.1.2. Path Identifier Assignment
Functionality/Description: Explain how Path Identifiers are assigned
in your implementation.
[RFC2119]: N/A
Implementation Comments
-------------- ------------------------------------------------------
Cumulus quagga is RX only for now so this is not an issue
Cisco Each net has unique path-id per paths under it. The
path ids that are withdrawn can get assigned to the
newer paths.
Exa By the user
Juniper Incrementally assign an id based on the N+1 of the
max(N) of the path ids already assigned.
ALU Path IDs are per address family. Every new advertised
path uses the next available path ID (in sequential
order) for the address family.
CZ.NIC Each route source (like add_path-unaware BGP peer) has
allocated fixed path id.
4.1.3. Path Identifier Assignment (2)
Functionality/Description: "...the Path Identifier MUST be assigned
in such a way that the BGP speaker is able to use the (prefix, path
identifier) to uniquely identify a path advertised to a neighbor."
Can your implementation uniquely identify an advertised path based on
the (prefix, path identifier) pair?
Retana Expires August 6, 2015 [Page 6]
Internet-Draft ADD-PATH Implementation Report February 2015
[RFC2119]: MUST
Implementation Yes/No/Other Comments
-------------- ------------ -----------------------------------------
Cumulus Yes
Cisco Yes
Exa Other This is left to the user of the
application to do.
Juniper Yes
ALU Yes
CZ.NIC Yes
4.1.4. Route Re-advertisement
Functionality/Description: "A BGP speaker that re-advertises a route
MUST generate its own Path Identifier to be associated with the re-
advertised route."
Does your implementation generate a new Path Identifier when re-
advertising a route?
[RFC2119]: MUST
Implementation Yes/No/Other Comments
-------------- ------------ -----------------------------------------
Cumulus Other Comments quagga does not support TX yet
Cisco Yes
Exa Other ExaBGP does not re-advertise routes
Juniper Yes
ALU Yes
CZ.NIC Other New path_id is allocated for each unique
path_id received through add_path-aware
BGP session.
4.1.5. Received Path Identifier
Functionality/Description: "A BGP speaker that receives a route
SHOULD NOT assume that the identifier carries any particular
semantics; it SHOULD be treated as an opaque value."
Does your implementation treat a received Path Identifier as an
opaque value?
[RFC2119]: SHOULD NOT
Retana Expires August 6, 2015 [Page 7]
Internet-Draft ADD-PATH Implementation Report February 2015
Implementation Yes/No/Other Comments
-------------- ------------ --------
Cumulus Yes
Cisco Yes
Exa Yes
Juniper Yes
ALU Yes
CZ.NIC Yes
4.2. Section 3: Extended NLRI Encodings
4.2.1. Base Behavior
Functionality/Description: Does your implementation use the encodings
specified in this section?
[RFC2119]: N/A
Implementation Yes/No/Other Comments
-------------- ------------ --------
Cumulus Yes
Cisco Yes
Exa Yes
Juniper Yes
ALU Yes
CZ.NIC Yes
4.3. Section 4: ADD-PATH Capability
4.3.1. Base Behavior
Functionality/Description: Is your implementation able to send and
receive the ADD-PATH Capability as described in this section?
[RFC2119]: N/A
Implementation Yes/No/Other Comments
-------------- ------------ --------
Cumulus Yes
Cisco Yes
Exa Yes
Juniper Yes
ALU Yes
CZ.NIC Yes
Retana Expires August 6, 2015 [Page 8]
Internet-Draft ADD-PATH Implementation Report February 2015
4.4. Section 5: Operation
4.4.1. Base Behavior
Functionality/Description: Is your implementation compatible with the
operation described in this section?
[RFC2119]: N/A
Implementation Yes/No/Other Comments
-------------- ------------ --------------------------
Cumulus Other RX yes, TX not implemented
Cisco Yes
Exa Yes
Juniper Yes
ALU Yes
CZ.NIC Yes
4.4.2. Implicit Replacement
Functionality/Description: "...a new advertisement for a given
address prefix and a given path identifier replaces a previous
advertisement for the same address prefix and path identifier."
Does your implementation replace previous advertisements with the
same (prefix, path identifier) pair?
[RFC2119]: N/A
Implementation Yes/No/Other Comments
-------------- ------------ -------------------------------
Cumulus Yes
Cisco Yes
Exa Other ExaBGP does not implement a FIB
Juniper Yes
ALU Yes
CZ.NIC Yes
4.4.3. Silently Ignore
Functionality/Description: "If a BGP speaker receives a message to
withdraw a prefix with a path identifier not seen before, it SHOULD
silently ignore it."
Does your implementation silently ignore the withdraw of a prefix
with a new path identifier?
[RFC2119]: SHOULD
Retana Expires August 6, 2015 [Page 9]
Internet-Draft ADD-PATH Implementation Report February 2015
Implementation Yes/No/Other Comments
-------------- ------------ -----------------------------------------
Cumulus
Cisco Yes
Exa Other ExaBGP is a "BGP engine", it only convert
BGP packet to some JSON that another
application can consume ( and vice-versa
).
Juniper Yes
ALU Yes
CZ.NIC
4.4.4. Send/Receive Logic
Functionality/Description: "For a BGP speaker to be able to send
multiple paths to its peer, that BGP speaker MUST advertise the ADD-
PATH capability with the Send/Receive field set to either 2 or 3, and
MUST receive from its peer the ADD-PATH capability with the Send/
Receive field set to either 1 or 3, for the corresponding <AFI,
SAFI>."
Does your implementation follow the send/receive logic as specified
in this section?
[RFC2119]: MUST
Implementation Yes/No/Other Comments
-------------- ------------ --------
Cumulus Yes
Cisco Yes
Exa Yes
Juniper Yes
ALU Yes
CZ.NIC Yes
4.4.5. Update Procedure
Functionality/Description: "A BGP speaker MUST follow the existing
procedures in generating an UPDATE message for a particular <AFI,
SAFI> to a peer unless the BGP speaker advertises the ADD-PATH
Capability to the peer indicating its ability to send multiple paths
for the <AFI, SAFI>, and also receives the ADD-PATH Capability from
the peer indicating its ability to receive multiple paths for the
<AFI, SAFI>..."
Does your implementation follow normal procedures when generating
UPDATES if the ADD-PATH capability is not sent and received?
Retana Expires August 6, 2015 [Page 10]
Internet-Draft ADD-PATH Implementation Report February 2015
[RFC2119]: MUST
Implementation Yes/No/Other Comments
-------------- ------------ --------
Cumulus Yes
Cisco Yes
Exa Yes
Juniper Yes
ALU Yes
CZ.NIC Yes
4.4.6. Update Generation with Encoding
Functionality/Description: "...in which case the speaker MUST
generate a route update for the <AFI, SAFI> based on the combination
of the address prefix and the Path Identifier, and use the extended
NLRI encodings specified in this document."
If the ADD-PATH capability has been sent and received, does your
implementation generate new UPDATEs using the (prefix, path
identifier) pair and the encodings defined in this document?
[RFC2119]: MUST
Implementation Yes/No/Other Comments
-------------- ------------ -----------------------
Cumulus Other TX is not supported yet
Cisco Yes
Exa Yes
Juniper Yes
ALU Yes
CZ.NIC Yes
4.4.7. Multiple Address Family Support
Functionality/Description: "The peer SHALL act accordingly in
processing an UPDATE message related to a particular <AFI, SAFI>."
Does your implementation support the use of the ADD-PATH capability
for multiple <AFI, SAFI> pairs?
[RFC2119]: SHALL
Retana Expires August 6, 2015 [Page 11]
Internet-Draft ADD-PATH Implementation Report February 2015
Implementation Yes/No/Other Comments
-------------- ------------ -----------------------------------------
Cumulus Yes
Cisco Yes
Exa Yes
Juniper Yes
ALU Yes
CZ.NIC Other BIRD currently does not support multiple
pairs in one connection, separate
connection is used for IPv4 and IPv6
(unicast).
4.4.8. Multiple Address Family Support (2)
Functionality/Description: Which <AFI, SAFI> pairs does your
implementation support when using the ADD-PATH capability?
[RFC2119]: N/A
Implementation Comments
-------------- ------------------------------------------------------
Cumulus IPv4 unicast and IPv6 unicast
Cisco ipv4 unicast and ipv6 unicast
Exa 1/1 2/1 1/4 2/4
Juniper IPv4 Unicast, IPv6 Unicast, IPv4 Labeled Unicast, IPv6
Labeled Unicast
ALU 1/1, 1/4, 1/128, 2/1, 2/4, 2/128
CZ.NIC IPv4 unicast and IPv6 unicast
4.4.9. Bestpath
Functionality/Description: "A BGP speaker SHOULD include the bestpath
when more than one path are advertised to a neighbor unless the
bestpath is a path received from that neighbor."
Does your implementation include the bestpath when multiple paths are
announced to a neighbor, as described?
[RFC2119]: SHOULD
Retana Expires August 6, 2015 [Page 12]
Internet-Draft ADD-PATH Implementation Report February 2015
Implementation Yes/No/Other Comments
-------------- ------------ -----------------------------------------
Cumulus Yes
Cisco Yes
Exa Other ExaBGP does not have a FIB, this is user
controlled.
Juniper Yes
ALU Yes
CZ.NIC Yes
4.4.10. Path Identifier Persistency
Functionality/Description: "As the Path Identifiers are locally
assigned, and may or may not be persistent across a control plane
restart of a BGP speaker..."
Are the path identifiers persistent across control plane restarts in
your implementation?
[RFC2119]: N/A
Implementation Yes/No/Other Comments
-------------- ------------ -----------------------------------------
Cumulus No
Cisco No XE-BGP-ADD-Paths need to have HA
enhancements
Exa Other User controlled
Juniper Other In the case of the BGP graceful restart
feature, path IDs are not persistent. In
the case of the JUNOS Non-stop Routing
feature, they persist.
ALU No With high availability (HA) the path IDs
are persistent if there is still one
remaining control card after
reset/failure of the other control card.
CZ.NIC No
4.4.11. Graceful Restart
Functionality/Description: "...an implementation SHOULD take special
care so that the underlying forwarding plane of a "Receiving Speaker"
as described in [RFC4724] is not affected during the graceful restart
of a BGP session."
Please explain how your implementation addresses Graceful Restart.
[RFC2119]: SHOULD
Retana Expires August 6, 2015 [Page 13]
Internet-Draft ADD-PATH Implementation Report February 2015
Implementation Comments
-------------- ------------------------------------------------------
Cumulus Quagga has partial GR support (it is GR aware for
other restarting nodes) but does not maintain the
forwarding plane during a restart.
Cisco XE-BGP-ADD-Paths need to have HA enhancements
Exa No FIB, not relevant
Juniper During BGP graceful restart procedures, the receiving
speaker ignores the path-id for purposes of
identifying a matching route. Once a refreshed route
has been correlated to a previous path, the path-id is
updated.
ALU Graceful restart is supported for the receiving router
role so by definition graceful restart does not affect
the forwarding plane.
CZ.NIC FIB is not modified until initial graceful restart
phase is finished.
4.5. Section 6: Applications
4.5.1. Applications
Functionality/Description: Please list or explain which applications
that require the propagation of multiple paths are supported by your
implementation.
[RFC2119]: N/A
Implementation Comments
-------------- ------------------------------------------------------
Cumulus None yet....RX onlys
Cisco 1. RR client to RR use cases for ipv4 and ipv6. 2. RR
to RR clients(could be ASBRs) use cases for ipv4 and
ipv6.
Exa N/A
Juniper Persistent route flap damping suppression.
Distribution of additional destinations or BGP
nexthops for multi-path purposes.
ALU Add-Paths ion IBGP sessions allows for better load-
sharing (more ECMP paths), advertisement of potential
backup paths, reduced routing churn.
CZ.NIC (iBGP) route reflector / RR client, (eBGP) route
server / RS client, use cases where paths are
distributed for other purposes than filling FIBs (like
topology-aware CDNs).
Retana Expires August 6, 2015 [Page 14]
Internet-Draft ADD-PATH Implementation Report February 2015
4.6. Section 7: Deployment Considerations
4.6.1. Deployment Experience
Functionality/Description: Please comment on deployment experience
with your implementation.
[RFC2119]: N/A
Implementation Comments
-------------- ------------------------------------------------------
Cumulus
Cisco
Exa Cisco routers exporting ADD-PATH routes to ExaBGP,
routes are then stored in a distributed Database. A
complex best path selection (including latency) is
performed on the stored routes, and the best routes
are then re-injected in the core via ExaBGP.
Juniper
ALU
CZ.NIC
5. Security Considerations
This document reports the results of an ADD-PATH implementation
survey. As such, it does not iintroduce any security risks.
6. IANA Considerations
This document has no IANA actions.
7. Acknowledgements
The editor would like to thank Daniel Walton, Mohammed Mirza, Thomas
Mangin, Jeff Haas, Adam Simpson and Ondrej Zajicek.
8. References
8.1. Normative References
[I-D.ietf-idr-add-paths]
Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", draft-ietf-idr-
add-paths-10 (work in progress), October 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Retana Expires August 6, 2015 [Page 15]
Internet-Draft ADD-PATH Implementation Report February 2015
8.2. Informative References
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
Author's Address
Alvaro Retana
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
Email: aretana@cisco.com
Retana Expires August 6, 2015 [Page 16]
