BESS Workgroup S. Sethuram Internet-Draft M. Mishra Intended status: Standards Track Cisco Systems Expires: 23 April 2026 S R. Mohanty Zscaler I. Means P. Ramadenu AT&T Labs, Inc. 20 October 2025 Signaling Alternative Labels for BGP Prefixes draft-smm-bess-alt-label-00 Abstract A single MPLS label or a label stack is advertised along with an address prefix as part of the NLRI belonging to labeled address families such as Labeled Unicast (RFC 8277), VPN (RFC 4364), etc. This document specifies a method to advertise one or more additional, alternative labels for a set of address prefixes using the Next Hop Dependent Characteristics (NHC) attribute. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 23 April 2026. Sethuram, et al. Expires 23 April 2026 [Page 1] Internet-Draft Alt-Label October 2025 Copyright Notice Copyright (c) 2025 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Alternative-Label Next Hop Characteristic . . . . . . . . . . 3 2.1. Operational behavior . . . . . . . . . . . . . . . . . . 4 2.1.1. Sending Alt-Label Characteristic . . . . . . . . . . 4 2.1.2. Receiving Alt-Label Characteristic . . . . . . . . . 4 3. Extra-domain Label Type . . . . . . . . . . . . . . . . . . . 5 3.1. Sending Extra-domain label . . . . . . . . . . . . . . . 5 3.2. Receiving Extra-domain label . . . . . . . . . . . . . . 5 3.3. Application of Extra-domain labels . . . . . . . . . . . 6 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Extra-domain Label Type . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction A single MPLS label or a label stack is advertised along with an NLRI belonging to labeled address families such as Labeled Unicast [RFC8277] [RFC4798], VPN [RFC4364] [RFC4659], etc. In certain topologies, it would be useful to advertise one or more additional, alternative labels associated with the same NLRI. This document proposes a method to encode and send such alternative labels using BGP Next Hop Dependent Characteristic (NHC) attribute [I-D.ietf-idr-entropy-label]. Sethuram, et al. Expires 23 April 2026 [Page 2] Internet-Draft Alt-Label October 2025 2. Alternative-Label Next Hop Characteristic The BGP Next Hop Dependent Characteristics attribute (NHC attribute) is an optional, transitive BGP path attribute defined in [I-D.ietf-idr-entropy-label] consisting of the Next Hop address and a list of Characteristic TLVs among other things. A new Characteristic TLV Type called the Alternative-Label Characteristic is used to encode alternative labels for an NLRI. It is also referred to as Alt-Label Characteristic in this document. The encoding of the Alt-Label Characteristic TLV is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Characteristic Code | Characteristic Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Characteristic Code: Assigned by IANA to be [TBD]. Characteristic Length: Length of the Characteristic Value - set to 6. Label Type: 1 octet representing the type of alternative label. This field is assigned values from a new IANA registry called "BGP Alternative-Label Label Types". Reserved: 2 octets reserved field for future use; MUST be set to 0 when sending and SHOULD be ignored when received. Label Value: 3 octets encoding one MPLS Label [RFC3032]. This document specifies Label Type 1, called "Extra-domain Label", described in later sections. Future documents may specify newer Label Types and allocate them in the IANA registry mentioned above. As depicted above, each Characteristic TLV supports encoding of a single label only i.e., label stack encoding is not supported. Sethuram, et al. Expires 23 April 2026 [Page 3] Internet-Draft Alt-Label October 2025 2.1. Operational behavior Unless specified otherwise in this document, advertisement and receive processing of the NHC attribute and the Alt-Label Characteristic TLVs follow the general behavior outlined in [I-D.ietf-idr-entropy-label]. This section specifies the general behavior for processing any Label Type. This behavior MAY be overridden for specific Label Types by documents that specify those Types. 2.1.1. Sending Alt-Label Characteristic A router that originates a route may attach the NHC attribute containing one or more Alt-Label Characteristic TLVs. More than one such TLV may contain the same Label Type but with different label values. 2.1.2. Receiving Alt-Label Characteristic On the receiving router: * any valid label in the received Alt-Label Characteristic TLV may be installed in the corresponding route forwarding entries as the outgoing label. * if more than one valid label is received, it is a matter of local policy to decide which of those labels are installed under what conditions. * if the received route is re-advertised by the router without changing the Next Hop, the received Alt-Label Characteristic TLVs MUST be re-advertised without modification. * if the received route is re-advertised by the router setting itself as the new Nexthop: - all received Alt-Label Characteristic TLVs SHOULD be removed from the NHC attribute. - one or more new labels MAY be allocated for the route locally, and MAY be advertised encoded in Alt-Label Characteristic TLVs within the NHC attribute. Sethuram, et al. Expires 23 April 2026 [Page 4] Internet-Draft Alt-Label October 2025 3. Extra-domain Label Type This document defines a new label type called "Extra-domain Label" which is assigned a value of Label Type 1. This label type indicates that any traffic destined to that label will be forwarded to one or more next hops that belong to domain(s) that are different from where the traffic ingressed. This behavior holds true whether such next hops are part of a prefix's bestpaths or backup paths or any other alternate paths. What constitutes a "domain" is outside the scope of this document, and is defined based on local policy or configuration. One simple instance of a domain is an Autonomous System, in which case, as an example, an extra-domain label L that receives traffic from ASN-X would switch that traffic towards ASNs other than ASN-X. Other examples of a domain may be an IGP area within a single Autonomous System, or a domain spanning multiple Autonomous Systems, and so on. 3.1. Sending Extra-domain label A router may allocate one or more extra-domain labels in addition to a "primary" label associated with the same route. The primary label is encoded as part of the NLRI (for example, [RFC8277] [RFC4364] etc) while the extra-domain labels would be encoded using the Alt-Label Characteristic TLVs. 3.2. Receiving Extra-domain label On the receiving router: * the extra-domain label may be installed in the corresponding route forwarding entry as the outgoing label. Specifically this label can be installed when the route is installed as the backup path or the FRR path of a prefix. This is so that any traffic forwarded towards that label in the event of bestpaths failure will not loop back to this router. * if the received route is re-advertised without changing the Nexthop, the received label(s) MUST be re-advertised without modification. * if the received route is re-advertised by the router after setting itself as the new Nexthop: - the received label(s) MUST be removed from the NHC Alt-Label Characteristic TLV(s). Sethuram, et al. Expires 23 April 2026 [Page 5] Internet-Draft Alt-Label October 2025 - one or more new extra-domain labels MAY be allocated locally and advertised by encoding them in Alt-Label Characteristic TLVs. 3.3. Application of Extra-domain labels This section illustrates an use case where allocating an addtional label for a prefix and advertising it using the Alt-Label Characteristic TLV within the NHC attribute can help break a continuous loop of advertisements. +---------------------------------+ | | | | +----+ | | |PE3 | | | /+----+\ | | / \ | | / \ | | +----+ +----+ | | |BR1 |-------|BR2 | | | +----+ +----+ | | \ / | | \ / | | \ / | | +----+ | | |PE4 | | | +----+ | | | | +---------------------------------+ Figure 1: A pair of Border Routers backing up each other The diagram depicts two Border Routers (BR1, BR2) peering with each other, as well as two PEs (PE3, PE4). PE3 originates some VPN routes which are advertised to BR1 and BR2, which in turn advertise them to PE4. Step 0: PE3 originates VPN routes and advertises them to BR1 and BR2. Step 1: Each Border Router considers its direct path to PE3 as the bestpath and selects the other Border Router as its backup path. Step 2: Initially, BR1 receives the primary path from PE3 with label L3. Local Label L11 is allocated with context {(PE3, L3)}. This is advertised to BR2 and PE4. Sethuram, et al. Expires 23 April 2026 [Page 6] Internet-Draft Alt-Label October 2025 Step 3: Similarly, BR2 receives the primary path from PE3 with label L3. Local Label L21 is allocated with context {(PE3, L3)}. This is advertised to BR1 and PE4. Step 4: BR1 receives the update from BR2 and selects it to be the backup path. It now allocates a new local label L12 with context {(PE3, L3), (BR2, L21)}. This is advertised to BR2 and PE4. Step 5: BR2 receives the new update from BR1. It now allocates a new local label L22 with context {(PE3, L3), (BR1, L12)}. This is advertised to BR1 and PE4. Step 6: BR1 receives the new update from BR2. It now allocates a new local label L13 with context {(PE3, L3), (BR2, L22)}. This is advertised to BR2 and PE4. Step 7: BR2 receives the new update from BR1. It now allocates a new local label L23 with context {(PE3, L3), (BR1, L13)}. This is advertised to BR2 and PE4. The above operations continue forever resulting in a continuous loop of label allocations and advertisements. The solution to the above problem involves each Border Router allocating an additional label whose context points to only the bestpath without including any backup path information. Accordingly, the modified steps are described below: Step 4: BR1 receives the update from BR2 and selects it to be the backup path. It now allocates a new local label L12 with context {(PE3, L3), (BR2, L21)}. In the route advertisement to BR2 and PE4, label L12 is encoded as part of the NLRI while label L11 is encoded as an extra-domain label in Alt-Label Characteristic TLV. Step 5: BR2 receives the update from BR1 and selects it to be the backup path. It now allocates a new local label L22 with context {(PE3, L3), (BR2, L11)}. Note that BR2 uses the extra-domain label L11 received in the Alt-Label Characteristic TLV when allocating its new local label L22. In the route advertisement to BR1 and PE4, label L22 is encoded as part of the NLRI while label L21 is encoded as an extra-domain label in Alt-Label Characteristic TLV. Step 6: BR1 receives the new update from BR2. It now sees the label Sethuram, et al. Expires 23 April 2026 [Page 7] Internet-Draft Alt-Label October 2025 L21 in the Alt-Label Characeristic TLV and determines no need for a change in the already allocated label (L12) context which is {(PE3, L3), (BR2, L21)}. Hence there is no new route advertisement. 4. Error Handling In case of any errors encountered while processing Alt-Label Characteristic TLV, the error SHOULD be logged for the attention of the operator. Unless otherwise specified, the error handling specified for NHC attribute in [I-D.ietf-idr-entropy-label] should be followed. If the Length of the Alt-Label Characteristic TLV is not 6, then the TLV MUST be parsed according to the encoded length and MUST be ignored. Subsequent TLVs of the NHC attribute SHOULD continue to be parsed normally. It is not an error to receive an unrecognized Label Type value in this Characteristic TLV. Such labels MUST be processed according to Section 2.1.2. If more than one instance of a TLV with the exact same Label Type and Label value fields are received, then all but the first instance MUST be ignored. It is not an error to receive more than one TLV instance with the same Label Type but different Label values. One or more of those labels MAY be used locally, and all such labels MUST be considered for further propagation subject to the behavior specified in Section 2.1.2. 4.1. Extra-domain Label Type When receving the Extra-domain Label Type, if syntactic or semantic errors are encountered while parsing the Label field, then only that TLV MUST be ignored. It is not an error to receive more than one extra-domain label. One or more of those labels MAY be used locally, and all such labels MUST be considered for further propagation subject to the behavior specified in Section 2.1.2. The exact conditions under which a particular label may be selected for installation in local route forwarding entries is beyond the scope of this document and left to the local application. Sethuram, et al. Expires 23 April 2026 [Page 8] Internet-Draft Alt-Label October 2025 5. IANA Considerations This document requests IANA to allocate a new type code in the in the "BGP Next Hop Dependent Characteristic Codes" registry to represent "Alternative-Label Characteristic". This document requests IANA to create a new registry called "BGP Alternative-Label Label Types" with the following initial allocations. The remainder of the values in the registry are to be allocated based on a First Come, First Served policy. VALUE DESCRIPTION REFERENCE CHANGE CONTROLLER ------- ----------- --------- ----------------- 0 Reserved (this doc) IETF 1 Extra-domain Label (this doc) IETF 240-254 Private use (this doc) IETF 255 Reserved (this doc) IETF 6. Security Considerations The security considerations of the base NHC attribute described in [I-D.ietf-idr-entropy-label] continues to apply. The labels signaled using the new Alternative-Label Characteristic TLV is tightly associated with the Next Hop signaled in the NHC attribute. If this consistency is not maintained, intentionally or otherwise, it could lead to traffic mis-direction or blackholing. An implementaion MAY provide a local configuration option to disable installation and propagation of such received labels for specific address-families, specific routes, etc. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . Sethuram, et al. Expires 23 April 2026 [Page 9] Internet-Draft Alt-Label October 2025 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, DOI 10.17487/RFC4798, February 2007, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, . [I-D.ietf-idr-entropy-label] Decraene, B., Scudder, J., Kompella, K., Satya, M. R., Wen, B., Wang, K., and S. Krier, "BGP Next Hop Dependent Characteristics Attribute", Work in Progress, Internet- Draft, draft-ietf-idr-entropy-label-18, 20 July 2025, . 7.2. Informative References Sethuram, et al. Expires 23 April 2026 [Page 10] Internet-Draft Alt-Label October 2025 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, . Appendix A. Acknowledgements Authors' Addresses Shyam Sethuram Cisco Systems Email: shyam.ioml@gmail.com Mankamana Mishra Cisco Systems Email: mankamis@cisco.com Satya Ranjan Mohanty Zscaler Email: smohanty@zscaler.com Israel Means AT&T Labs, Inc. Email: im8327@att.com Praveen Ramadenu AT&T Labs, Inc. Email: pr9637@att.com Sethuram, et al. Expires 23 April 2026 [Page 11]