RFC 8401

Bit Index Explicit Replication (BIER) Support via IS-IS

📅 published June 2018, from ietf

RFC 8401: Bit Index Explicit Replication (BIER) Support via IS-IS ✨

Title block (the important facts, bestie): 📋

Series: IETF, RFC 8401 🎀
Category: Standards Track 🦋
Date: June 2018 🌸
ISSN: 2070-1721
Authors: L. Ginsberg, Ed. (Cisco Systems), A. Przygienda (Juniper Networks), S. Aldrin (Google), and J. Zhang (Juniper Networks, Inc.) 👑
Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🧚

Abstract

okay so this doc is all about adding IS-IS extensions that support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture 💖 It's basically the routing-protocol glue that makes BIER work ✨

Status of This Memo

this one is an Internet Standards Track document 🔥

it's a product of the Internet Engineering Task Force (IETF), which means it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want the deets on Internet Standards, check out Section 2 of RFC 7841 🫶

for the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8401 🌈

Copyright Notice

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜

also, any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License 🦋

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
  2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
4.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
  4.1.  BIER Domains and Subdomains . . . . . . . . . . . . . . .   5
  4.2.  Advertising BIER Information  . . . . . . . . . . . . . .   5
5.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  5.1.  Multi-Topology and Subdomain  . . . . . . . . . . . . . .   5
  5.2.  BFR-id Advertisements . . . . . . . . . . . . . . . . . .   6
  5.3.  Logging Misconfiguration  . . . . . . . . . . . . . . . .   6
  5.4.  Flooding Reduction  . . . . . . . . . . . . . . . . . . .   6
6.  Packet Formats  . . . . . . . . . . . . . . . . . . . . . . .   7
  6.1.  BIER Info Sub-TLV . . . . . . . . . . . . . . . . . . . .   7
  6.2.  BIER MPLS Encapsulation Sub-sub-TLV . . . . . . . . . . .   8
7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction ✨

okay bestie, so Bit Index Explicit Replication (BIER) [RFC8279] is an architecture where every intended multicast receiver gets encoded as a bitmask inside the multicast packet header. That header can use different encapsulations, like the one in [RFC8296] 🦋 When a router gets one of these packets, it forwards based on the bit position toward the receiver(s), following a precomputed tree for each bit in the packet. Each receiver owns one unique bit in the bitmask 💖

this doc adds the extensions needed to the IS-IS for IP that's already deployed [RFC1195]. The goal is to distribute the info that BIER domains and subdomains need in order to run. It defines a new TLV that every router taking part in BIER signaling has to advertise 🎀

it also covers MPLS encapsulation, as specified in [RFC8296]. Other encapsulation types, and using more than one encapsulation type at once, are out of scope for this document 🙈

2. Terminology 🌸

some of the terms from [RFC8279] get repeated here, plus a few extra definitions we need:

BIER: Bit Index Explicit Replication. The overall architecture for forwarding multicast using a bit position.
BIER-OL: BIER Overlay Signaling. The method a BFIR uses to learn about BFERs.
BFR: Bit Forwarding Router. A router that takes part in Bit Index Multipoint Forwarding. A BFR is identified by a unique BFR-prefix in a BIER domain.
BFIR: Bit Forwarding Ingress Router. The ingress border router that puts the BitString into the packet. Each BFIR must have a valid BFR-id assigned.
BFER: Bit Forwarding Egress Router. A router that takes part in Bit Index Forwarding as a leaf. Each BFER must be a BFR. Each BFER must have a valid BFR-id assigned.
BFT: Bit Forwarding Tree, used to reach all BFERs in a domain.
BIER subdomain: A further distinction within a BIER domain, identified by its unique subdomain identifier. A BIER subdomain can support multiple BitString Lengths.
BFR-id: An optional, unique identifier for a BFR within a BIER subdomain.
Invalid BFR-id: An unassigned BFR-id. The special value 0 is reserved for this purpose.
BAR: BIER Algorithm. Used to calculate underlay next hops.
IPA: IGP Algorithm. May be used to modify, enhance, or replace the calculation of underlay paths as defined by the BAR value.
SPF: Shortest Path First routing calculation based on the IGP link metric.

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 get read the way BCP 14 [RFC2119] [RFC8174] describes. That only happens when, and only when, they show up in all capitals, exactly like this 💅

