Network Working Group A. Retana
Internet-Draft Cisco Systems, Inc.
Intended status: Informational November 10, 2014
Expires: May 14, 2015
Advertisement of Multiple Paths in BGP: Implementation Report
draft-retana-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 three implementers who completed the survey (Cumulus Networks,
Cisco Systems and Exa Networks).
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 May 14, 2015.
Copyright Notice
Copyright (c) 2014 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
Retana Expires May 14, 2015 [Page 1]
Internet-Draft ADD-PATH Implementation Report November 2014
carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . 5
4.1.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Path Identifier Assignment . . . . . . . . . . . . . 5
4.1.3. Path Identifier Assignment (2) . . . . . . . . . . . 6
4.1.4. Route Re-advertisement . . . . . . . . . . . . . . . 6
4.1.5. Received Path Identifier . . . . . . . . . . . . . . 7
4.2. Section 3: Extended NLRI Encodings . . . . . . . . . . . 7
4.2.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 7
4.3. Section 4: ADD-PATH Capability . . . . . . . . . . . . . 7
4.3.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 7
4.4. Section 5: Operation . . . . . . . . . . . . . . . . . . 8
4.4.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 8
4.4.2. Implicit Replacement . . . . . . . . . . . . . . . . 8
4.4.3. Silently Ignore . . . . . . . . . . . . . . . . . . . 8
4.4.4. Send/Receive Logic . . . . . . . . . . . . . . . . . 9
4.4.5. Update Procedure . . . . . . . . . . . . . . . . . . 9
4.4.6. Update Generation with Encoding . . . . . . . . . . . 9
4.4.7. Multiple Address Family Support . . . . . . . . . . . 10
4.4.8. Multiple Address Family Support (2) . . . . . . . . . 10
4.4.9. Bestpath . . . . . . . . . . . . . . . . . . . . . . 10
4.4.10. Path Identifier Persistency . . . . . . . . . . . . . 11
4.4.11. Graceful Restart . . . . . . . . . . . . . . . . . . 11
4.5. Section 6: Applications . . . . . . . . . . . . . . . . . 12
4.5.1. Applications . . . . . . . . . . . . . . . . . . . . 12
4.6. Section 7: Deployment Considerations . . . . . . . . . . 12
4.6.1. Deployment Experience . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
Retana Expires May 14, 2015 [Page 2]
Internet-Draft ADD-PATH Implementation Report November 2014
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]. Three implementers
(Cumulus Networks, Cisco Systems and Exa Networks) completed the
survey. Section 4 provides a compilation of the results.
Section 3.1 provides an overview of the differences between the
implementations. Section 3.3 provides interoperability information.
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.
The following questions were not answered "Yes" by all respondents
(Note that the question numbers correspond to the subsection numbers
of Section 4):
MUST
4.1.3, 4.1.4, 4.4.6
Question 4.1.3 asks about the ability of the implementation to
uniquely identify a path. This question is linked to 4.1.2 in which
the mechanism used to assigned Path Identifiers is explained. The
Retana Expires May 14, 2015 [Page 3]
Internet-Draft ADD-PATH Implementation Report November 2014
vendor that did not answer "Yes" to 4.1.3 lets the user assign Path
Identifiers; the response to 4.1.3 was "Other: This is left to the
user of the application to do."
Question 4.1.4 asks about the generation of Path Identifiers when re-
advertising a route. All responded chose "Other" -- I believe that
there was some misinterpretation on the intent of re-advertisement.
Question 4.4.6 asks about using the encoding defined when generating
an Update. One vendor replied "Other"; in their case, transmitting
Updates hasn't been implemented.
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
Retana Expires May 14, 2015 [Page 4]
Internet-Draft ADD-PATH Implementation Report November 2014
Contact e-mail: thomas.mangin@exa-networks.co.uk
3.3. Implementations and Interoperability
+---------+---------+-------+-----+-------+
| | Cumulus | Cisco | Exa | Other |
| Cumulus | | Yes | | Bird |
| Cisco | | Yes | | |
| Exa | | Yes | | |
+---------+---------+-------+-----+-------+
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 respondent
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.
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
4.1.2. Path Identifier Assignment
Functionality/Description: Explain how Path Identifiers are assigned
in your implementation.
[RFC2119]: N/A
Retana Expires May 14, 2015 [Page 5]
Internet-Draft ADD-PATH Implementation Report November 2014
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
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?
[RFC2119]: MUST
Implementation Yes/No/Other Comments
-------------- ------------ -----------------------------------------
Cumulus Yes
Cisco Yes
Exa Other This is left to the user of the
application to do.
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 Other Once a BGP speaker advertises a path-id
it has to also withdraw it. In case it
has to readvertise, it either updates the
older path-id path or creates a new path
with a new unique id.
Exa Other ExaBGP does not re-advertise routes
Retana Expires May 14, 2015 [Page 6]
Internet-Draft ADD-PATH Implementation Report November 2014
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
Implementation Yes/No/Other Comments
-------------- ------------ --------
Cumulus Yes
Cisco Yes
Exa 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
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
Retana Expires May 14, 2015 [Page 7]
Internet-Draft ADD-PATH Implementation Report November 2014
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
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
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
Implementation Yes/No/Other Comments
-------------- ------------ --------
Cumulus
Cisco
Exa
Retana Expires May 14, 2015 [Page 8]
Internet-Draft ADD-PATH Implementation Report November 2014
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
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?
[RFC2119]: MUST
Implementation Yes/No/Other Comments
-------------- ------------ --------
Cumulus Yes
Cisco Yes
Exa 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."
Retana Expires May 14, 2015 [Page 9]
Internet-Draft ADD-PATH Implementation Report November 2014
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
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
Implementation Yes/No/Other Comments
-------------- ------------ --------
Cumulus Yes
Cisco Yes
Exa Yes
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
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."
Retana Expires May 14, 2015 [Page 10]
Internet-Draft ADD-PATH Implementation Report November 2014
Does your implementation include the bestpath when multiple paths are
announced to a neighbor, as described?
[RFC2119]: SHOULD
Implementation Yes/No/Other Comments
-------------- ------------ -----------------------------------------
Cumulus Yes
Cisco Yes
Exa Other ExaBGP does not have a FIB, this is user
controlled.
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
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
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
Retana Expires May 14, 2015 [Page 11]
Internet-Draft ADD-PATH Implementation Report November 2014
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
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.
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.
Retana Expires May 14, 2015 [Page 12]
Internet-Draft ADD-PATH Implementation Report November 2014
7. Acknowledgements
The editor would like to thank Daniel Walton, Mohammed Mirza and
Thomas Mangin.
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.
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 May 14, 2015 [Page 13]