RFC 9793

BGP Extensions for Bit Index Explicit Replication (BIER)

📅 published June 2025, from ietf

RFC 9793 📡 BGP Extensions for Bit Index Explicit Replication (BIER) 🦋

Okay bestie, here's the title block in plain English 💖 This is an Internet Standards Track doc from the IETF, published in June 2025, with ISSN 2070-1721. The authors are X. Xu (China Mobile), M. Chen (Huawei), K. Patel (Arrcus, Inc.), IJ. Wijnands (Individual), T. Przygienda, and Z. Zhang, Ed. (Juniper). The title block doesn't list anything it obsoletes or updates ✨

Abstract

Okay so, Bit Index Explicit Replication (BIER) is a multicast forwarding architecture 🌸 It doesn't need an explicit tree-building protocol, and the middle routers don't have to keep per-tree multicast state, which is so iconic. Some BIER info and state still needs to be advertised, calculated, and maintained. It scales with the number of BIER routers, not with the number of trees, so it's not nothing 👀 This document describes the BGP extensions that advertise that BIER info, plus the methods for calculating BIER state from those advertisements 💅

Status of This Memo

This is an Internet Standards Track document 🎀

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841 ✨

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9793 🦋

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.  Terminology
  2.1.  Requirements Language
3.  BIER Path Attribute
  3.1.  BIER MPLS Encapsulation Sub-TLV
  3.2.  BIER Non-MPLS Encapsulation Sub-TLV
  3.3.  BIER Nexthop Sub-TLV
4.  Originating/Propagating/Updating the BIER Attribute
5.  BIFT Calculation with BGP Signaling
6.  Example of BIER Nexthop Usage and Handling
7.  Operational Considerations
8.  IANA Considerations
9.  Security Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 🌈

So BIER [RFC8279] is a multicast forwarding architecture that doesn't need an explicit tree-building protocol, and intermediate routers don't have to keep per-tree multicast state. It supports both direct and tunneled BIER forwarding 🚀 This document describes the BGP extensions for advertising BIER info and the methods for calculating BIER state from those advertisements.

The main character here is a new optional transitive BGP attribute called the "BIER attribute" 👑 It carries BIER-specific info like the Bit-Forwarding Router Identifier (BFR-ID), the BitStringLength (BSL), and more. The signaling is meant for a single Administrative Domain (AD). Section 7 has the procedures that stop the BIER attribute from "leaking out" of the domain, so no oversharing 🙈

2. Terminology 📖

This document uses terminology defined in [RFC4271] and [RFC8279]. Here are some terms for convenience 💖

  • BIER: Bit Indexed Explicit Replication
  • BFR: Bit-Forwarding Router
  • BFR-ID: BFR Identifier
  • BSL: BitStringLength
  • BIFT: Bit Index Forwarding Table
  • BIFT-id: Bit Index Forwarding Table Identifier
  • BFER: Bit-Forwarding Egress Router
  • BFR-prefix: Each BFR is assigned a single "BFR-prefix" for each sub-domain it belongs to. It is recommended that the BFR-prefix be a loopback address of the BFR. 🌸
  • NLRI: Network Layer Reachability Information [RFC4271]
  • AFI: Address Family Identifier [RFC4760]
  • SAFI: Subsequent Address Family Identifier [RFC4760]

2.1. 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. This is the one spot where the capitals are the whole point 🫶

3. BIER Path Attribute 🎀

This specification defines an optional, transitive BGP path attribute called the "BIER attribute". The originator can attach it to a BGP UPDATE message for NLRIs of AFI 1 or 2 and SAFI 1, 2, or 4. It indicates the BIER-specific info of a particular BFR, identified by the /32 (for IPv4) or /128 (for IPv6) host address prefix in the NLRI 🦋 Attaching the BIER attribute to non-host address prefixes isn't defined by this document. It may be specified in the future, for example, by [BIER-Prefix-Redistribute] 👀

If the BIER path attribute is present, the NLRI is called a "BFR-prefix". Using the attribute with other AFIs/SAFIs is outside the scope of this document 🙅‍♀️

The BIER path attribute is an optional, transitive BGP path attribute with type code 41 and variable length. Its value portion carries BIER TLVs, laid out like this:

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                        Value (variable)                       ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Length field is the length of the value portion in octets, so a TLV with no value portion has a length of zero. The TLV is not padded to 4-octet alignment. Unknown and unsupported types MUST be preserved and propagated within the BIER attribute. Unknown or unexpected TLVs MUST NOT make the NLRI or the BIER attribute count as malformed 🧚

