idnits 2.17.00 (12 Aug 2021) /tmp/idnits62651/draft-keyupate-idr-bgp-selective-add-paths-01.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 (July 8, 2016) is 2136 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 151, but not defined == Missing Reference: 'RFC4456' is mentioned on line 254, but not defined == Missing Reference: 'RFC4724' is mentioned on line 259, but not defined == Outdated reference: draft-ietf-idr-add-paths has been published as RFC 7911 Summary: 0 errors (**), 0 flaws (~~), 6 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: January 9, 2017 L. Jalil 6 Verizon 7 July 8, 2016 9 Selective Advertisement of Multiple Paths within BGP 10 draft-keyupate-idr-bgp-selective-add-paths-01.txt 12 Abstract 14 [draft-ietf-idr-add-paths] defines a BGP extension that allows the 15 advertisement of multiple paths for the same address prefix without 16 the new paths implicitly replacing any previous ones. The essence of 17 the extension is that each path is identified by a path identifier in 18 addition to the address prefix. This draft augments functionality 19 defined in [draft-ietf-idr-add-paths] to facilitate advertisement of 20 multiple paths for a subset of prefixes in a given address family. 21 Prefixes are selected through specification of a well-known BGP 22 extended community. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 9, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 72 2. Selective Add-Path Capability . . . . . . . . . . . . . . . . 3 73 3. Selective Add-Path Community . . . . . . . . . . . . . . . . 4 74 4. Selective Add-Path Use Case . . . . . . . . . . . . . . . . . 5 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 77 6.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . 5 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 80 7.2. Information References . . . . . . . . . . . . . . . . . 6 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 83 1. Introduction 85 [I-D.ietf-idr-add-paths] defines a BGP extension that allows the 86 advertisement of multiple paths for the same address prefix without 87 the new paths implicitly replacing any previous ones. The essence of 88 the extension is that each path is identified by a path identifier in 89 addition to the address prefix. This document augments functionality 90 defined in defined in [I-D.ietf-idr-add-paths] to facilitate 91 advertisement of multiple paths for a subset of prefixes in a given 92 address family. Prefixes are selected through specification of a 93 reserved BGP extended community. 95 This draft defines a capability to limit the scope of BGP multiple 96 path advertisement to a subset prefixes in a given address family. 98 Prefixes are selected through specification of a reserved BGP 99 extended community [RFC4360]. 101 ------ 102 P1--> | R1 | 103 P2--> ------ \ ------ ------ 104 -- | RR | -- | R3 | 105 ------ / ------ ------ 106 P1--> | R2 | 107 P2--> ------ 109 As an example, suppose that RR is a route reflector that doesn't 110 change nexthops of the prefixes it reflects, with clients R1, R2 and 111 R3. Suppose R1 sends RR an UPDATE: and . Suppose R2 sends RR an UPDATE: and 113 . R1, R2, and R3 would like selective ADDPATHs for 114 Prefix P1 and not for Prefix P2. R1, R2, and R3 exchange selective 115 the ADDPATH capability with RR. R1, R2, R3 are configured with the 116 reserved selective ADDPATHs community that they attach to prefixes 117 that need selective ADDPATHs. RR now has two paths to P1 and P2. RR 118 announces P2 with bestpath to all its clients while RR announces P1 119 with additional paths. The number of additional paths with its best 120 path and its additional paths is a matter of local policy configured 121 on RR. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. Selective Add-Path Capability 131 The ADD-PATH Capability is a new BGP capability [RFC5492]. The 132 Capability Code for this capability is allocated by IANA as specified 133 in the Section 5. The Capability Length field of this capability is 134 variable. The Capability Value field consists of one or more of the 135 following tuples: 137 +------------------------------------------------+ 138 | Address Family Identifier (2 octets) | 139 +------------------------------------------------+ 140 | Subsequent Address Family Identifier (1 octet) | 141 +------------------------------------------------+ 143 The meaning and use of the fields are as follows: 145 Address Family Identifier (AFI): 147 This field is the same as the one used in [RFC4760]. 149 Subsequent Address Family Identifier (SAFI): 151 This field is the same as the one used in [RFC4760]. 153 A BGP Speaker that wishes to announce or receive multiple paths MUST 154 exchange the add-path capability defined in [I-D.ietf-idr-add-paths]. 155 A BGP Speaker that wishes to announce or receive multiple paths for 156 selected prefixes MUST exchange the selective add-path capability 157 defined in this draft. A BGP speaker wanting to advertise selective 158 add-path capability MUST also advertise the add-path capability 159 defined in [I-D.ietf-idr-add-paths]. 161 In processing a received selective add-path capability from a peer, a 162 BGP speaker MUST ensure that it also received the add-path capability 163 defined in [I-D.ietf-idr-add-paths]. Otherwise, the BGP speaker 164 should ignore the received selective add-path capability and follow 165 the error handling rules for unsupported add-path capabilites in 166 [RFC5492]. 168 3. Selective Add-Path Community 170 Upon successful Selective Add-Path capability negotiation, a BGP 171 speaker MUST NOT announce multiple paths for any AFI/SAFI prefix 172 unless it has received at least one UPDATE for that prefix that 173 includes the Selective Add-Path well-known community in its 174 attributes. The community is a Transitive Opaque Extended Community 175 with the sub-type value IANA-TBD. 177 If Selective Add-Path capability negotiation for a given AFI/SAFI has 178 not taken place and the Selective Add-Path Community is included with 179 a prefix advertised for the same AFI/SAFI, the Selective Add-Path 180 Community will be ignored. However, the occurance of the unexpected 181 community SHOULD be logged. 183 4. Selective Add-Path Use Case 185 A use case is a BGP deployment where underlay and overlay routes are 186 associated with the same AFI/SAFI and, due to scaling, only multiple 187 paths are only advertised and installed for underlay routes. For 188 direct BGP sessions, the ingress routers would only advertise 189 multiple paths for the underlay routes. However, if the topology 190 includes BGP Router Reflectors [RFC4456], it is likely that multiple 191 ingress routers will advertise the same overlay routes. In this 192 case, the mechanism describe herein would be useful in limiting 193 multi-path best-path computation and advertisement to the underlay 194 routes. 196 As a second usecase, many times a service provider will carry both 197 customer traffic and internal services (e.g., VOIP) on the same 198 backbone network using routes in the same BGP address families. In 199 this situation, the number of customer routes and paths greatly 200 exceed the number of routes and paths for internal services. 201 However, the service provider desires the faster failover and 202 convergence provided by BGP Add-Paths [I-D.ietf-idr-add-paths]. In 203 this scenario, the Selective Add-Path functionality described herein 204 can be leveraged for routes corresponding to internal services 205 without the overhead incurred if multiple paths were advertised for 206 the customer routes. 208 5. IANA Considerations 210 This document defines a new capability for BGP. We request IANA to 211 assign BGP capability number from BGP Capabilities Registry. 213 This document also defines a new extended community for BGP. We 214 request IANA to assign a BGP well-known extended community from the 215 Transitive Opaque Extended Community Sub-Types Registry. 217 6. Security Considerations 219 This extension to BGP does not change the underlying security issues 220 inherent in the existing [RFC4724] and [RFC4271]. 222 6.1. Acknowledgements 224 The authors would like to thank .... for the review and comments. 226 7. References 227 7.1. Normative References 229 [I-D.ietf-idr-add-paths] 230 Walton, D., Retana, A., Chen, E., and J. Scudder, 231 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 232 add-paths-13 (work in progress), December 2015. 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, 236 DOI 10.17487/RFC2119, March 1997, 237 . 239 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 240 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 241 DOI 10.17487/RFC4271, January 2006, 242 . 244 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 245 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 246 February 2006, . 248 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 249 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 250 2009, . 252 7.2. Information References 254 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 255 Reflection: An Alternative to Full Mesh Internal BGP 256 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 257 . 259 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 260 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 261 DOI 10.17487/RFC4724, January 2007, 262 . 264 Authors' Addresses 266 Keyur Patel 267 Cisco Systems 268 170 W. Tasman Drive 269 San Jose, CA 95134 270 USA 272 Email: keyupate@cisco.com 273 Acee Lindem 274 Cisco Systems 275 170 W. Tasman Drive 276 San Jose, CA 95134 277 USA 279 Email: acee@cisco.com 281 Luay Jalil 282 Verizon 283 400 International Parkway 284 Richardson, Tx 75081 285 USA 287 Email: luay.jalil@verizon.com