idnits 2.17.1 draft-ietf-idr-next-hop-capability-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 date (June 29, 2017) is 2493 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Decraene 3 Internet-Draft Orange 4 Updates: 6790 (if approved) K. Kompella 5 Intended status: Standards Track Juniper Networks, Inc. 6 Expires: December 31, 2017 W. Henderickx 7 Nokia 8 June 29, 2017 10 BGP Next-Hop dependent capabilities 11 draft-ietf-idr-next-hop-capability-01 13 Abstract 15 RFC 5492 advertises the capabilities of the BGP peer. When the BGP 16 peer is not the same as the BGP Next-Hop, it is useful to also be 17 able to advertise the capability of the BGP Next-Hop, in particular 18 to advertise forwarding plane features. This document defines a 19 mechanism to advertise such BGP Next Hop dependent Capabilities. 21 This document defines a new BGP non-transitive attribute to carry 22 Next-Hop Capabilities. This attribute is guaranteed to be deleted or 23 updated when the BGP Next Hop is changed, in order to reflect the 24 capabilities of the new BGP Next-Hop. 26 This document also defines a Next-Hop capability to advertise the 27 ability to process the MPLS Entropy Label as an egress LSR for all 28 NLRI advertised in the BGP UPDATE. It updates RFC 6790 with regard 29 to this BGP signaling. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on December 31, 2017. 54 Copyright Notice 56 Copyright (c) 2017 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. BGP Next-Hop dependent Capabilities Attribute . . . . . . . . 3 73 2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2.2. Attribute Operation . . . . . . . . . . . . . . . . . . . 4 75 2.3. Interpreting received Capability . . . . . . . . . . . . 5 76 2.4. Attribute Error Handling . . . . . . . . . . . . . . . . 5 77 2.5. Network operation considerations . . . . . . . . . . . . 6 78 3. Entropy Label Next-Hop dependent Capability . . . . . . . . . 6 79 3.1. Entropy Label Next-Hop Capability error handling . . . . 7 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 81 4.1. Next-Hop Capabilities Attribute . . . . . . . . . . . . . 7 82 4.2. Next-Hop Capability registry . . . . . . . . . . . . . . 7 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 84 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 87 7.2. Informative References . . . . . . . . . . . . . . . . . 9 88 Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 [RFC5492] advertises the capabilities of the BGP peer. When the BGP 94 peer is not the same as the BGP Next-Hop, it is useful to also be 95 able to advertise the capability of the BGP Next-Hop, in particular 96 to advertise forwarding plane features. This document defines a 97 mechanism to advertise such BGP Next Hop Capabilities. 99 This document defines a new BGP non-transitive attribute to carry 100 Next-Hop Capabilities. This attribute is guaranteed to be deleted or 101 updated when the BGP Next Hop is changed, in order to reflect the 102 capabilities of the new BGP Next-Hop. Hence it allows advertising 103 capabilities which are dependent of the BGP Next-Hop. 105 This attribute advertises the capabilities of the BGP Next-Hop for 106 the NLRI advertised in the same BGP update. A BGP Next-Hop may 107 advertise different capabilities for different set of NLRI. 109 This document also defines a first application to advertise the 110 capability to handle the MPLS Entropy Label defined in [RFC6790]. 111 Note that RFC 6790 had originally defined a BGP attribute for this 112 but it has been latter deprecated in [RFC7447]. 114 2. BGP Next-Hop dependent Capabilities Attribute 116 2.1. Encoding 118 The BGP Next-Hop dependent Capabilities Attribute is an optional, 119 non-transitive BGP Attribute, of value TBD1. The attribute consists 120 of a set of Next-Hop Capabilities. 122 The inclusion of a Next-Hop Capability "X" in a BGP UPDATE message, 123 indicates that the BGP Next-Hop, encoded in either the NEXT_HOP 124 attribute defined in [RFC4271] or the Network Address of Next Hop 125 field of the MP_REACH_NLRI attribute defined in [RFC4760], supports 126 the capability "X" for the NLRI advertised in this BGP UPDATE. 128 This document does not make a distinction between these two Next-Hop 129 fields and uses the term 'BGP Next-Hop' to refer to whichever one is 130 used in a given BGP UPDATE message. 132 A Next-Hop Capability is a triple (Capability Code, Capability 133 Length, Capability Value) aka a TLV: 135 +------------------------------+ 136 | Capability Code (2 octets) | 137 +------------------------------+ 138 | Capability Length (2 octets) | 139 +------------------------------+ 140 | Capability Value (variable) | 141 ~ ~ 142 +------------------------------+ 144 Figure 1: BGP Next-Hop Capability 146 Capability Code: a two-octets unsigned binary integer which indicates 147 the type of "Next-Hop Capability" advertised and unambiguously 148 identifies an individual capability. 150 Capability Length: a two-octets unsigned binary integer which 151 indicates the length, in octets, of the Capability Value field. A 152 length of 0 indicates that no Capability Value field is present. 154 Capability Value: a variable-length field. It is interpreted 155 according to the value of the Capability Code. 157 BGP speakers SHOULD NOT include more than one instance of a Next-Hop 158 capability with the same Capability Code, Capability Length, and 159 Capability Value. Note, however, that processing of multiple 160 instances of such capability does not require special handling, as 161 additional instances do not change the meaning of the announced 162 capability; thus, a BGP speaker MUST be prepared to accept such 163 multiple instances. 165 BGP speakers MAY include more than one instance of a capability (as 166 identified by the Capability Code) with non-zero Capability Length 167 field, but with different Capability Value and either the same or 168 different Capability Length. Processing of these capability 169 instances is specific to the Capability Code and MUST be described in 170 the document introducing the new capability. 172 2.2. Attribute Operation 174 The BGP Next-Hop dependent Capabilities attribute being non- 175 transitive, as per [RFC4271], a BGP speaker which does not understand 176 it will quietly ignore it and not pass it along to other BGP peers. 178 A BGP speaker that understands the BGP Next-Hop dependent 179 Capabilities Attribute and does not change the BGP Next-Hop, SHOULD 180 NOT change the BGP Next-Hop dependent Capabilities Attribute and 181 SHOULD pass the attribute unchanged along to other BGP peers. 183 A BGP speaker that understands the BGP Next-Hop dependent 184 Capabilities Attribute and changes the BGP Next-Hop, MUST remove or 185 update the received BGP Next-Hop dependent Capabilities Attribute 186 before propagating the BGP UPDATE to other BGP peers. If the 187 capability is not removed, it MUST be updated to only advertise the 188 capabilities of the new BGP Next-Hop for these NLRIs. An 189 implementation MAY allow, by configuration, to not advertise some of 190 the capabilities of a BGP Next-Hop. If a received capability is 191 unknown, it can't be updated hence unknown capabilities MUST be 192 removed when the BGP Next-Hop is changed. 194 The BGP Next-Hop Capability Code MUST reflect the capability of the 195 router indicated in the BGP Next-Hop, for the NLRI advertised in the 196 BGP UPDATE. If a BGP speaker sets the BGP Next-Hop to an address of 197 a different router, it MUST NOT advertise a BGP Next-Hop Capability 198 not supported by this router for these NLRI. 200 2.3. Interpreting received Capability 202 A BGP speaker receiving a BGP Next-Hop Capability Code that it 203 supports behave as defined in the document defining this Capability 204 Code. A BGP speaker receiving a BGP Next-Hop Capability Code that it 205 does not support MUST ignore this BGP Next-Hop Capability Code. In 206 particular, this MUST NOT be handled as an error. In both cases, the 207 BGP speaker MUST examine the remaining BGP Next-Hop Capability 208 Code(s) that may be present in the BGP Next-Hop Capabilities 209 Attribute. 211 The presence of a Next-Hop Capability SHOULD NOT influence route 212 selection or route preference, unless tunneling is used to reach the 213 BGP Next-Hop or the selected route has been learnt from EBGP (i.e. 214 the Next-Hop is in a different AS). Indeed, it is in general 215 impossible for a node to know that all BGP routers of the Autonomous 216 System (AS) will understand a given Next-Hop Capability; and having 217 different routers, within an AS, use a different preference for a 218 route, may result in forwarding loops if tunnelling is not used to 219 reach the BGP Next-Hop. 221 2.4. Attribute Error Handling 223 A BGP Next-Hop dependent Capabilities Attribute is considered 224 malformed if the length of the Attribute is not equal to the sum of 225 all (BGP Next-Hop dependent Capability Length +4) of the capabilities 226 carried in this attribute. Note that "4" is the length of the fields 227 "Type" and "Length" of each BGP Next Hop dependent Capability, as the 228 capability length only account for the length of the Value field. 230 A BGP UPDATE message with a malformed BGP Next-Hop dependent 231 Capabilities Attribute SHALL be handled using the approach of 232 "attribute discard" defined in [RFC7606]. 234 Unknown Next-Hop Capabilities Codes MUST NOT be considered as an 235 error. 237 A document that specifies a new Next-Hop Capability SHOULD provide 238 specifics regarding what constitutes an error for that Next-Hop 239 Capability. 241 If a Next-Hop dependent Capability is malformed, this Capability MUST 242 be ignored and removed. Others Next-Hop Capabilities MUST be 243 processed as usual. 245 2.5. Network operation considerations 247 In the corner case where multiple nodes use the same IP address as 248 their BGP Next-Hop, aka anycast nodes as described in [RFC4786], a 249 BGP speaker MUST NOT advertise a given Next-Hop Capability unless all 250 nodes sharing this same IP address support this Next-Hop Capability. 251 The network operator operating those anycast nodes is responsible for 252 enforcing that an anycast node does not advertise a BGP Next-Hop 253 capability not supported by all nodes advertising this anycast 254 address. This can be performed by using anycast nodes sharing the 255 same capabilities or by filtering the BGP Next-Hop Capabilities which 256 are not shared by all anycast nodes. 258 For security considerations, a network operator may want to filter 259 the BGP Next-Hop capabilities advertised to external Autonomous 260 Systems. 262 3. Entropy Label Next-Hop dependent Capability 264 The Entropy Label Next-Hop Capability has type code 1 and a length of 265 0 octet. 267 The inclusion of the "Entropy Label" Next-Hop Capability indicates 268 that the BGP Next-Hop can be sent packets, for all routes indicated 269 in the NRLI, with a MPLS entropy label (ELI, EL) added immediately 270 after the label stack advertised with the NLRI. 272 On the receiving side, suppose BGP speaker S has determined that 273 packet P is to be forwarded according to BGP route R, where R is a 274 route of one of the labeled address families. And suppose that L is 275 the label stack embedded in the NLRI of route R. Then to forward 276 packet P according to route R, S either replaces P's top label with 277 L, or else pushes L onto the MPLS label stack. If the EL-Capability 278 is advertised in the BGP UPDATE advertising this route R, S knows 279 that it may safely place the ELI and an EL on the label stack 280 immediately beneath L. 282 A BGP speaker S that sends an UPDATE with the BGP Next-Hop "NH" MAY 283 include the Entropy Label Next-Hop Capability only if the NLRI are 284 labelled and for all the NLRI in the BGP UPDATE, either of the 285 following is true: 287 o Egress case: NH is the egress of the LSP advertised with the NLRI 288 and its capable of handling the ELI during the lookup of the MPLS 289 top label. 291 o Transit LSR case: NH is a transit LSR for the LSP advertised with 292 the NLRI (i.e. NH swaps one of the label advertised in the NLRI) 293 and next downstream BGP Next-Hop(s) has(have) advertised the 294 Entropy Label Next-Hop Capability (or a similar capability 295 signalled by protocol P if the route is redistributed, by NH, from 296 protocol P into BGP). 298 3.1. Entropy Label Next-Hop Capability error handling 300 If the Entropy Label Next-Hop Capability is present more than once, 301 it MUST be considered as received once with a length of 0. 303 If the Entropy Label Next-Hop Capability is received with a length 304 other than 0, it is not considered malformed, but its semantics are 305 exactly the same as if it had a length of 0. In other words, 306 additional octets MUST be ignored. This is to allow for graceful 307 future extension. 309 4. IANA Considerations 311 4.1. Next-Hop Capabilities Attribute 313 IANA is requested to allocate a new Path Attribute, called "Next-Hop 314 Capabilities", type Code TBD1, from the "BGP Path Attributes" 315 registry. 317 4.2. Next-Hop Capability registry 319 The IANA is requested to create and maintain a registry entitled "BGP 320 Next-Hop Capabilities". 322 The registration policies [RFC8126] for this registry are: 324 1-63 IETF Review 325 64-65534 First Come First Served 326 65535 Reserved 328 IANA is requested to make the following initial assignments: 330 Registry Name: Next-Hop Capability. 332 Value Meaning Reference 333 ---------- ---------------------------------------- --------- 334 0 Reserved (not to be allocated) This document 335 1 Entropy Label This document 336 2-65534 Unassigned 337 65535 Reserved for future registry extension This document 339 5. Security Considerations 341 This document does not introduce new security vulnerabilities in BGP. 342 Specifically, an operator who is relying on the information carried 343 in BGP must have a transitive trust relationship back to the source 344 of the information. Specifying the mechanism(s) to provide such a 345 relationship is beyond the scope of this document. Please refer to 346 the Security Considerations section of [RFC4271] for security 347 mechanisms applicable to BGP. 349 The advertisement of BGP Next-Hop capabilities to EBGP peers may 350 disclose, to the peer AS, some capabilities of the BGP node and may 351 help fingerprinting its hardware model and software version. This 352 may be mitigated by filtering the capability advertised to EBGP 353 peers. 355 Security of the Entropy Label capability advertisement is unchanged 356 compared to [RFC6790] which first defined this signaling. 358 6. Acknowledgement 360 The Entropy Label Next-Hop Capability defined in this document is 361 based on the ELC BGP attribute defined in section 5.2 of [RFC6790]. 363 The authors wish to thank John Scudder for the discussions on this 364 topic and Eric Rosen for his in-depth review of this document. 366 The authors wish to thank Jie Dong and Robert Raszuk for their review 367 and comments. 369 7. References 371 7.1. Normative References 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, 375 DOI 10.17487/RFC2119, March 1997, 376 . 378 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 379 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 380 DOI 10.17487/RFC4271, January 2006, 381 . 383 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 384 "Multiprotocol Extensions for BGP-4", RFC 4760, 385 DOI 10.17487/RFC4760, January 2007, 386 . 388 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 389 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 390 RFC 6790, DOI 10.17487/RFC6790, November 2012, 391 . 393 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 394 Patel, "Revised Error Handling for BGP UPDATE Messages", 395 RFC 7606, DOI 10.17487/RFC7606, August 2015, 396 . 398 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 399 Writing an IANA Considerations Section in RFCs", BCP 26, 400 RFC 8126, DOI 10.17487/RFC8126, June 2017, 401 . 403 7.2. Informative References 405 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 406 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 407 December 2006, . 409 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 410 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 411 2009, . 413 [RFC7447] Scudder, J. and K. Kompella, "Deprecation of BGP Entropy 414 Label Capability Attribute", RFC 7447, 415 DOI 10.17487/RFC7447, February 2015, 416 . 418 Appendix A. Changes / Author Notes 420 [RFC Editor: Please remove this section before publication] 422 Changes -01: 424 o Capability code and length encoded over 2 octets (from one). IANA 425 registry is now mainly FCFS. 427 o Addition of section "Network operation considerations", in 428 particular to discuss anycast nodes. 430 o Enhanced Security consideration (capability advertised to external 431 ASes). 433 o Editorial changes and typo corrections. 435 Authors' Addresses 437 Bruno Decraene 438 Orange 440 Email: bruno.decraene@orange.com 442 Kireeti Kompella 443 Juniper Networks, Inc. 444 1194 N. Mathilda Avenue 445 Sunnyvale, CA 94089 446 USA 448 Email: kireeti.kompella@gmail.com 450 Wim Henderickx 451 Nokia 452 Copernicuslaan 50 453 Antwerp 2018, CA 95134 454 Belgium 456 Email: wim.henderickx@nokia.com