When a BFR creates a BIER attribute, it MUST include one BIER TLV for every sub-domain the prefix belongs to. The attribute type code is 41. The value field contains one or more BIER TLVs, shaped like this:

       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 = 1            |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Sub-domain   |            BFR-ID             |   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                                                               ~
      |                           Sub-TLVs                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................

Here's what each field means 💅

  • Type: 1
  • Length: 2 octets encoding the length in octets of the Value part.
  • Sub-domain: A 1-octet field encoding the sub-domain ID corresponding to the BFR-ID (see [RFC8279]).
  • BFR-ID: A 2-octet field encoding the BFR-ID (see [RFC8279]).
  • Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. 🫧
  • Sub-TLVs: Contains one or more sub-TLVs.

The BIER TLV MAY appear multiple times in the BIER path attribute, one for each sub-domain. There MUST be no more than one BIER TLV with the same Sub-domain value. If there is, the entire BIER path attribute MUST be ignored 🚫

A BIER TLV can have sub-TLVs, and those sub-TLVs can have their own sub-TLVs. They're all called sub-TLVs and share the same Type space, no matter the level. Not confusing at all, I promise 🙃

3.1. BIER MPLS Encapsulation Sub-TLV 🌸

The BIER MPLS Encapsulation sub-TLV has the following format. It MAY appear multiple times in the BIER TLV. 💖

Its layout looks like this:

       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 = 2            |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Max SI    |BS Len |             Label                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                        sub-TLVs                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields, explained 🍓

  • Type: 2
  • Length: 2 octets encoding the length in octets of the Value part. The value is 4 or other (depending on sub-TLVs).
  • Max SI: A 1-octet field encoding the Maximum Set Identifier (see Section 1 of [RFC8279]) used in the encapsulation for this BIER sub-domain for this BitString length.
  • BS Len: BitString Length. A 4-bit field encoding the supported BitString length associated with this BFR-prefix. The values allowed in this field are specified in Section 2 of [RFC8296].
  • Label: A 20-bit value representing the first label in the label range.

The "label range" is the set of labels starting at the Label and ending at (Label + (Max SI)). A unique label range is allocated for each BitString length and sub-domain-id. These labels are used for BIER forwarding, as described in [RFC8279] and [RFC8296] ✨

The size of the label range depends on the number of SIs (Section 1 of [RFC8279]) used in the network. Each SI maps to one label in the range: the first label is for SI=0, the second label is for SI=1, and so on 🦋

If the label associated with the Maximum SI goes past the 20-bit range, the BIER MPLS Encapsulation sub-TLV containing the error MUST be ignored. 🚨

If the same BitString length is repeated across multiple BIER MPLS Encapsulation sub-TLVs inside the same BIER TLV, all BIER MPLS Encapsulation sub-TLVs in that BIER TLV MUST be ignored. Yikes 💀

Label ranges within all BIER MPLS Encapsulation sub-TLVs advertised by the same BFR MUST NOT overlap. If an overlap is detected, all BIER MPLS Encapsulation sub-TLVs advertised by that BFR MUST be ignored. No label collisions allowed, bestie 🔥

3.2. BIER Non-MPLS Encapsulation Sub-TLV 🦋

okay so the BIER non-MPLS Encapsulation sub-TLV is the one used for non-MPLS encapsulation, and it has its own format 💅 It MAY appear multiple times within a single BIER TLV. If the same BitString length is repeated in multiple BIER non-MPLS Encapsulation sub-TLVs inside the same BIER TLV, the BIER TLV MUST be ignored. no exceptions, bestie 🙈

    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 = 3            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Max SI    |BS Len |                  BIFT-id              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        sub-TLVs                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 3 🌸

Length: 2 octets encoding the length in octets of the Value part. The value is 4 or other (depending on sub-TLVs). ✨

Max SI: A 1-octet field encoding the Maximum Set Identifier (Section 1 of [RFC8279]) used in the encapsulation for this BIER sub-domain for this BitString length. The first BIFT-id is for SI=0, the second BIFT-id is for SI=1, etc. If the BIFT-id associated with the Maximum SI exceeds the 20-bit range, the sub-TLV MUST be ignored. 💀

BS Len: BitString Length. A 4-bit field encoding the BitString length (as per [RFC8296]) supported for the encapsulation.

