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 ." 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 to a peer unless the BGP speaker advertises the ADD-PATH Capability to the peer indicating its ability to send multiple paths for the , and also receives the ADD-PATH Capability from the peer indicating its ability to receive multiple paths for the ..." 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 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 ." Does your implementation support the use of the ADD-PATH capability for multiple 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 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]