3. IANA Considerations 🧚

this doc adds one new entry to the "Sub-TLVs for TLVs 135, 235, 236, and 237" registry:

Value: 32
Name: BIER Info

it also creates a brand-new registry for sub-sub-TLVs of the BIER Info sub-TLV. The registration policy is Expert Review, as defined in [RFC8126]. The "Sub-sub-TLVs for BIER Info Sub-TLV" registry was made inside the "IS-IS TLV Codepoints" registry, and its one defined value is:

  Type    Name
  ----    ----
  1       BIER MPLS Encapsulation

IANA also set up the "BIER Algorithms" registry inside the "Bit Index Explicit Replication (BIER)" registry. The registration policies [RFC8126] for it are:

"Standards Action" for values 0-127
"Specification Required" for values 128-239
"Experimental Use" for values 240-254

The initial values in the "BIER Algorithms" registry are:

0: No BIER-specific algorithm is used
255: Reserved

4. Concepts 🦋

4.1. BIER Domains and Subdomains 💖

an IS-IS-signaled BIER domain lines up with the scope where BFR-prefixes get distributed to identify BFRs inside IS-IS. In that case, IS-IS is the supporting BIER underlay 🌈

inside such a domain, the extensions in this doc advertise BIER info for one or more BIER subdomains. Every subdomain is uniquely identified by a subdomain-id (SD). Each subdomain goes with one IS-IS topology (MT) [RFC5120], which can be any topology IS-IS supports. Local config decides which <MT,SD> pairs a router supports. The mapping from subdomains to topologies MUST be consistent within the IS-IS flooding domain that advertises BIER info ✨

