BIER Payload Label

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 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

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:¶

"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 <BFIR-id, sub-domain-id>.  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):¶

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.¶

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.¶

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

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

Authors' Addresses