idr Z. Zhang, Ed. Internet-Draft Juniper Networks Updates: 8296, 8402, 9573 (if approved) T. Eckert, Ed. Intended status: Standards Track Futurewei USA Expires: 11 December 2025 H. Bidgoli Nokia Z. Zhang ZTE 9 June 2025 BIER Payload Label draft-zzhang-bier-payload-label-00 Abstract The BIER Encapsulation RFC8296 specifies that the "Proto" field in the BIER header is set to 1 if an MPLS label stack follows the BIER header and the top of the stack label is a downstream-assigned label, and is set to 2 if the top of stack label is an upstream-assigned label, which is looked up in the context-specific label forwarding table that can be derived from the BIER header. The terms upstream/downstream-assignment are inappropriate to describe the required forwarding for new MPLS label semantics such as SRGB and DCB labels as defined in RFC8402 and RFC9573 respectively. This can result in potentially inconsistent implementation choices causing potential interoperability issues. This document rectifies this situation by changing the IANA BIER Next Protocol Identifier semantic for MPLS code points from their label semantic to the required LFIB in the forwarding plane, hence covering those new type of labels without changing behavior for existing upstream/downstream-assigned labels. 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/. Zhang, et al. Expires 11 December 2025 [Page 1] Internet-Draft BIER Payload Label June 2025 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 11 December 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. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Update to RFC8296 . . . . . . . . . . . . . . . . . . . . 5 2.2. Updates to RFC8402 and RFC9573 . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction BIER [RFC8279] is a multicast technology that achieves efficient replication without incurring per-flow/tunnel states inside a BIER domain. [RFC8296] specifies its encapsulation. [RFC8296] specifies: Zhang, et al. Expires 11 December 2025 [Page 2] Internet-Draft BIER Payload Label June 2025 "If the BIER payload is an MPLS packet, the BIER header is followed by an MPLS label stack. ... For an example of an application where it is useful to carry an MPLS packet as the BIER payload, see [BIER_MVPN]. If the BIER encapsulation's Proto field indicates that the payload is an MPLS packet with an upstream-assigned label at the top of the stack, the upstream-assigned label is interpreted in the context of . Note that the sub-domain-id must be inferred from the BIFT-id." The codepoints for "Proto field" in the above quote are registered in the IANA "BIER Next Protocol Identifiers" registry, with the following values for MPLS payload (among other values that are omitted here): +=======+================================+===========+ | Value | Description | Reference | +=======+================================+===========+ | 1 | MPLS packet with downstream- | [RFC8296] | | | assigned label at top of stack | | +-------+--------------------------------+-----------+ | 2 | MPLS packet with upstream- | [RFC8296] | | | assigned label at top of stack | | +-------+--------------------------------+-----------+ Table 1: Pre-existing IANA BIER Next Protocol Identifier for MPLS MPLS downstream-assigned labels are defined in [RFC3031]. [RFC5332] introduces upstream-assigned labels as a mechanism to support multicasting of MPLS packets, such that a single MPLS packet can be received by more than one LSR. To avoid the need for all receiving LSR to coordinate the assignment of such multicasted packet, the label is assigned by the upstream (sending) LSR. [RFC5331] specifies "Context-Specific Label Spaces" as the common MPLS forwarding plane mechanism to support upstream assigned MPLS label for multicast, as well as other use-cases that can not be supported by downstream-assigned labels, such as per-platform and per-interface label spaces defined in [RFC3031]. After [RFC8296] was published, which specifies BIER header Proto field values only for upstream and downstream labels, new MPLS label semantics where introduced: [RFC8402] introduced "SR Global Block" (SRGB), and [RFC9573] introduced "Domain-wide Control Block" (DCB). Hence, these new semantics of MPLS labels where not considered by [RFC8296] BIER Next Protocol Identifiers. Zhang, et al. Expires 11 December 2025 [Page 3] Internet-Draft BIER Payload Label June 2025 Both type of new MPLS labels can be multicast, aka: replicated and hence received by more than one receiver. In terms of [RFC5332] this could make them upstream-assigned. However, these MPLS labels are "globally" or rather domain-wide assigned, so there is no need for the use of a Context-Specific Label Space as required for upstream- assigned labels. In the MPLS LSR forwarding plane, such Context-Specific Label Spaces are more expensive, because they require more expensive context specific lookups of MPLS labels. Therefore it is desirable that new label semantics that can use the default label space are signalled such that they will be looked up from the default label space. Both SRGB and DCB labels where designed to use the default label space. Because the BIER Next Protocol Identifier value is meant to support (only) the necessary demultiplexing of packets in the forwarding plane on a BFER (but no further control plane semantics of the label used), it does not make sense to introduce new codepoints values for new MPLS label semantics when they are intended to share pre-existing forwarding plane semantics; specifically the default label space as used for downstream-assigned labels (codepoint 1), or a Context- Specific Label Space as used for upstream-assigned labels (codepoint 2). Additional codepoints for these cases would only complicate MPLS forwarding planes unnecessary and make introduction of new MPLS label semantics that can share these pre-existing forwarding plane demultiplexing paths unnecessary complex. For this reason, this document changes the definitions of the two existing codepoints as follows: * Code point 1 indicates a label from the default label space. It is intended to be used by all label semantics that can use the default label space. * Code point 2 indicates a label from a context-specific label space. It is intended to be used only by those label semantics that can not use code point 1 because different sending LSR in a domain may have different bindings for the same label. Both of these definitions are a superset of and hence backward- compatible with the existing definitions from [RFC5331], [RFC5332] and [RFC8296]. They are just not defining the use of the codepoints based on the the label semantics but on the LFIB required to support the semantic. Zhang, et al. Expires 11 December 2025 [Page 4] Internet-Draft BIER Payload Label June 2025 In addition, this document clarifies that SRGB and DCB labels are using the default label space and hence need to be signalled in the BIER header via codepoint 1 and how future semantics need to use existing or new BIER Next Protocol Identifier values. 2. Specification 2.1. Update to RFC8296 The Description for codepoint 1 and 2 in the IANA BIER Next Protocol Identifier table are changed as follows: +=======+=========================================+===========+ | Value | Description | Reference | +=======+=========================================+===========+ | 1 | MPLS packet with the top of stack label | [THISRFC] | | | to be looked up in the Default LFIB | | +-------+-----------------------------------------+-----------+ | 2 | MPLS packet with the top of stack label | [THISRFC] | | | to be looked up in the Context-specific | | | | LFIB for the BFIR | | +-------+-----------------------------------------+-----------+ Table 2: Updated IANA BIER Next Protocol Identifier Descriptions for MPLS Downstream-assigned labels [RFC3031], "SR Global Block" (SRGB, [RFC8402]) and "Domain-wide Control Block" (DCB), [RFC9573] label use the Default LFIB for forwarding and to thus require use of value 1. Upstream-assigned labels [RFC5331], as used by [RFC5332], [RFC8556], and [RFC9624] require the use of a context-specific LFIB and do thus require use of value 2. New semantics for MPLS labels beyond the aforementioned (upstream, downstream, SRGB, DCB) SHOULD re-use one of these two pre-existing values unless they can not co-exist with the pre-existing MPLS label semantics in the forwarding plane. In that case, a new entry needs to be alloced in the registry. 2.2. Updates to RFC8402 and RFC9573 This document specifies that "SR Global Block" (SRGB) labels as specified in [RFC8402]) and "Domain-wide Control Block" (DCB) labels as specified in [RFC9573] have to be indicated through a value of 1 (default LFIB) when used as a top op stack label in an [RFC8296] BIER packet MPLS payload. This was underspecified in both RFCs. Zhang, et al. Expires 11 December 2025 [Page 5] Internet-Draft BIER Payload Label June 2025 3. Security Considerations This document does not introduce new security concerns. 4. IANA Considerations This document requests IANA to update the codepoint 1 and 2 in the "BIER Next Protocol Identifiers" registry as specified above in Table 2. 5. Acknowledgments 6. References 6.1. Normative References [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, . [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, . [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non- MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC9573] Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands, "MVPN/EVPN Tunnel Aggregation with Common Labels", RFC 9573, DOI 10.17487/RFC9573, May 2024, . Zhang, et al. Expires 11 December 2025 [Page 6] Internet-Draft BIER Payload Label June 2025 6.2. Informative References [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, DOI 10.17487/RFC5332, August 2008, . [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., and A. Dolganow, "Multicast VPN Using Bit Index Explicit Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 2019, . [RFC9624] Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan, "EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Using Bit Index Explicit Replication (BIER)", RFC 9624, DOI 10.17487/RFC9624, August 2024, . Authors' Addresses Zhaohui Zhang (editor) Juniper Networks Email: zzhang@juniper.net Toerless Eckert (editor) Futurewei USA Email: tte@cs.fau.de Hooman Bidgoli Nokia Email: hooman.bidgoli@nokia.com Zheng Zhang ZTE Email: zhang.zheng@zte.com.cn Zhang, et al. Expires 11 December 2025 [Page 7]