| Internet-Draft | Unmasked BIER Mode | October 2026 |
| Przygienda, et al. | Expires 3 May 2027 | [Page] |
The document introduces a new mode of interpretation of the bitmask field in the BIER encoding, called unmasked BIER, that solves the problem of BIER originator targeting receivers across many different sets and hence, in worst case, degrading into ingress replication.¶
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 3 May 2027.¶
Copyright (c) 2026 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.¶
BIER technology [RFC8296] in its standard form may suffer from a degradation towards ingress replication in a scenario where the total number of involved BFRs is very large but most packets address varying combination of relatively few receivers spread across different sets.¶
More explicitly, BIER carries in its standard form a bitmask of successive BFR receivers represented as bits in a set and thus on large numbers of involved BFRs and few receivers w/o customized allocation of BFR IDs or application awareness of the address locality each receiver on a packet may be found in a different set in most extreme cases. Obviously, when receivers are in different sets, multiple packets MUST be sent, one per involved set. Such a scenario can become common in large distributed computation environments based on consensus building algorithms (or building closures by successive folding of results), e.g. multi-CPU HPC or data centers and RAID storage where storing data while addressing large number of always changing stripes can lead to this kind of anomaly.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
To deal with the problem of small number of receivers spread across many sets we introduce into BIER a special interpretation of the bitmask field called unmasked BIER or U-BIER for brevity's sake. U-BIER bitmask is interpreted as sequence of BFR-IDs that can belong to different sets and be interspersed with "holes" consisting of illegal BFR-IDs to increase hardware processing efficiency.¶
Each BFR-ID occupies 2 octets. The number of destination BFR-IDs encapsulated in each message depends on the length of the BSL. When the BSL is 64 bits, 4 BFR-IDs can be encapsulated; when the BSL is 256 bits, 16 BFR-IDs can be encapsulated, and so on. When the number of discrete receivers exceeds the number that can be encapsulated in a single message, multiple message encapsulation can be used. For example, if the BSL is 256 bits but 32 destination BFR-IDs need to be encapsulated, 16 destination BFR-IDs can be encapsulated in each message, resulting in 2 messages.¶
Support for processing of unmasked BIER is indicated by signalling special label or its equivalent analogous to BIER Encapsulation signalling. Based on this info the upstream node can decide on a hop-by-hop basis whether it compresses the same BIER frames it received for different sets (how the recognition of same frames is performed is outside the scope of this document) into a single U-BIER frame or propagates a U-BIER frame with according changes, i.e. only providing the BFR-IDs for which the receiver is responsible. The removal of BFR IDs from the packet before forwarding it is completely analogous to the normal bitmask processing in a sense but here spanning possibly many sets in the lookup engine. In case the downstream receiver does not support U-BIER the frame needs to be replicated into according standard BIER frames with usual bitmask interpretation.¶
The following is an example of U-BIER encapsulation. Suppose there are 8 discrete BFR-IDs that need to be encapsulated into a U-BIER header. BFR-ID1~8 represent 8 destinations respectively.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIFT-id | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nibble | Ver | BSL | Entropy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OAM|Rsv| DSCP | Proto | BFIR-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFR-ID1 | BFR-ID2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFR-ID3 | BFR-ID4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFR-ID5 | BFR-ID6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFR-ID7 | BFR-ID8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
In this example, the number of encapsulated BFR-IDs is less than 16, the BFR-IDs are encoded at the end of the BitString, and the unused BitStrings are set to 0. Encoding the BFR-IDs at the end makes it easier to determine if there are more BFR-IDs to check, as a BFR-ID may be cleared during the forwarding iteration (see below).¶
The bitmask field MUST be interpreted in U-BIER mode as sequence of BFR-IDs (as an example, within 256 bits maximum 16 receivers can be encoded) whereas illegal BFR-IDs are allowed in any position and MUST be ignored. Duplicates are also allowed and MUST be treated as a single occurrence. No guarantees are provided in terms of sorting of the BFR-IDs in U-BIER.¶
Conceptually and over-simplified, a BFR checks the BFR-IDs in the incoming BitString one by one. The lookup of a BFR-ID produces a next hop, and the rest of BFR-IDs are scanned. Any BFR-ID covered by the next hop's F-BM are moved into the copy of the packet sent to the next hop, and cleared from the incoming packet. The process iterates until no more BFR-IDs are present in the incoming BitString.¶
For the regular BIER, the reference model is that BIFTs for the same (SD, BSL) but different sets are separate. An implemenation may be different - it could have a single BIFT for all the sets of the same (SD, BSL) and the lookup of a bit index happens in the appropriate section of that single table. This document follows the reference model because it is desired to have U-BIER and regular BIER co-exist and share the infrastructure as much as possible, while an implementation could still be different. Note that the F-BM checked for coverage of more BFR-IDs now is a combined set of all F-BMs for all the sets.¶
An implementation may also preprocess the BFR-IDs into a BitString and then follow the regular BIER forwarding. When a copy is sent, it may use regular BIER encoding (with a true BitString) or use U-BIER encoding (with individual BFR-ID encoded in the BitString).¶
The following sub-section will describe the extensions of IS-IS, OSPF, and BGP protocols in MPLS and non-MPLS scenarios, respectively.¶
The signalling follows the BIER MPLS Encapsulation Sub-sub-TLV [RFC8401], i.e. it is <SD, SI, BSL> specific but obviously does not include the concept of a set.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |BS Len | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...¶
Type: TBD1¶
Length: 4 * of U-Mode BitString Length specific labels.¶
Reserved: MUST be 0 on send and ignored on reception.¶
BS Len: BitString Length. A 4-bit field encoding the supported BitString length associated with this BFR-prefix using the exponential encoding defined in section 2.1.2 [RFC8296].¶
Label: Frames received on this label interpret the BitMask as U-BIER.¶
In case multiple values are advertised for same bitstring length, the sub-sub-TLV MUST be ignored. In case same label value is advertised for different bitstring lengths, the sub-sub-TLV MUST be ignored.¶
Label values MUST NOT match any of the reserved values defined in [RFC3032].¶
The signalling follows the IS-IS BIER non-MPLS Encapsulation Sub-sub-TLV [I-D.ietf-bier-lsr-non-mpls-extensions], excluding the SI.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |BS Len | BIFT-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...¶
Type: TBD2¶
Length: 4 octets.¶
Reserved: MUST be 0 on send and ignored on reception.¶
BS Len: BitString Length. A 4-bit field encoding the supported BitString length associated with this BFR-prefix using the exponential encoding defined in section 2.1.2 [RFC8296].¶
BIFT-ID: A 20 bit field encoding the BIFT-id.¶
In case multiple values are advertised for same bitstring length, the sub-sub-TLV MUST be ignored. In case same BIFT-ID value is advertised for different bitstring lengths, the sub-sub-TLV MUST be ignored.¶
The signalling follows the BIER MPLS Encapsulation Sub-TLV [RFC8444], excluding the SI.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |BS Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Type: TBD3¶
Length: 8 octets.¶
Reserved: MUST be 0 on send and ignored on reception.¶
BS Len: BitString Length. A 4-bit field encoding the supported BitString length associated with this BFR-prefix using the exponential encoding defined in section 2.1.2 [RFC8296].¶
Label: Frames received on this label interpret the BitMask as U-BIER.¶
In case multiple values are advertised for same bitstring length, the sub-TLV MUST be ignored. In case same label value is advertised for different bitstring lengths, the sub-TLV MUST be ignored.¶
Label values MUST NOT match any of the reserved values defined in [RFC3032].¶
The signalling follows the OSPFv2 BIER non-MPLS Encapsulation Sub-TLV [I-D.ietf-bier-lsr-non-mpls-extensions], excluding the SI.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | BIFT-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |BS Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Type: TBD4¶
Length: 8 octets.¶
Reserved: MUST be 0 on send and ignored on reception.¶
BS Len: BitString Length. A 4-bit field encoding the supported BitString length associated with this BFR-prefix using the exponential encoding defined in section 2.1.2 [RFC8296].¶
BIFT-ID: A 20 bit field encoding the BIFT-ID.¶
In case multiple values are advertised for same bitstring length, the sub-TLV MUST be ignored. In case same BIFT-ID value is advertised for different bitstring lengths, the sub-TLV MUST be ignored.¶
The signalling follows the BIER MPLS Encapsulation Sub-TLV [I-D.ietf-bier-ospfv3-extensions], excluding the SI.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|BS Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
Type: TBD5¶
Length: 8 octets.¶
Reserved: MUST be 0 on send and ignored on reception.¶
BS Len: BitString Length. A 4-bit field encoding the supported BitString length associated with this BFR-prefix using the exponential encoding defined in section 2.1.2 [RFC8296].¶
Label: Frames received on this label interpret the BitMask as U-BIER.¶
In case multiple values are advertised for same bitstring length, the sub-TLV MUST be ignored. In case same label value is advertised for different bitstring lengths, the sub-TLV MUST be ignored.¶
Label values MUST NOT match any of the reserved values defined in [RFC3032].¶
The signalling follows the OSPFv3 BIER non-MPLS Encapsulation Sub-TLV [I-D.ietf-bier-lsr-non-mpls-extensions], excluding the SI.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD6 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | BIFT-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |BS Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Type: TBD6¶
Length: 8 octets.¶
Reserved: MUST be 0 on send and ignored on reception.¶
BS Len: BitString Length. A 4-bit field encoding the supported BitString length associated with this BFR-prefix using the exponential encoding defined in section 2.1.2 [RFC8296].¶
BIFT-ID: A 20 bit field encoding the BIFT-ID.¶
In case multiple values are advertised for same bitstring length, the sub-TLV MUST be ignored. In case same BIFT-ID value is advertised for different bitstring lengths, the sub-TLV MUST be ignored.¶
The signalling follows the BIER MPLS Encapsulation Sub-TLV [RFC9793], excluding the SI.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =TBD7 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |BS Len | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
Type: TBD7¶
Length: 2 octets encoding the length in octets of the Value part. The value is 4 or other (depending on sub-TLVs).¶
Reserved: MUST be 0 on send and ignored on reception.¶
BS Len: BitString Length. A 4-bit field encoding the supported BitString length associated with this BFR-prefix using the exponential encoding defined in section 2.1.2 [RFC8296].¶
Label: Frames received on this label interpret the BitMask as U-BIER.¶
In case multiple values are advertised for same bitstring length, the sub-TLV MUST be ignored. In case same label value is advertised for different bitstring lengths, the sub-LV MUST be ignored.¶
Label values MUST NOT match any of the reserved values defined in [RFC3032].¶
The signalling follows the BIER non-MPLS Encapsulation Sub-TLV [RFC9793], excluding the SI.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD8 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |BS Len | BIFT-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
Type: TBD8¶
Length: 2 octets encoding the length in octets of the Value part. The value is 4 or other (depending on sub-TLVs).¶
Reserved: MUST be 0 on send and ignored on reception.¶
BS Len: BitString Length. A 4-bit field encoding the supported BitString length associated with this BFR-prefix using the exponential encoding defined in section 2.1.2 [RFC8296].¶
BIFT-ID: A 20 bit field encoding the BIFT-id.¶
In case multiple values are advertised for same bitstring length, the sub-TLV MUST be ignored. In case same BIFT-ID value is advertised for different bitstring lengths, the sub-TLV MUST be ignored.¶
U-BIER can be deployed within existing BIER node by node, either as addition or the only mode supported. Observe that in an environment where only some nodes support U-BIER those may have to disaggregate U-BIER into normal BIER and hence fall back to average replication. In a network where some nodes support only U-BIER normal BIER nodes may consider them not supporting BIER at all or may perform translation from normal BIER into U-BIER frames, however, it MUST be expected that they will use a single frame and basically send U-BIER with the BFR IDs of a single set only, not rendering any gains unless a mechanism is in place the same frame is detected sent on multiple sets and coalesced into a single U-BIER frame. This can be achieved by many mechanisms out the scope of this draft, amongst them a shim after the BIER encapsulation [I-D.zzhang-bier-extension-headers] in way similar to inband telemetry or fragmentation support.¶
Mixing U-BIER and normal BIER within a subdomain can lead to difficulties of decoding the according packets in the middle in terms of destinations targeted if the involved parties in the middle do not possess the correct binding information. An obvious method to deal with this problem is to deploy U-BIER specifically in its own sub-domain where the interpretation of the bitmask is unambiguous.¶
TBD¶
The document requests new allocations from the IANA registries as follows:¶
U-Mode BIER MPLS Encapsulation Sub-sub-TLV: TBD1¶
U-Mode BIER non-MPLS Encapsulation Sub-sub-TLV: TBD2¶
U-Mode BIER MPLS Encapsulation Sub-TLV: TBD3¶
U-Mode BIER non-MPLS Encapsulation Sub-TLV: TBD4¶
U-Mode BIER MPLS Encapsulation Sub-TLV: TBD5¶
U-Mode BIER non-MPLS Encapsulation Sub-TLV: TBD6¶
U-Mode BIER MPLS Encapsulation Sub-TLV: TBD7¶
U-Mode BIER non-MPLS Encapsulation Sub-TLV: TBD8¶
Michael Menth and Toerless Eckert mentioned the problem and approaches to address it in open forums for the first time.¶