BIFT-id: A 20-bit field representing the first BIFT-id in the BIFT-id range.

The "BIFT-id range" is the set of 20-bit values beginning with the BIFT-id and ending with (BIFT-id + (Max SI)). These BIFT-ids are used for BIER forwarding, as described in [RFC8279] and [RFC8296]. 🦋

The size of the BIFT-id range is determined by the number of SIs (Section 1 of [RFC8279]) that are used in the network. Each SI maps to a single BIFT-id in the BIFT-id range: the first BIFT-id is for SI=0, the second BIFT-id is for SI=1, etc. so the range literally grows with your network 📈

If the BIFT-id associated with the Maximum SI exceeds the 20-bit range, the BIER non-MPLS Encapsulation sub-TLV containing the error MUST be ignored. the whole sub-TLV gets tossed, no second chances 🙅‍♀️

BIFT-id ranges within all the BIER non-MPLS Encapsulation sub-TLVs advertised by the same BFR MUST NOT overlap. If an overlap is detected, all the BIER non-MPLS Encapsulation sub-TLVs advertised by the BFR MUST be ignored. However, the BIFT-id ranges may overlap across different encapsulation types and that is allowed. As an example, the BIFT-id value in the non-MPLS Encapsulation sub-TLV may overlap with the Label value in the Label range in the BIER MPLS Encapsulation sub-TLV. the overlap rule is per encapsulation family, so cross-type overlap is totally fine 🫶

3.3. BIER Nexthop Sub-TLV 🍓

The BIER Nexthop sub-TLV MAY be included, and it MUST NOT be included more than once in each of the MPLS or non-MPLS Encapsulation sub-TLVs or in the top-level BIER TLV. It is used when calculating BIFT entries, as described in Section 5 and illustrated in Section 6. ✨

    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 = 4           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Nexthop                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 4 🧚

Length: 2 octets. The value is 4 if the Nexthop is an IPv4 address and 16 if the Nexthop is an IPv6 address.

Nexthop: 4 or 16 octets of an IPv4/IPv6 address.

4. Originating/Propagating/Updating the BIER Attribute 🔥

A Bit-Forwarding Egress Router (BFER) MUST attach a BIER attribute to its own /32 (for IPv4) or /128 (for IPv6) host BFR-prefix NLRI. The BIER attribute MUST include one BIER TLV for each BIER sub-domain that it supports. Each BIER TLV MUST include an MPLS and/or non-MPLS Encapsulation sub-TLV and MAY include a BIER Nexthop sub-TLV with the Nexthop set to the BIER prefix. If the BIER Nexthop sub-TLV is not included, the BIER prefix will be used by receiving BFRs as the BIER next hop when calculating BIFT. 👑

When a BFR receives an update with the BIER path attribute, the attribute is parsed with the following validations:

  • Syntactic checking based on the Length field of TLVs and sub-TLVs:
    • The total length of BIER TLVs (including the Type and Length fields) MUST be equal to the BIER path attribute length.
    • The total length of sub-TLVs (including the Type and Length fields) of a TLV MUST be equal to the length of the TLV.
  • Semantic checking as per Section 3.

If the syntactic checking fails, the attribute is considered malformed and the "attribute discard" action [RFC7606] for the BIER attribute MUST be taken. If the semantic checking passes, BIFT entries are calculated as described in Section 5. Otherwise (i.e., if semantic checking fails), some or all BIER TLVs are ignored, per the rules given in Section 3, and if the remaining data permits, BIFT entries are calculated per Section 5. 😭

When a BFR re-advertises a BGP NLRI with a BIER attribute, for the sub-domains that this BFR supports, in the corresponding BIER TLV, it SHOULD set/update the BIER Nexthop sub-TLV to use its own BIER prefix; in which case, it MUST replace the MPLS or non-MPLS Encapsulation sub-TLV with its own, i.e., as if the BFR is attaching the encapsulation sub-TLV for its own BIER prefix. If it does not update the BIER Nexthop sub-TLVs, it MUST NOT update the MPLS or non-MPLS Encapsulation sub-TLV. If it does not support a sub-domain, it MUST NOT update the corresponding BIER TLV. the re-advertising rules are very much "don't touch what you don't own" 🙈