each BIER subdomain has its own unique attributes: the encapsulation it uses, and the type of tree it uses to forward BIER frames (right now that's always SPF). On top of that, for each supported BitString length in the subdomain, every router advertises the label ranges it needs to support that length 🎀

4.2. Advertising BIER Information 🫶

BIER info advertisements ride along in a new sub-TLV inside the extended reachability TLVs. BIER info is always tied to a host prefix, and that prefix MUST be a node address for the advertising node. If it isn't, the advertisement MUST be ignored. So these restrictions apply:

Prefix length MUST be 32 for an IPv4 prefix or 128 for an IPv6 prefix.
When the Prefix Attributes Flags sub-TLV [RFC7794] is present, the N flag MUST be set and the R flag MUST NOT be set.
BIER sub-TLVs MUST be included when a prefix reachability advertisement is leaked between levels.

5. Procedures 🌟

5.1. Multi-Topology and Subdomain 🧚

a given subdomain is supported within one and only one topology. Every router in the flooding scope of the BIER sub-TLVs MUST advertise the same subdomain within the same multi-topology. If a router gets an <MT,SD> advertisement that doesn't match its locally configured pair, it MUST report a misconfiguration of the received <MT,SD> pair. All received BIER advertisements tied to the conflicting <MT,SD> pair MUST be ignored. Heads up: when there's a misconfiguration like this, it will lead to partitioning of the subdomain 😭

example time 💅

the following combination of advertisements is valid: <0,0> <0,1>, and <2,2>.

the following combination is invalid: <0,0> <0,1>, and <2,0>. Advertisements tied to <0,0> and <2,0> must be ignored.

5.2. BFR-id Advertisements 🍓

if a BFER/BFIR is configured with a BFR-id, it advertises that value in its BIER advertisements. If no BFR-id is configured, it advertises the value "Invalid BFR-id". A valid BFR-id MUST be unique within the flooding scope of the BIER advertisements. All BFERs/BFIRs MUST detect when a valid BFR-id is advertised more than once for a given <MT,SD>. When that duplication is detected, every router advertising a duplicate MUST be treated as if it did not advertise a valid BFR-id. This implies those routers can't act as a BFER or BFIR in that <MT,SD> 🙈

5.3. Logging Misconfiguration 💀

whenever an advertisement comes in that breaks any of the constraints in this document, the receiving router MUST support logging that occurrence. Logging SHOULD be dampened to avoid excessive output 📝

5.4. Flooding Reduction 🌈

it's expected that changes to the BIER domain info advertised by IS-IS happen infrequently. If that expectation isn't met for an extended period (more than a few seconds of burstiness), the changes will increase the number of Link State PDU (LSP) updates and hurt network performance. Implementations SHOULD protect against this by, for example, dampening updates when they happen over an extended period of time 🫶

Part 1 of 2 ✨ Section 6 and everything after it comes next 🦋

6.1. BIER Info Sub-TLV ✨

okay so this sub-TLV is where a router spills the tea on the BIER subdomains it's hanging out in as a BFR 💅 It MAY show up multiple times in a given prefix-reachability TLV, once for each subdomain supported in the associated topology 🌈

Each one advertises a single <MT,SD> combo, followed by optional sub-sub-TLVs, which we'll get into in the following sections 🦋

     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      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   BAR         |    IPA        | subdomain-id  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     BFR-id                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  sub-sub-TLVs (variable)                                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's the breakdown of the fields 👀

Type: As indicated in the IANA section.
Length: Variable
BAR: BIER Algorithm. Specifies a BIER-specific algorithm used to calculate underlay paths to reach BFERs. Values are allocated from the "BIER Algorithms" registry. 1 octet.
IPA: IGP Algorithm. Specifies an IGP Algorithm to either modify, enhance, or replace the calculation of underlay paths to reach BFERs as defined by the BAR value. Values are from the IGP Algorithm registry. 1 octet.
subdomain-id: Unique value identifying the BIER subdomain. 1 octet.
BFR-id: A 2-octet field encoding the BFR-id, as documented in [RFC8279]. If no BFR-id has been assigned, the value of this field is set to "Invalid BFR-id", which is defined as illegal in [RFC8279].

Heads up: using non-zero values in the BAR field or the IPA field is outside the scope of this document 🙈

If an implementation doesn't support non-zero values in those fields but still gets a BIER Info sub-TLV containing them, it SHOULD treat the advertising router as incapable of supporting BIER 🫶 (one way of handling incapable routers is documented in Section 6.9 of [RFC8279], and additional methods may be defined in the future ✨)

6.2. BIER MPLS Encapsulation Sub-sub-TLV 🧚

This sub-sub-TLV carries the BIER MPLS encapsulation info, including the label range for a specific BitString length for a certain <MT,SD> 🍓 It gets advertised inside the BIER Info sub-TLV (Section 6.1), and it MAY appear multiple times within a single BIER Info sub-TLV 💜

Now the rules, bestie, and they're strict 😭 If the same BitString length gets repeated across multiple sub-sub-TLVs inside the same BIER Info sub-TLV, the BIER Info sub-TLV MUST be ignored 💀

Label ranges across ALL the BIER MPLS Encapsulation sub-sub-TLVs from ALL the BIER Info sub-TLVs advertised by the same BFR MUST NOT overlap 🚫 If overlap is detected, the advertising router MUST be treated as if it did not advertise any BIER sub-TLVs at all 🙃

Label values MUST NOT match any of the reserved values defined in [RFC3032] 🔥

     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      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Max SI      |BS Len |                    Label              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields, explained 🎀

Type: Value of 1 indicating MPLS encapsulation.
Length: 4
Max SI: Maximum Set Identifier (Section 1 of [RFC8279]) used in the encapsulation for this BIER subdomain for this BitString length, 1 octet. Each SI maps to a single label in the label range. The first label is for SI=0, the second label is for SI=1, etc. If the label associated with the Maximum Set Identifier exceeds the 20-bit range, the sub-sub-TLV MUST be ignored.
Local BitString Length (BS Len): Encoded BitString length as per [RFC8296]. 4 bits.
Label: First label of the range, 20 bits. The labels are as defined in [RFC8296].

7. Security Considerations 🔐

okay the security part is SO important, so let's be serious for a sec 😭 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310] 🫶

The Security Considerations section of [RFC8279] talks about the possibility of a Denial-of-Service (DoS) attack by setting too many bits in the BitString of a BIER-encapsulated packet 💀 BUT this kind of DoS attack cannot be started by modifying the IS-IS BIER advertisements specified in this document 🙅‍♀️ A BFIR decides which systems are going to receive a BIER-encapsulated packet, and it is NOT influenced by IS-IS control messages when it makes that call 👑 When it creates the encapsulation, the BFIR sets one bit in the encapsulation for each destination system. The info in the IS-IS BIER advertisements is used to build the forwarding tables that map each bit in the encapsulation to a set of next hops for the host identified by that bit, but the BFIR doesn't use it to decide which bits to set 🦋 So an attack on the IS-IS control plane can't be used to cause this sort of DoS attack ✨

While a BIER-encapsulated packet is traveling through the network, a BFR that receives one with n bits set in its BitString may have to replicate the packet and forward multiple copies 🌸 However, a given bit will only be set in one copy of the packet. That means each transmitted replica of a received packet has fewer bits set (so it's targeted to fewer destinations) than the received packet 🔥 This is an essential property of the BIER-forwarding process as defined in [RFC8279]. A failure of this process might cause a DoS attack (as discussed in the Security Considerations of [RFC8279]), but such a failure cannot be caused by an attack on the IS-IS control plane 😭

For more BIER-specific security considerations, check out [RFC8279] 🧚

8. References 📚

8.1. Normative References

[RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
           dual environments", RFC 1195, DOI 10.17487/RFC1195,
           December 1990, <https://www.rfc-editor.org/info/rfc1195>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[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,
           <https://www.rfc-editor.org/info/rfc3032>.

[RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
           Topology (MT) Routing in Intermediate System to
           Intermediate Systems (IS-ISs)", RFC 5120,
           DOI 10.17487/RFC5120, February 2008,
           <https://www.rfc-editor.org/info/rfc5120>.

[RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
           Authentication", RFC 5304, DOI 10.17487/RFC5304, October
           2008, <https://www.rfc-editor.org/info/rfc5304>.

[RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
           Engineering", RFC 5305, DOI 10.17487/RFC5305, October
           2008, <https://www.rfc-editor.org/info/rfc5305>.

[RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
           DOI 10.17487/RFC5308, October 2008,
           <https://www.rfc-editor.org/info/rfc5308>.

[RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
           and M. Fanto, "IS-IS Generic Cryptographic
           Authentication", RFC 5310, DOI 10.17487/RFC5310, February
           2009, <https://www.rfc-editor.org/info/rfc5310>.

[RFC7794]  Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and
           U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4
           and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
           March 2016, <https://www.rfc-editor.org/info/rfc7794>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[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,
           <https://www.rfc-editor.org/info/rfc8279>.

[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, <https://www.rfc-editor.org/info/rfc8296>.

8.2. Informative References

[OPSFv2BIER]
           Psenak, P., Kumar, N., Wijnands, I., Dolganow, A.,
           Przygienda, T., Zhang, Z., and S. Aldrin, "OSPFv2
           Extensions for BIER", Work in Progress, draft-ietf-bier-
           ospf-bier-extensions-18, June 2018.

[RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
           Writing an IANA Considerations Section in RFCs", BCP 26,
           RFC 8126, DOI 10.17487/RFC8126, June 2017,
           <https://www.rfc-editor.org/info/rfc8126>.

Acknowledgements 🫶

This RFC lines up with the "OSPFv2 Extensions for BIER" [OPSFv2BIER] document as far as the protocol mechanisms overlap 💖

Many thanks to (in no particular order) Hannes Gredler, IJsbrand Wijnands, Peter Psenak, and Chris Bowers for their comments 🌈

Special thanks to Eric Rosen 👑

Authors' Addresses 💌

Les Ginsberg (editor)
Cisco Systems
510 McCarthy Blvd.
Milpitas, CA  95035
United States of America

Email: ginsberg@cisco.com


Tony Przygienda
Juniper Networks

Email: prz@juniper.net


Sam Aldrin
Google
1600 Amphitheatre Parkway
Mountain View, CA
United States of America

Email: aldrin.ietf@gmail.com


Jeffrey (Zhaohui) Zhang
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA  01886
United States of America

Email: zzhang@juniper.net

📦 where this page comes from

ietf: rfc8401 2018-06
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms