Network Working Group K. Patel Internet-Draft A. Lindem Intended status: Standards Track Cisco Systems Expires: September 19, 2016 March 18, 2016 Selective Advertisement of Multiple Paths within BGP draft-keyupate-idr-bgp-selective-add-paths-00.txt Abstract Originally, a BGP speaker was only allowed to advertise one path to any given address prefix. If the BGP speaker advertised a second path to a given prefix, the second path was considered to be a replacement for the first. The BGP ADD-PATH capability was defined to enable a BGP speaker to advertise multiple paths to a given address prefix, without one path replacing any of the others. However, whether a BGP speaker advertises multiple paths for any given prefix is always a matter of local policy for that BGP speaker. In certain situations, it is desirable to allow a BGP speaker to signal to its peers that the peers may advertise multiple simultaneous paths for certain prefixes but not for others. This document defines a new BGP capability, the Selective ADD-PATH capability, that allows a BGP speaker to signal to its peers whether a particular prefix is or is not eligible to have multiple paths advertised. 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 September 19, 2016. Patel & Lindem Expires September 19, 2016 [Page 1] Internet-Draft BGP Add-Path Selective Advertisement March 2016 Copyright Notice Copyright (c) 2016 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 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Selective ADD-PATH Capability . . . . . . . . . . . . . . . . 4 3. Selective ADD-PATH Extended Community . . . . . . . . . . . . 5 4. Selective Add-Path Use Case . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informational References . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction [I-D.ietf-idr-add-paths] defines a BGP extension, ADD-PATH, that allows a BGP speaker to advertise multiple simultaneous paths for the same address prefix. Without this extension, only one path at a time can be advertised; if a BGP speaker advertises a second path for a Patel & Lindem Expires September 19, 2016 [Page 2] Internet-Draft BGP Add-Path Selective Advertisement March 2016 given prefix, that path is considered to be replacement for the previously advertised path. Sometimes it would desirable for a BGP speaker to be able to signal to its peers that the peers may advertise multiple simultaneous paths for certain prefixes but not for others. This document specifies a mechanism by which a BGP speaker can perform this signaling. A new BGP Extended Community ([RFC4360], [RFC7153]), known as the Selective ADD-PATH Extended Community is defined. A BGP speaker can signal that a particular prefix is eligible to have multiple simultaneous paths advertised by adding this Extended Community to its own advertisements of the paths to that prefix. This draft also defines a new BGP Capability, the Selective ADD-PATH Capability. As an example of the use of Selective ADD-PATH, consider the topology of Figure 1. +----+ P1--> | R1 | P2--> +----+ \ +----+ +----+ -- | RR | -- | R3 | +----+ / +----+ +----+ P1--> | R2 | P2--> +----+ Figure 1: Selective ADD-PATH Example Suppose that RR is a route reflector that doesn't change the nexthops of the prefixes that it reflects. Let R1, R2 and R3 be clients of RR. Suppose R1 sends RR an UPDATE: and . Suppose R2 sends RR an UPDATE: and . Also suppose that it is desired to advertise multiple paths for P1, but not for P2. This can be achieved using Selective ADD-PATHS, as follows. First, all three BGP sessions (R1-RR, R2-RR, and R3-rr) will negotiate both the ADD-PATH Capability and the Selective ADD-PATH Capability. When R1 and R2 originate their advertisements for prefix P1, they will attach the Selective ADD-PATH Extended Community. But when R1 and R2 originate their advertisements for prefix P2, they will not attach the Selective ADD-PATH Extended Community. Patel & Lindem Expires September 19, 2016 [Page 3] Internet-Draft BGP Add-Path Selective Advertisement March 2016 As a result, RR will know that when advertising NLRI to R3, it may advertise multiple simultaneous paths to P1, but that it may advertise only a single path to P2. This mechanism does not require the RR to advertise all the paths to P1; the actual number of paths advertised is a matter of local policy at RR. 1.1. 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 RFC 2119 [RFC2119]. 2. Selective ADD-PATH Capability The Selective ADD-PATH Capability is a new BGP Capability [RFC5492], whose code point is to be allocated by IANA. The Capability Length field of this capability is variable. The Capability Value field consists of one or more of the following tuples: +------------------------------------------------+ | Address Family Identifier (2 octets) | +------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +------------------------------------------------+ The meaning and use of the fields are as follows: Address Family Identifier (AFI): This field is the same as the one used in [RFC4760]. Subsequent Address Family Identifier (SAFI): This field is the same as the one used in [RFC4760]. A BGP Speaker that wishes to announce or receive multiple simultaneous paths for any prefix MUST exchange the ADD-PATH Capability defined in [I-D.ietf-idr-add-paths]. A BGP Speaker that wishes to signal that only certain prefixes are eligible to have multiple simultaneous paths, MUST additionally exchange the Selective ADD-PATH Capability defined in this draft. The Capability Value field MUST specify the AFI/SAFI of the prefixes in question. Patel & Lindem Expires September 19, 2016 [Page 4] Internet-Draft BGP Add-Path Selective Advertisement March 2016 If a particular AFI/SAFI is not listed in the Capability value field, the procedures in this document MUST NOT be applied to prefixes of that AFI/SAFI. However, note that since the ADD-PATH Capability has also been exchanged, every UPDATE will still contain an NLRI containing a "path identifier", as specified in [I-D.ietf-idr-add-paths]. When processing a received Selective ADD-PATH Capability on a particular BGP session, a BGP speaker MUST ensure that it has already received the ADD-PATH Capability defined in [I-D.ietf-idr-add-paths] on that session. Otherwise, the BGP speaker MUST treat the received Selective ADD-PATH Capability as an unsupported Capability, and follow the error handling rules for unsupported Capabilities in [RFC5492]. 3. Selective ADD-PATH Extended Community We define a new Transitive Opaque Extended Community ([RFC4360], [RFC7153]) known as the Selective ADD-PATH Extended Community. The sub-type code point for this Extended Community will be assigned by IANA. If Selective ADD-PATH Capability negotiation for a given AFI/SAFI has not taken place, but the Selective ADD-PATH Extended Community is included with a prefix of that AFI/SAFI, the Selective ADD-PATH Extended Community will be ignored. However, the occurrence of the unexpected Extended Community SHOULD be logged. Also, the Extended Community SHOULD NOT be stripped from the path, but rather SHOULD be propagated along with the path. Upon successful Selective ADD-PATH Capability negotiation for a particular AFI/SAFI, a BGP speaker MUST NOT announce multiple paths for any prefix of that AFI/SAFI unless at least one of the following conditions holds: o It has at least one received UPDATE for that prefix that includes the Selective ADD-PATH Extended Community in its attributes. o It is the originator of an UPDATE for that prefix, and it has been configured to attach the Selective ADD-PATH Extended Community to that UPDATE. If at some later time, these conditions no longer hold for a given prefix, the BGP speaker MUST withdraw all but the best path for that prefix. It is to be expected that if a BGP speaker has received multiple paths for a given prefix, either all the paths will have the Patel & Lindem Expires September 19, 2016 [Page 5] Internet-Draft BGP Add-Path Selective Advertisement March 2016 Selective ADD-PATH Extended Community or none of them will. However, the rules above require the Selective ADD-PATH procedures to be applied to that prefix if even one received path for that prefix has the Selective ADD-PATH Extended Community. 4. Selective Add-Path Use Case A use case is a BGP deployment where underlay and overlay routes are associated with the same AFI/SAFI and, for scaling reasons, it is desired that multiple paths are advertised and installed only for the underlay routes. For direct BGP sessions, the ingress routers would only advertise multiple paths for the underlay routes. However, if the topology includes BGP Router Reflectors [RFC4456], it is likely that multiple ingress routers will advertise the same overlay routes. In this case, the mechanism describe herein would be useful in limiting multi-path best-path computation and advertisement to the underlay routes. 5. IANA Considerations This document defines a new Capability for BGP, the "Selective ADD- PATH" Capability. We request IANA to assign a code point for this Capability from "First Come, First Served" range of the BGP "Capability Codes" registry at http://www.iana.org/assignments/ capability-codes/capability-codes.xhtml. This document should be the reference. This document also defines a new Extended Community for BGP, the Selective ADD-PATH Extended Community. We request IANA to assign a code point for this community from the "First Come, First Served" range of the "Transitive Opaque Extended Communities Sub-Type" registry at http://www.iana.org/assignments/bgp-extended-communities/ bgp-extended-communities.xhtml. This document should be the reference. 6. Security Considerations This extension to BGP does not change the underlying security issues inherent in the existing [RFC4724] and [RFC4271]. 6.1. Acknowledgements The authors would like to thank Eric Rosen for his review and comments. Patel & Lindem Expires September 19, 2016 [Page 6] Internet-Draft BGP Add-Path Selective Advertisement March 2016 7. References 7.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-13 (work in progress), December 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, . 7.2. Informational References [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, . [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, . Authors' Addresses Patel & Lindem Expires September 19, 2016 [Page 7] Internet-Draft BGP Add-Path Selective Advertisement March 2016 Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: keyupate@cisco.com Acee Lindem Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: acee@cisco.com Patel & Lindem Expires September 19, 2016 [Page 8]