It's possible that the BFR supports some but not all BitStringLengths (BSLs) in the received MPLS or non-MPLS Encapsulation sub-TLVs. After setting/updating the BIER Nexthop sub-TLV in the top BIER TLV to itself, for the BSLs that it does support, the BFR MUST remove the BIER Nexthop sub-TLV (if present) in the corresponding Encapsulation sub-TLVs. For the BSLs that it does not support:

  • If a BIER Nexthop sub-TLV is included in the Encapsulation sub-TLV, it MUST NOT be updated.
  • Otherwise, if a BIER Nexthop sub-TLV is included in the received BIER TLV, its original value (before changed for supported BSLs by this BFR) MUST be copied into the Encapsulation sub-TLV.
  • Otherwise, a BIER Nexthop sub-TLV MUST be added to the Encapsulation sub-TLV with its value set to the BFR-prefix.

All impacted Length fields (e.g., the Encapsulation sub-TLV Length and the top-level BIER TLV Length) MUST be updated accordingly. 📏

Since the BIER attribute is an optional, transitive BGP path attribute, a non-BFR BGP speaker could still re-advertise the received route with a BIER attribute. 🌈

Two different BFR-prefixes MUST NOT have the same non-zero BFR-ID in the same sub-domain. If a duplication is detected, the receiving BFR MUST NOT use the BFR-prefixes with the same BFR-ID for BIFT calculation for the sub-domain and an error SHOULD be logged. duplicate IDs are a big no, babe 💅

5. BIFT Calculation with BGP Signaling 🧠

As pointed out in [RFC8279], BIFTs are derived from the unicast FIB by adding BIER-specific information. 🦋

For each sub-domain, a BFR calculates the corresponding BIFTs by going through the BIER prefixes whose BIER attribute includes a BIER TLV for the sub-domain. For a non-zero BFR-id in the BIER TLV, a BIFT entry is created or updated. The entry's BFR Neighbor (BFR-NBR) [RFC8279] is the Nexthop in the BIER Nexthop sub-TLV in the corresponding Encapsulation sub-TLV or in the top-level BIER TLV if the Encapsulation sub-TLV does not have a BIER Nexthop sub-TLV. If there is no BIER Nexthop sub-TLV at all, the entry's BFR-NBR is the BIER prefix itself. The BIER label or BIFT-id for the entry is derived from the label range in the MPLS Encapsulation sub-TLV or from the BIFT-id range in the non-MPLS Encapsulation sub-TLV. ✨

BIER traffic is sent to the BFR-NBR either directly (BIER header directly follows a Layer 2 header) if the BFR-NBR is directly connected or via a tunnel. Notice that, if a non-BFR BGP speaker re-advertises a BIER prefix (in this case, it cannot update the BIER attribute since it is not capable), or if a BFR BGP speaker re-advertises a BIER prefix without updating the BIER Nexthop sub-TLV, the BFR receiving the prefix will tunnel BIER traffic -- the BGP speaker re-advertising the BIER prefix will not see the BIER traffic for the BIER prefix. 👀

How the tunnel is set up and chosen is outside the scope of this document. It can be any kind of tunnel, e.g., MPLS Label Switched Path or IP/GRE, as long as the tunnel header can indicate that the payload is BIER. 🎀

6. Example of BIER Nexthop Usage and Handling 🌸

Consider a simple topology as follows:

                                     ----- BFER1
                                    /
          BFR1 --- non-BFR --- BFR2 ------ BFER2
                                    \
                                     ----- BFER3

The BFER1/2/3 each advertises a route for its loopback address with a BIER path attribute, listing one BIER TLV for each sub-domain that it is in, with a non-zero BFR-ID and an MPLS Encapsulation sub-TLV. A BIER Nexthop sub-TLV is not included in the one from BFER1 but is included in the ones from BFER2/3. The BIER Nexthop sub-TLV encodes the BFR-prefix of BFER2 and BFER3, respectively. 🍓

When BFR2 receives the route, it calculates its BIFT entries. Because the route from BFER1 does not include a BIER Nexthop, BFR2 uses BFR1's BFR-prefix as the next hop. 🧚

When BFR2 re-advertises the routes to the non-BFR, it adds a BIER Nexthop sub-TLV to the BFER1 route and updates the BIER Nexthop sub-TLV in the BFER2/3 routes, all encoding BFR2's own address. It also updates the MPLS Encapsulation sub-TLV to encode its own labels. 💜

When the non-BFR receives the routes, since it does not support BIER, no BIER-specific action is taken and the routes are re-advertised to BFR1 with the BIER path attribute unchanged. 🙃

