RFC 9272

Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER) 🦋

Okay bestie, here's the header tea ☕

• RFC number: 9272
• Title: Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER)
• Authors: Z. Zhang and A. Przygienda (Juniper Networks), A. Dolganow (Individual), H. Bidgoli (Nokia), IJ. Wijnands (Individual), A. Gulko (Edward Jones Wealth Management)
• Category: Standards Track 🌸
• ISSN: 2070-1721
• Date: September 2022
• Updates: RFC 8401 and RFC 8444 ✨
• Obsoletes: nothing is listed in the header

It's published by the Internet Engineering Task Force (IETF) 💜

Abstract

Okay so the TL;DR 💅 This doc sets the general ground rules for how the BIER Algorithm (BAR) and the IGP Algorithm (IPA) work together when calculating underlay paths inside the Bit Index Explicit Replication (BIER) architecture. It updates RFC 8401 and RFC 8444, and it also updates the "BIER Algorithm" registry that RFC 8401 set up. Iconic 🎀

Status of This Memo

This is an Internet Standards Track document 🔥

It's a product of the IETF, so it represents what the IETF community agreed on. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 🌈

Info about the current status of this document, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9272 💖

Copyright Notice

Copyright (c) 2022 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) as they're in effect on the publication date. Please actually read those, because they spell out your rights and restrictions for this document. If you pull Code Components out of this document, they must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License 🫶

Table of Contents

1.  Introduction
  1.1.  Requirements Language
2.  Updated Definitions for IPA and BAR Fields
3.  General Rules for the BAR and IPA Interaction
  3.1.  When BAR Is Not Used
  3.2.  Exceptions or Extensions to the General Rules
4.  Examples
5.  IANA Considerations
6.  Security Considerations
7.  Normative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

Okay so in the BIER architecture [RFC8279], packets carrying a BIER encapsulation header get forwarded to neighbors along underlay paths. Those paths lead to Bit-Forwarding Egress Routers (BFERs), and the BFERs are represented by bits that are set in the header's BitString. Think of it like a guest list 🎟️ Paths get calculated in the underlay topology for each sub-domain, using a calculation algorithm that's specific to that sub-domain. The topology and the algorithm may or may not be congruent with unicast. The algorithm could be a BIER-specific one, or it could be a generic IGP one, like Shortest Path First (SPF), for example 🧚

Now, [RFC8401] and [RFC8444] define an 8-bit BAR (BIER Algorithm) field and an 8-bit IPA (IGP Algorithm) field. These signal the BIER-specific algorithm and the generic IGP algorithm, respectively. In those two documents, only value 0 is allowed for both fields, so it's pretty limited 🙈

This document is the glow-up 💅 It lays out general rules for how the BAR and IPA interact for underlay path calculation, for when other BAR and/or IPA values are being used. The semantics here update [RFC8401] and [RFC8444]. It also updates the "BIER Algorithm" registry defined in [RFC8401] by renaming the "Experimental Use" range to "Private or Experimental Use" 🌸

1.1. Requirements Language

Heads up on the key words 👀 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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like shown here. Lowercase versions are just regular words ✨

2. Updated Definitions for IPA and BAR Fields 🎀

The definitions for the IPA and BAR fields in Section 6.1 of [RFC8401] and Section 2.1 of [RFC8444] get updated like this:

IPA: IGP Algorithm. It specifies a generic Routing Algorithm and related Routing Constraints, used to calculate underlay paths to reach other Bit-Forwarding Routers (BFRs). Values come from the "IGP Algorithm Types" registry. It's one octet 💖

BAR: BIER Algorithm. It specifies a BIER-specific Algorithm and BIER-specific Constraints. These either modify, enhance, or replace the calculation of underlay paths to reach other BFRs, as defined by the IPA value. Values get allocated from the "BIER Algorithm" registry. It's one octet too 🦋

When a BAR value is defined, the matching BIER-specific Algorithm (BA) and BIER-specific Constraint (BC) semantics SHOULD be specified. If you're using an IGP Algorithm as a BIER IPA, its Routing Algorithm (RA) and Routing Constraint (RC) semantics SHOULD be specified too. If any of these semantics isn't specified, it MUST be interpreted as the "NULL" algorithm or constraint. For example, the IGP Algorithm 0 defined in [RFC8665] gets treated as having a NULL RC, which means no constraints (see Section 3) 💅

If a specification isn't available for a specific BAR value, then its value MUST come from the Private or Experimental Use range of the registry 🌈

3. General Rules for the BAR and IPA Interaction 👑

For a particular sub-domain, all BFRs MUST be provisioned with and signal the same BAR and IPA values. If a BFR discovers another BFR advertising a different BAR or IPA value for that sub-domain, it MUST treat the advertising router as incapable of supporting BIER for that sub-domain. Lowkey a big deal 😭 (One way of handling incapable routers is documented in Section 6.9 of [RFC8279], and more methods might get defined in the future.)

For a particular topology X that a sub-domain is associated with, a router MUST calculate the underlay paths according to its BAR and IPA values, in this order:

1. Apply the BIER constraints, which gives you BC(X). If BC is NULL, then BC(X) is just X itself.
2. Apply the routing constraints, which gives you RC(BC(X)). If RC is NULL, then RC(BC(X)) is just BC(X).
3. Select the algorithm AG like this:
   • a. If BA is NULL, AG gets set to RA.
   • b. If BA is not NULL, AG gets set to BA.
4. Run AG on RC(BC(X)).

It's possible that the resulting AG isn't applicable to BIER. In that case, no BIER paths will be calculated. That's a network design issue, and an operator needs to avoid it when choosing the BAR or IPA 🙈

3.1. When BAR Is Not Used

BAR value 0 is defined as "No BIER-specific algorithm is used" [RFC8401]. This value means NULL BA and BC. Following the rules above, the IPA value on its own identifies the calculation algorithm and the constraints to use for a particular sub-domain. Simple and clean 🌸

3.2. Exceptions or Extensions to the General Rules

Exceptions or extensions to the general rules above might get specified in the future for specific BAR and/or IPA values. When that happens, compatibility with the defined BAR and/or IPA values and their semantics needs to be specified too 🧚

4. Examples 💖

Here's an example 🎀 Someone could define a new BAR with a BIER-specific constraint of "excluding BIER-incapable routers". No BIER-specific algorithm gets specified, and the BIER-specific constraint can go with any IPA. That means any RC defined by the IPA gets augmented with "excluding BIER-incapable routers". (Routers that don't support BIER aren't considered when the IGP Algorithm is applied.)

If the BC and RC happen to conflict and end up with an empty topology, then no BIER forwarding path will be found. Say the BC is "exclude BIER-incapable routers" and the RC is "include green links only". If every green link is tied to a BIER-incapable router, you get an empty topology. Again, that's a network design issue an operator needs to avoid when choosing the BAR or IPA 💀

Another one: a BAR value can be specified to use the Steiner tree algorithm, and it gets used together with IPA 0, which uses an SPF algorithm. According to the general rules, the BIER-specific algorithm takes precedence, so SPF doesn't get used 🍓

Authors' Addresses ✨

Okay bestie, here are the humans behind this one 🫶 Each one gets their name, where they work, and their email, so you can slide into their DMs about it 💌

Zhaohui Zhang 🌸 Juniper Networks Email: zzhang@juniper.net

Antoni Przygienda 🦋 Juniper Networks Email: prz@juniper.net

Andrew Dolganow 🧚 Individual Email: adolgano@gmail.com

Hooman Bidgoli 💜 Nokia Email: hooman.bidgoli@nokia.com

IJsbrand Wijnands 🍓 Individual Email: ice@braindump.be

Arkadiy Gulko 👑 Edward Jones Wealth Management Email: arkadiy.gulko@edwardjones.com