idnits 2.17.1 draft-ietf-idr-next-hop-capability-03.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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Advertisement of the RLD is optional. When used, changes in IGP routing may trigger BGP re-advertisement and hence will increase BGP churn. If the RLD is decreased, it SHOULD be readvertised immediatly. If the RLD is increased is MAY NOT be readvertised immediatly. We note however that labelled BGP routes are typically not advertised outside of an administrative domain hence the churn would be limited to this administrative domain. -- The document date (June 26, 2018) is 2130 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) == Outdated reference: A later version (-12) exists of draft-ietf-mpls-spring-entropy-label-11 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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 28, 2018 W. Henderickx 7 Nokia 8 June 26, 2018 10 BGP Next-Hop dependent capabilities 11 draft-ietf-idr-next-hop-capability-03 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 https://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 28, 2018. 54 Copyright Notice 56 Copyright (c) 2018 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 (https://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. Readable Label Depth . . . . . . . . . . . . . . . . . . 7 80 3.2. Entropy Label Next-Hop Capability error handling . . . . 9 81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 4.1. Next-Hop Capabilities Attribute . . . . . . . . . . . . . 9 83 4.2. Next-Hop Capability registry . . . . . . . . . . . . . . 9 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 88 7.2. Informative References . . . . . . . . . . . . . . . . . 11 89 Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 11 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 [RFC5492] advertises the capabilities of the BGP peer. When the BGP 95 peer is not the same as the BGP Next-Hop, it is useful to also be 96 able to advertise the capability of the BGP Next-Hop, in particular 97 to advertise forwarding plane features. This document defines a 98 mechanism to advertise such BGP Next Hop Capabilities. 100 This document defines a new BGP non-transitive attribute to carry 101 Next-Hop Capabilities. This attribute is guaranteed to be deleted or 102 updated when the BGP Next Hop is changed, in order to reflect the 103 capabilities of the new BGP Next-Hop. Hence it allows advertising 104 capabilities which are dependent of the BGP Next-Hop. 106 This attribute advertises the capabilities of the BGP Next-Hop for 107 the NLRI advertised in the same BGP update. A BGP Next-Hop may 108 advertise different capabilities for different set of NLRI. 110 This document also defines a first application to advertise the 111 capability to handle the MPLS Entropy Label defined in [RFC6790]. 112 Note that RFC 6790 had originally defined a BGP attribute for this 113 but it has been latter deprecated in [RFC7447]. 115 2. BGP Next-Hop dependent Capabilities Attribute 117 2.1. Encoding 119 The BGP Next-Hop dependent Capabilities Attribute is an optional, 120 non-transitive BGP Attribute, of value TBD1. The attribute consists 121 of a set of Next-Hop Capabilities. 123 The inclusion of a Next-Hop Capability "X" in a BGP UPDATE message, 124 indicates that the BGP Next-Hop, encoded in either the NEXT_HOP 125 attribute defined in [RFC4271] or the Network Address of Next Hop 126 field of the MP_REACH_NLRI attribute defined in [RFC4760], supports 127 the capability "X" for the NLRI advertised in this BGP UPDATE. 129 This document does not make a distinction between these two Next-Hop 130 fields and uses the term 'BGP Next-Hop' to refer to whichever one is 131 used in a given BGP UPDATE message. 133 A Next-Hop Capability is a triple (Capability Code, Capability 134 Length, Capability Value) aka a TLV: 136 +------------------------------+ 137 | Capability Code (2 octets) | 138 +------------------------------+ 139 | Capability Length (2 octets) | 140 +------------------------------+ 141 | Capability Value (variable) | 142 ~ ~ 143 +------------------------------+ 145 Figure 1: BGP Next-Hop Capability 147 Capability Code: a two-octets unsigned binary integer which indicates 148 the type of "Next-Hop Capability" advertised and unambiguously 149 identifies an individual capability. 151 Capability Length: a two-octets unsigned binary integer which 152 indicates the length, in octets, of the Capability Value field. A 153 length of 0 indicates that no Capability Value field is present. 155 Capability Value: a variable-length field. It is interpreted 156 according to the value of the Capability Code. 158 BGP speakers SHOULD NOT include more than one instance of a Next-Hop 159 capability with the same Capability Code, Capability Length, and 160 Capability Value. Note, however, that processing of multiple 161 instances of such capability does not require special handling, as 162 additional instances do not change the meaning of the announced 163 capability; thus, a BGP speaker MUST be prepared to accept such 164 multiple instances. 166 BGP speakers MAY include more than one instance of a capability (as 167 identified by the Capability Code) with non-zero Capability Length 168 field, but with different Capability Value and either the same or 169 different Capability Length. Processing of these capability 170 instances is specific to the Capability Code and MUST be described in 171 the document introducing the new capability. 173 2.2. Attribute Operation 175 The BGP Next-Hop dependent Capabilities attribute being non- 176 transitive, as per [RFC4271], a BGP speaker which does not understand 177 it will quietly ignore it and not pass it along to other BGP peers. 179 A BGP speaker that understands the BGP Next-Hop dependent 180 Capabilities Attribute and does not change the BGP Next-Hop, SHOULD 181 NOT change the BGP Next-Hop dependent Capabilities Attribute and 182 SHOULD pass the attribute unchanged along to other BGP peers. 184 A BGP speaker that understands the BGP Next-Hop dependent 185 Capabilities Attribute and changes the BGP Next-Hop, MUST remove or 186 update the received BGP Next-Hop dependent Capabilities Attribute 187 before propagating the BGP UPDATE to other BGP peers. If the 188 capability is not removed, it MUST be updated to only advertise the 189 capabilities of the new BGP Next-Hop for these NLRIs. An 190 implementation MAY allow, by configuration, to not advertise some of 191 the capabilities of a BGP Next-Hop. If a received capability is 192 unknown, it can't be updated hence unknown capabilities MUST be 193 removed when the BGP Next-Hop is changed. 195 The BGP Next-Hop Capability Code MUST reflect the capability of the 196 router indicated in the BGP Next-Hop, for the NLRI advertised in the 197 BGP UPDATE. If a BGP speaker sets the BGP Next-Hop to an address of 198 a different router, it MUST NOT advertise a BGP Next-Hop Capability 199 not supported by this router for these NLRI. 201 2.3. Interpreting received Capability 203 A BGP speaker receiving a BGP Next-Hop Capability Code that it 204 supports behave as defined in the document defining this Capability 205 Code. A BGP speaker receiving a BGP Next-Hop Capability Code that it 206 does not support MUST ignore this BGP Next-Hop Capability Code. In 207 particular, this MUST NOT be handled as an error. In both cases, the 208 BGP speaker MUST examine the remaining BGP Next-Hop Capability 209 Code(s) that may be present in the BGP Next-Hop Capabilities 210 Attribute. 212 The presence of a Next-Hop Capability SHOULD NOT influence route 213 selection or route preference, unless tunneling is used to reach the 214 BGP Next-Hop or the selected route has been learnt from EBGP (i.e. 215 the Next-Hop is in a different AS). Indeed, it is in general 216 impossible for a node to know that all BGP routers of the Autonomous 217 System (AS) will understand a given Next-Hop Capability; and having 218 different routers, within an AS, use a different preference for a 219 route, may result in forwarding loops if tunnelling is not used to 220 reach the BGP Next-Hop. 222 2.4. Attribute Error Handling 224 A BGP Next-Hop dependent Capabilities Attribute is considered 225 malformed if the length of the Attribute is not equal to the sum of 226 all (BGP Next-Hop dependent Capability Length +4) of the capabilities 227 carried in this attribute. Note that "4" is the length of the fields 228 "Type" and "Length" of each BGP Next Hop dependent Capability, as the 229 capability length only account for the length of the Value field. 231 A BGP UPDATE message with a malformed BGP Next-Hop dependent 232 Capabilities Attribute SHALL be handled using the approach of 233 "attribute discard" defined in [RFC7606]. 235 Unknown Next-Hop Capabilities Codes MUST NOT be considered as an 236 error. 238 A document that specifies a new Next-Hop Capability SHOULD provide 239 specifics regarding what constitutes an error for that Next-Hop 240 Capability. 242 If a Next-Hop dependent Capability is malformed, this Capability MUST 243 be ignored and removed. Others Next-Hop Capabilities MUST be 244 processed as usual. 246 2.5. Network operation considerations 248 In the corner case where multiple nodes use the same IP address as 249 their BGP Next-Hop, aka anycast nodes as described in [RFC4786], a 250 BGP speaker MUST NOT advertise a given Next-Hop Capability unless all 251 nodes sharing this same IP address support this Next-Hop Capability. 252 The network operator operating those anycast nodes is responsible for 253 enforcing that an anycast node does not advertise a BGP Next-Hop 254 capability not supported by all nodes advertising this anycast 255 address. This can be performed by using anycast nodes sharing the 256 same capabilities or by filtering the BGP Next-Hop Capabilities which 257 are not shared by all anycast nodes. 259 For security considerations, a network operator may want to filter 260 the BGP Next-Hop capabilities advertised to external Autonomous 261 Systems. 263 3. Entropy Label Next-Hop dependent Capability 265 The Entropy Label Next-Hop Capability has type code 1 and a length of 266 0 or 1 octet. 268 The inclusion of the "Entropy Label" Next-Hop Capability indicates 269 that the BGP Next-Hop can be sent packets, for all routes indicated 270 in the NRLI, with a MPLS entropy label (ELI, EL) added immediately 271 after the label stack advertised with the NLRI. 273 On the receiving side, suppose BGP speaker S has determined that 274 packet P is to be forwarded according to BGP route R, where R is a 275 route of one of the labeled address families. And suppose that L is 276 the label stack embedded in the NLRI of route R. Then to forward 277 packet P according to route R, S either replaces P's top label with 278 L, or else pushes L onto the MPLS label stack. If the EL-Capability 279 is advertised in the BGP UPDATE advertising this route R, S knows 280 that it may safely place the ELI and an EL on the label stack 281 immediately beneath L. 283 A BGP speaker S that sends an UPDATE with the BGP Next-Hop "NH" MAY 284 include the Entropy Label Next-Hop Capability only if the NLRI are 285 labelled and for all the NLRI in the BGP UPDATE, either of the 286 following is true: 288 o Egress case: NH is the egress of the LSP advertised with the NLRI 289 and its capable of handling the ELI during the lookup of the MPLS 290 top label. 292 o Transit LSR case: NH is a transit LSR for the LSP advertised with 293 the NLRI (i.e. NH swaps one of the label advertised in the NLRI) 294 and next downstream BGP Next-Hop(s) has(have) advertised the 295 Entropy Label Next-Hop Capability (or a similar capability 296 signalled by protocol P if the route is redistributed, by NH, from 297 protocol P into BGP). 299 3.1. Readable Label Depth 301 When stacked LSPs are used and a LSR nests LSP(s) inside this BGP 302 signalled LSP, its useful for the ingress LSRs to know how many 303 labels the BGP Next-Hop and its downstream LSR(s) may read when load- 304 balancing based on the Entropy Label. In other words, how many 305 labels the ingress LER may push, before pushing an entropy label that 306 will be seen by the BGP Next-Hop and its downstream LSR(s). 308 This maximum number of labels is called the Readable Label Depth 309 (RLD) of the LSP(s). It is related, yet different, to the RLD of an 310 node which is defined in [I-D.ietf-mpls-spring-entropy-label] 312 The RLD of the LSP(s) advertised in the NLRI, may be advertised in 313 the first octet of value field of the Entropy Label Next-Hop 314 Capability. This value field is optional. If present, the value 315 field is a one-octet unsigned binary integer which indicates the 316 maximum Readable Label Depth (RLD) of the LSP(s) advertised in the 317 NLRI. In other words, this is the maximum number of MPLS labels that 318 may be pushed by the ingress, before pushing the ELI, EL labels, 319 where the BGP Next-Hop and its downstream LSR(s) are capable of 320 performing load-balancing based on the entropy label. 322 S SHOULD advertise a RLD of: 324 o If S is the egress of the LSP(s) advertised in the NLRI: its own 325 local RLD; 327 o If S is propagating in BGP a route received in BGP: the minimum 328 of: 330 * its own node RLD; 332 * the RLD of the LSP from itself to the BGP NEXT_HOP of its 333 received route minus (Number of Labels in the received NLRI - 334 Number of Labels in the sent NLRI); 336 * 0 if a RLD is not present in its received routes or the RLD in 337 the received BGP route minus (Number of Labels in the received 338 NLRI - Number of Labels in the sent NLRI). 340 * Note that the first term represents the limitation of the new 341 BGP NEXT_HOP (S), the second term the contribution of the 342 LSR(s) between the new BGP NEXT_HOP (S) and the old (received) 343 BGP NEXT_HOP (S'), the third term represent the contribution 344 from the old BGP NEXT_HOP (S') toward the egress. 346 o If S is propagating in BGP a route received in protocol X: the 347 minimum of: 349 * its own node RLD; 351 * the minimum of thg RLD(s) in the received protocol X to reach 352 the NLRI(s). 354 255 is a reserved value. 356 Note that the local RLD is meant as a node value. If a router has 357 multiple line cards with different capabilities, the router SHOULD 358 advertise the smallest one. However, a router MAY choose to only 359 consider the line cards that may be used by the BGP routers receiving 360 the ELC. e.g. if the ELC is advertised over an EBGP session with peer 361 A, a router MAY consider only the line cards connected to peer A. 363 Advertisement of the RLD is optional. When used, changes in IGP 364 routing may trigger BGP re-advertisement and hence will increase BGP 365 churn. If the RLD is decreased, it SHOULD be readvertised 366 immediatly. If the RLD is increased is MAY NOT be readvertised 367 immediatly. We note however that labelled BGP routes are typically 368 not advertised outside of an administrative domain hence the churn 369 would be limited to this administrative domain. 371 3.2. Entropy Label Next-Hop Capability error handling 373 If the Entropy Label Next-Hop Capability is present more than once, 374 it MUST be considered as received once with a length of 0. 376 If the Entropy Label Next-Hop Capability is received with a length 377 other than 0 or 1, it is not considered malformed, and its semantics 378 are exactly the same as if it had a length of 1. In other words, 379 additional octets MUST be ignored. This allows for the graceful 380 addition of future extensions. 382 4. IANA Considerations 384 4.1. Next-Hop Capabilities Attribute 386 IANA is requested to allocate a new Path Attribute, called "Next-Hop 387 Capabilities", type Code TBD1, from the "BGP Path Attributes" 388 registry. 390 4.2. Next-Hop Capability registry 392 The IANA is requested to create and maintain a registry entitled "BGP 393 Next-Hop Capabilities". 395 The registration policies [RFC8126] for this registry are: 397 1-63 IETF Review 398 64-65534 First Come First Served 399 65535 Reserved 401 IANA is requested to make the following initial assignments: 403 Registry Name: Next-Hop Capability. 405 Value Meaning Reference 406 ---------- ---------------------------------------- --------- 407 0 Reserved (not to be allocated) This document 408 1 Entropy Label This document 409 2-65534 Unassigned 410 65535 Reserved for future registry extension This document 412 5. Security Considerations 414 This document does not introduce new security vulnerabilities in BGP. 415 Specifically, an operator who is relying on the information carried 416 in BGP must have a transitive trust relationship back to the source 417 of the information. Specifying the mechanism(s) to provide such a 418 relationship is beyond the scope of this document. Please refer to 419 the Security Considerations section of [RFC4271] for security 420 mechanisms applicable to BGP. 422 The advertisement of BGP Next-Hop capabilities to EBGP peers may 423 disclose, to the peer AS, some capabilities of the BGP node and may 424 help fingerprinting its hardware model and software version. This 425 may be mitigated by filtering the capability advertised to EBGP 426 peers. 428 Security of the Entropy Label capability advertisement is unchanged 429 compared to [RFC6790] which originally defined this signaling. 431 6. Acknowledgement 433 The Entropy Label Next-Hop Capability defined in this document is 434 based on the ELC BGP attribute defined in section 5.2 of [RFC6790]. 436 The authors wish to thank John Scudder for the discussions on this 437 topic and Eric Rosen for his in-depth review of this document. 439 The authors wish to thank Jie Dong and Robert Raszuk for their review 440 and comments. 442 7. References 444 7.1. Normative References 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, 448 DOI 10.17487/RFC2119, March 1997, 449 . 451 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 452 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 453 DOI 10.17487/RFC4271, January 2006, 454 . 456 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 457 "Multiprotocol Extensions for BGP-4", RFC 4760, 458 DOI 10.17487/RFC4760, January 2007, 459 . 461 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 462 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 463 RFC 6790, DOI 10.17487/RFC6790, November 2012, 464 . 466 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 467 Patel, "Revised Error Handling for BGP UPDATE Messages", 468 RFC 7606, DOI 10.17487/RFC7606, August 2015, 469 . 471 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 472 Writing an IANA Considerations Section in RFCs", BCP 26, 473 RFC 8126, DOI 10.17487/RFC8126, June 2017, 474 . 476 7.2. Informative References 478 [I-D.ietf-mpls-spring-entropy-label] 479 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 480 Shakir, R., and J. Tantsura, "Entropy label for SPRING 481 tunnels", draft-ietf-mpls-spring-entropy-label-11 (work in 482 progress), May 2018. 484 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 485 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 486 December 2006, . 488 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 489 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 490 2009, . 492 [RFC7447] Scudder, J. and K. Kompella, "Deprecation of BGP Entropy 493 Label Capability Attribute", RFC 7447, 494 DOI 10.17487/RFC7447, February 2015, 495 . 497 Appendix A. Changes / Author Notes 499 [RFC Editor: Please remove this section before publication] 501 Changes -01: 503 o Capability code and length encoded over 2 octets (from one). IANA 504 registry is now mainly FCFS. 506 o Addition of section "Network operation considerations", in 507 particular to discuss anycast nodes. 509 o Enhanced Security consideration (capability advertised to external 510 ASes). 512 o Editorial changes and typo corrections. 514 Changes -02: No change. Refresh only. 516 Changes -03: Addition of the optional Readable Label Depth. 518 Authors' Addresses 520 Bruno Decraene 521 Orange 523 Email: bruno.decraene@orange.com 525 Kireeti Kompella 526 Juniper Networks, Inc. 527 1194 N. Mathilda Avenue 528 Sunnyvale, CA 94089 529 USA 531 Email: kireeti.kompella@gmail.com 533 Wim Henderickx 534 Nokia 535 Copernicuslaan 50 536 Antwerp 2018, CA 95134 537 Belgium 539 Email: wim.henderickx@nokia.com