When BFR1 receives the routes, it calculates the BIFT entries, using BFR2's address encoded in the BIER Nexthop sub-TLV as the next hop. Because BFR2 is not directly connected, a tunnel must be used. the whole thing is basically a relay race of Nexthop TLVs 🏃‍♀️💨

7. Operational Considerations ✨

okay so first things first 🎀 this doc assumes the BIER domain [RFC8279] lines up with an Administrative Domain (AD), and an AD can be made of multiple Autonomous Systems. using the BIER attribute in any other setup is outside the scope of this doc, so we're not going there 🙅‍♀️

BFR-prefixes are usually loopback addresses on the BFRs 🦋 they get distributed all over the AD, but they don't need to be distributed outside the AD for BIER's purposes. it's kinda the same energy as Provider Edge routers' loopback addresses, which also get shared inside the AD but don't need to leave it 💅

now the spicy part 🌶️ if prefixes get distributed outside the AD with the BIER attribute attached, AND the neighboring AD is also deploying BIER, then the two BIER domains could get accidentally joined together. they're supposed to be independent of each other, so this is a huge mess 😭 they'd most likely end up with conflicting configurations, which causes security risks and operational troubles. not cute!!

so to prevent that 🛡️ a boundary router of the AD that supports the BIER attribute MUST support a policy based on an External BGP (EBGP) session/group that indicates whether the attribute is allowed. by default, it is NOT allowed. if it's not allowed, the BIER attribute MUST NOT be sent to any EBGP peer of that session/group. and if a BIER attribute comes in from a peer, it MUST be treated exactly as if it were an unrecognized non-transitive attribute. which means it MUST be quietly ignored and not passed along to other BGP peers 🫶

the key takeaway: the BIER attribute stays inside its own AD by default. don't let it leak across the border, bestie 🚧

8. IANA Considerations 🌸

IANA has assigned codepoint 41 to the BIER attribute in the "BGP Path Attributes" registry <https://www.iana.org/assignments/bgp-parameters> like this:

                       +=======+======+===========+
                       | Value | Code | Reference |
                       +=======+======+===========+
                       | 41    | BIER | RFC 9793  |
                       +-------+------+-----------+

Table 1

IANA has also created the "BGP BIER TLV and Sub-TLV Types" registry within the "Border Gateway Protocol (BGP) Parameters" registry group 🍓 the type field for this registry is 2 octets, with possible values from 0 to 65535 (the value 0 is reserved). the allocation policy for this field is First Come First Served [RFC8126].

the five initial values were allocated like so 💖

         +=========+================================+===========+
         | Value   | Name                           | Reference |
         +=========+================================+===========+
         | 0       | Reserved                       | RFC 9793  |
         +---------+--------------------------------+-----------+
         | 1       | BIER TLV                       | RFC 9793  |
         +---------+--------------------------------+-----------+
         | 2       | MPLS Encapsulation sub-TLV     | RFC 9793  |
         +---------+--------------------------------+-----------+
         | 3       | non-MPLS Encapsulation sub-TLV | RFC 9793  |
         +---------+--------------------------------+-----------+
         | 4       | BIER Nexthop sub-TLV           | RFC 9793  |
         +---------+--------------------------------+-----------+
         | 5-65535 | Unassigned                                 |
         +---------+--------------------------------------------+

Table 2

9. Security Considerations 🔐

okay this one is lowkey the most important section 😭 this document introduces no new security considerations beyond those already discussed in [RFC4271], [RFC8279], and the operational considerations (Section 7) of this document. so go read those too, periodt 💀

10. References 📚

10.1. Normative References

10.2. Informative References

Acknowledgements 🫶

Thanks to Eric Rosen and Peter Psenak for their valuable comments on this document 💜

Contributors 🌈

This document has the following contributor:

Zheng (Sandy) Zhang
ZTE
Email: zhang.zheng@zte.com.cn

Authors' Addresses ✨

Xiaohu Xu
China Mobile
Email: xuxiaohu@cmss.chinamobile.com

Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com

Keyur Patel
Arrcus, Inc.
Email: keyur@arrcus.com

IJsbrand Wijnands
Individual
Email: ice@braindump.be

Tony Przygienda
Juniper
Email: prz@juniper.net

Zhaohui Zhang (editor)
Juniper
Email: zzhang@juniper.net
📦 where this page comes from