idnits 2.17.00 (12 Aug 2021) /tmp/idnits17052/draft-keyupate-idr-bgp-selective-add-paths-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 18, 2016) is 2255 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4760' is mentioned on line 175, but not defined == Outdated reference: draft-ietf-idr-add-paths has been published as RFC 7911 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Patel 3 Internet-Draft A. Lindem 4 Intended status: Standards Track Cisco Systems 5 Expires: September 19, 2016 March 18, 2016 7 Selective Advertisement of Multiple Paths within BGP 8 draft-keyupate-idr-bgp-selective-add-paths-00.txt 10 Abstract 12 Originally, a BGP speaker was only allowed to advertise one path to 13 any given address prefix. If the BGP speaker advertised a second 14 path to a given prefix, the second path was considered to be a 15 replacement for the first. The BGP ADD-PATH capability was defined 16 to enable a BGP speaker to advertise multiple paths to a given 17 address prefix, without one path replacing any of the others. 18 However, whether a BGP speaker advertises multiple paths for any 19 given prefix is always a matter of local policy for that BGP speaker. 20 In certain situations, it is desirable to allow a BGP speaker to 21 signal to its peers that the peers may advertise multiple 22 simultaneous paths for certain prefixes but not for others. This 23 document defines a new BGP capability, the Selective ADD-PATH 24 capability, that allows a BGP speaker to signal to its peers whether 25 a particular prefix is or is not eligible to have multiple paths 26 advertised. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 19, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 76 2. Selective ADD-PATH Capability . . . . . . . . . . . . . . . . 4 77 3. Selective ADD-PATH Extended Community . . . . . . . . . . . . 5 78 4. Selective Add-Path Use Case . . . . . . . . . . . . . . . . . 6 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 81 6.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . 6 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 84 7.2. Informational References . . . . . . . . . . . . . . . . 7 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 87 1. Introduction 89 [I-D.ietf-idr-add-paths] defines a BGP extension, ADD-PATH, that 90 allows a BGP speaker to advertise multiple simultaneous paths for the 91 same address prefix. Without this extension, only one path at a time 92 can be advertised; if a BGP speaker advertises a second path for a 93 given prefix, that path is considered to be replacement for the 94 previously advertised path. 96 Sometimes it would desirable for a BGP speaker to be able to signal 97 to its peers that the peers may advertise multiple simultaneous paths 98 for certain prefixes but not for others. This document specifies a 99 mechanism by which a BGP speaker can perform this signaling. A new 100 BGP Extended Community ([RFC4360], [RFC7153]), known as the Selective 101 ADD-PATH Extended Community is defined. A BGP speaker can signal 102 that a particular prefix is eligible to have multiple simultaneous 103 paths advertised by adding this Extended Community to its own 104 advertisements of the paths to that prefix. 106 This draft also defines a new BGP Capability, the Selective ADD-PATH 107 Capability. 109 As an example of the use of Selective ADD-PATH, consider the topology 110 of Figure 1. 112 +----+ 113 P1--> | R1 | 114 P2--> +----+ \ +----+ +----+ 115 -- | RR | -- | R3 | 116 +----+ / +----+ +----+ 117 P1--> | R2 | 118 P2--> +----+ 120 Figure 1: Selective ADD-PATH Example 122 Suppose that RR is a route reflector that doesn't change the nexthops 123 of the prefixes that it reflects. Let R1, R2 and R3 be clients of 124 RR. 126 Suppose R1 sends RR an UPDATE: and . 127 Suppose R2 sends RR an UPDATE: and . 128 Also suppose that it is desired to advertise multiple paths for P1, 129 but not for P2. 131 This can be achieved using Selective ADD-PATHS, as follows. First, 132 all three BGP sessions (R1-RR, R2-RR, and R3-rr) will negotiate both 133 the ADD-PATH Capability and the Selective ADD-PATH Capability. 135 When R1 and R2 originate their advertisements for prefix P1, they 136 will attach the Selective ADD-PATH Extended Community. But when R1 137 and R2 originate their advertisements for prefix P2, they will not 138 attach the Selective ADD-PATH Extended Community. 140 As a result, RR will know that when advertising NLRI to R3, it may 141 advertise multiple simultaneous paths to P1, but that it may 142 advertise only a single path to P2. 144 This mechanism does not require the RR to advertise all the paths to 145 P1; the actual number of paths advertised is a matter of local policy 146 at RR. 148 1.1. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 2. Selective ADD-PATH Capability 156 The Selective ADD-PATH Capability is a new BGP Capability [RFC5492], 157 whose code point is to be allocated by IANA. The Capability Length 158 field of this capability is variable. The Capability Value field 159 consists of one or more of the following tuples: 161 +------------------------------------------------+ 162 | Address Family Identifier (2 octets) | 163 +------------------------------------------------+ 164 | Subsequent Address Family Identifier (1 octet) | 165 +------------------------------------------------+ 167 The meaning and use of the fields are as follows: 169 Address Family Identifier (AFI): 171 This field is the same as the one used in [RFC4760]. 173 Subsequent Address Family Identifier (SAFI): 175 This field is the same as the one used in [RFC4760]. 177 A BGP Speaker that wishes to announce or receive multiple 178 simultaneous paths for any prefix MUST exchange the ADD-PATH 179 Capability defined in [I-D.ietf-idr-add-paths]. A BGP Speaker that 180 wishes to signal that only certain prefixes are eligible to have 181 multiple simultaneous paths, MUST additionally exchange the Selective 182 ADD-PATH Capability defined in this draft. The Capability Value 183 field MUST specify the AFI/SAFI of the prefixes in question. 185 If a particular AFI/SAFI is not listed in the Capability value field, 186 the procedures in this document MUST NOT be applied to prefixes of 187 that AFI/SAFI. However, note that since the ADD-PATH Capability has 188 also been exchanged, every UPDATE will still contain an NLRI 189 containing a "path identifier", as specified in 190 [I-D.ietf-idr-add-paths]. 192 When processing a received Selective ADD-PATH Capability on a 193 particular BGP session, a BGP speaker MUST ensure that it has already 194 received the ADD-PATH Capability defined in [I-D.ietf-idr-add-paths] 195 on that session. Otherwise, the BGP speaker MUST treat the received 196 Selective ADD-PATH Capability as an unsupported Capability, and 197 follow the error handling rules for unsupported Capabilities in 198 [RFC5492]. 200 3. Selective ADD-PATH Extended Community 202 We define a new Transitive Opaque Extended Community ([RFC4360], 203 [RFC7153]) known as the Selective ADD-PATH Extended Community. The 204 sub-type code point for this Extended Community will be assigned by 205 IANA. 207 If Selective ADD-PATH Capability negotiation for a given AFI/SAFI has 208 not taken place, but the Selective ADD-PATH Extended Community is 209 included with a prefix of that AFI/SAFI, the Selective ADD-PATH 210 Extended Community will be ignored. However, the occurrence of the 211 unexpected Extended Community SHOULD be logged. Also, the Extended 212 Community SHOULD NOT be stripped from the path, but rather SHOULD be 213 propagated along with the path. 215 Upon successful Selective ADD-PATH Capability negotiation for a 216 particular AFI/SAFI, a BGP speaker MUST NOT announce multiple paths 217 for any prefix of that AFI/SAFI unless at least one of the following 218 conditions holds: 220 o It has at least one received UPDATE for that prefix that includes 221 the Selective ADD-PATH Extended Community in its attributes. 223 o It is the originator of an UPDATE for that prefix, and it has been 224 configured to attach the Selective ADD-PATH Extended Community to 225 that UPDATE. 227 If at some later time, these conditions no longer hold for a given 228 prefix, the BGP speaker MUST withdraw all but the best path for that 229 prefix. 231 It is to be expected that if a BGP speaker has received multiple 232 paths for a given prefix, either all the paths will have the 233 Selective ADD-PATH Extended Community or none of them will. However, 234 the rules above require the Selective ADD-PATH procedures to be 235 applied to that prefix if even one received path for that prefix has 236 the Selective ADD-PATH Extended Community. 238 4. Selective Add-Path Use Case 240 A use case is a BGP deployment where underlay and overlay routes are 241 associated with the same AFI/SAFI and, for scaling reasons, it is 242 desired that multiple paths are advertised and installed only for the 243 underlay routes. For direct BGP sessions, the ingress routers would 244 only advertise multiple paths for the underlay routes. However, if 245 the topology includes BGP Router Reflectors [RFC4456], it is likely 246 that multiple ingress routers will advertise the same overlay routes. 247 In this case, the mechanism describe herein would be useful in 248 limiting multi-path best-path computation and advertisement to the 249 underlay routes. 251 5. IANA Considerations 253 This document defines a new Capability for BGP, the "Selective ADD- 254 PATH" Capability. We request IANA to assign a code point for this 255 Capability from "First Come, First Served" range of the BGP 256 "Capability Codes" registry at http://www.iana.org/assignments/ 257 capability-codes/capability-codes.xhtml. This document should be the 258 reference. 260 This document also defines a new Extended Community for BGP, the 261 Selective ADD-PATH Extended Community. We request IANA to assign a 262 code point for this community from the "First Come, First Served" 263 range of the "Transitive Opaque Extended Communities Sub-Type" 264 registry at http://www.iana.org/assignments/bgp-extended-communities/ 265 bgp-extended-communities.xhtml. This document should be the 266 reference. 268 6. Security Considerations 270 This extension to BGP does not change the underlying security issues 271 inherent in the existing [RFC4724] and [RFC4271]. 273 6.1. Acknowledgements 275 The authors would like to thank Eric Rosen for his review and 276 comments. 278 7. References 280 7.1. Normative References 282 [I-D.ietf-idr-add-paths] 283 Walton, D., Retana, A., Chen, E., and J. Scudder, 284 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 285 add-paths-13 (work in progress), December 2015. 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, 289 DOI 10.17487/RFC2119, March 1997, 290 . 292 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 293 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 294 DOI 10.17487/RFC4271, January 2006, 295 . 297 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 298 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 299 February 2006, . 301 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 302 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 303 2009, . 305 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 306 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 307 March 2014, . 309 7.2. Informational References 311 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 312 Reflection: An Alternative to Full Mesh Internal BGP 313 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 314 . 316 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 317 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 318 DOI 10.17487/RFC4724, January 2007, 319 . 321 Authors' Addresses 322 Keyur Patel 323 Cisco Systems 324 170 W. Tasman Drive 325 San Jose, CA 95134 326 USA 328 Email: keyupate@cisco.com 330 Acee Lindem 331 Cisco Systems 332 170 W. Tasman Drive 333 San Jose, CA 95134 334 USA 336 Email: acee@cisco.com