--- 1/draft-ietf-idr-next-hop-capability-02.txt 2018-06-27 01:13:09.835713542 -0700 +++ 2/draft-ietf-idr-next-hop-capability-03.txt 2018-06-27 01:13:09.863714216 -0700 @@ -1,21 +1,21 @@ Network Working Group B. Decraene Internet-Draft Orange Updates: 6790 (if approved) K. Kompella Intended status: Standards Track Juniper Networks, Inc. -Expires: August 15, 2018 W. Henderickx +Expires: December 28, 2018 W. Henderickx Nokia - February 11, 2018 + June 26, 2018 BGP Next-Hop dependent capabilities - draft-ietf-idr-next-hop-capability-02 + draft-ietf-idr-next-hop-capability-03 Abstract RFC 5492 advertises the capabilities of the BGP peer. When the BGP peer is not the same as the BGP Next-Hop, it is useful to also be able to advertise the capability of the BGP Next-Hop, in particular to advertise forwarding plane features. This document defines a mechanism to advertise such BGP Next Hop dependent Capabilities. This document defines a new BGP non-transitive attribute to carry @@ -42,21 +42,21 @@ 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 https://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 August 15, 2018. + This Internet-Draft will expire on December 28, 2018. Copyright Notice Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -69,31 +69,32 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. BGP Next-Hop dependent Capabilities Attribute . . . . . . . . 3 2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Attribute Operation . . . . . . . . . . . . . . . . . . . 4 2.3. Interpreting received Capability . . . . . . . . . . . . 5 2.4. Attribute Error Handling . . . . . . . . . . . . . . . . 5 2.5. Network operation considerations . . . . . . . . . . . . 6 3. Entropy Label Next-Hop dependent Capability . . . . . . . . . 6 - 3.1. Entropy Label Next-Hop Capability error handling . . . . 7 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 4.1. Next-Hop Capabilities Attribute . . . . . . . . . . . . . 7 - 4.2. Next-Hop Capability registry . . . . . . . . . . . . . . 7 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 - 7.2. Informative References . . . . . . . . . . . . . . . . . 9 - Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1. Readable Label Depth . . . . . . . . . . . . . . . . . . 7 + 3.2. Entropy Label Next-Hop Capability error handling . . . . 9 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 4.1. Next-Hop Capabilities Attribute . . . . . . . . . . . . . 9 + 4.2. Next-Hop Capability registry . . . . . . . . . . . . . . 9 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 7.2. Informative References . . . . . . . . . . . . . . . . . 11 + Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction [RFC5492] advertises the capabilities of the BGP peer. When the BGP peer is not the same as the BGP Next-Hop, it is useful to also be able to advertise the capability of the BGP Next-Hop, in particular to advertise forwarding plane features. This document defines a mechanism to advertise such BGP Next Hop Capabilities. This document defines a new BGP non-transitive attribute to carry @@ -255,21 +256,21 @@ same capabilities or by filtering the BGP Next-Hop Capabilities which are not shared by all anycast nodes. For security considerations, a network operator may want to filter the BGP Next-Hop capabilities advertised to external Autonomous Systems. 3. Entropy Label Next-Hop dependent Capability The Entropy Label Next-Hop Capability has type code 1 and a length of - 0 octet. + 0 or 1 octet. The inclusion of the "Entropy Label" Next-Hop Capability indicates that the BGP Next-Hop can be sent packets, for all routes indicated in the NRLI, with a MPLS entropy label (ELI, EL) added immediately after the label stack advertised with the NLRI. On the receiving side, suppose BGP speaker S has determined that packet P is to be forwarded according to BGP route R, where R is a route of one of the labeled address families. And suppose that L is the label stack embedded in the NLRI of route R. Then to forward @@ -288,30 +289,102 @@ and its capable of handling the ELI during the lookup of the MPLS top label. o Transit LSR case: NH is a transit LSR for the LSP advertised with the NLRI (i.e. NH swaps one of the label advertised in the NLRI) and next downstream BGP Next-Hop(s) has(have) advertised the Entropy Label Next-Hop Capability (or a similar capability signalled by protocol P if the route is redistributed, by NH, from protocol P into BGP). -3.1. Entropy Label Next-Hop Capability error handling +3.1. Readable Label Depth + + When stacked LSPs are used and a LSR nests LSP(s) inside this BGP + signalled LSP, its useful for the ingress LSRs to know how many + labels the BGP Next-Hop and its downstream LSR(s) may read when load- + balancing based on the Entropy Label. In other words, how many + labels the ingress LER may push, before pushing an entropy label that + will be seen by the BGP Next-Hop and its downstream LSR(s). + + This maximum number of labels is called the Readable Label Depth + (RLD) of the LSP(s). It is related, yet different, to the RLD of an + node which is defined in [I-D.ietf-mpls-spring-entropy-label] + + The RLD of the LSP(s) advertised in the NLRI, may be advertised in + the first octet of value field of the Entropy Label Next-Hop + Capability. This value field is optional. If present, the value + field is a one-octet unsigned binary integer which indicates the + maximum Readable Label Depth (RLD) of the LSP(s) advertised in the + NLRI. In other words, this is the maximum number of MPLS labels that + may be pushed by the ingress, before pushing the ELI, EL labels, + where the BGP Next-Hop and its downstream LSR(s) are capable of + performing load-balancing based on the entropy label. + + S SHOULD advertise a RLD of: + + o If S is the egress of the LSP(s) advertised in the NLRI: its own + local RLD; + + o If S is propagating in BGP a route received in BGP: the minimum + of: + + * its own node RLD; + + * the RLD of the LSP from itself to the BGP NEXT_HOP of its + received route minus (Number of Labels in the received NLRI - + Number of Labels in the sent NLRI); + + * 0 if a RLD is not present in its received routes or the RLD in + the received BGP route minus (Number of Labels in the received + NLRI - Number of Labels in the sent NLRI). + + * Note that the first term represents the limitation of the new + BGP NEXT_HOP (S), the second term the contribution of the + LSR(s) between the new BGP NEXT_HOP (S) and the old (received) + BGP NEXT_HOP (S'), the third term represent the contribution + from the old BGP NEXT_HOP (S') toward the egress. + + o If S is propagating in BGP a route received in protocol X: the + minimum of: + + * its own node RLD; + + * the minimum of thg RLD(s) in the received protocol X to reach + the NLRI(s). + + 255 is a reserved value. + + Note that the local RLD is meant as a node value. If a router has + multiple line cards with different capabilities, the router SHOULD + advertise the smallest one. However, a router MAY choose to only + consider the line cards that may be used by the BGP routers receiving + the ELC. e.g. if the ELC is advertised over an EBGP session with peer + A, a router MAY consider only the line cards connected to peer A. + + 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. + +3.2. Entropy Label Next-Hop Capability error handling If the Entropy Label Next-Hop Capability is present more than once, it MUST be considered as received once with a length of 0. If the Entropy Label Next-Hop Capability is received with a length - other than 0, it is not considered malformed, but its semantics are - exactly the same as if it had a length of 0. In other words, - additional octets MUST be ignored. This is to allow for graceful - future extension. + other than 0 or 1, it is not considered malformed, and its semantics + are exactly the same as if it had a length of 1. In other words, + additional octets MUST be ignored. This allows for the graceful + addition of future extensions. 4. IANA Considerations 4.1. Next-Hop Capabilities Attribute IANA is requested to allocate a new Path Attribute, called "Next-Hop Capabilities", type Code TBD1, from the "BGP Path Attributes" registry. 4.2. Next-Hop Capability registry @@ -346,21 +419,21 @@ the Security Considerations section of [RFC4271] for security mechanisms applicable to BGP. The advertisement of BGP Next-Hop capabilities to EBGP peers may disclose, to the peer AS, some capabilities of the BGP node and may help fingerprinting its hardware model and software version. This may be mitigated by filtering the capability advertised to EBGP peers. Security of the Entropy Label capability advertisement is unchanged - compared to [RFC6790] which first defined this signaling. + compared to [RFC6790] which originally defined this signaling. 6. Acknowledgement The Entropy Label Next-Hop Capability defined in this document is based on the ELC BGP attribute defined in section 5.2 of [RFC6790]. The authors wish to thank John Scudder for the discussions on this topic and Eric Rosen for his in-depth review of this document. The authors wish to thank Jie Dong and Robert Raszuk for their review @@ -395,20 +468,26 @@ RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . 7.2. Informative References + [I-D.ietf-mpls-spring-entropy-label] + Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., + Shakir, R., and J. Tantsura, "Entropy label for SPRING + tunnels", draft-ietf-mpls-spring-entropy-label-11 (work in + progress), May 2018. + [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC7447] Scudder, J. and K. Kompella, "Deprecation of BGP Entropy Label Capability Attribute", RFC 7447, @@ -427,20 +506,22 @@ o Addition of section "Network operation considerations", in particular to discuss anycast nodes. o Enhanced Security consideration (capability advertised to external ASes). o Editorial changes and typo corrections. Changes -02: No change. Refresh only. + Changes -03: Addition of the optional Readable Label Depth. + Authors' Addresses Bruno Decraene Orange Email: bruno.decraene@orange.com Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Avenue