RFC 8556

Multicast VPN Using Bit Index Explicit Replication (BIER)

📅 published April 2019, from ietf

RFC 8556: Multicast VPN Using Bit Index Explicit Replication (BIER) 🦋

okay bestie, this one is about getting multicast traffic across a service provider's backbone using BIER 💖 Here's the header tea: E. Rosen is the editor, with M. Sivakumar and T. Przygienda (all at Juniper Networks, Inc.), S. Aldrin (Google, Inc.), and A. Dolganow (Nokia). It's a Standards Track document, published April 2018, with ISSN 2070-1721. The header doesn't list any RFCs that it obsoletes or updates, so it's not replacing or patching anything else 🌸

Abstract 🌸

okay so MVPN specs need multicast tunnels called "P-tunnels" that go across a provider's backbone network 🛣️ The P-tunnels carry multicast traffic over that backbone, and several P-tunnel types are supported. BIER is the new architecture here, and it gives you optimal multicast forwarding through a "multicast domain" 🔥 The best part? Intermediate routers don't have to keep any per-flow state or run an explicit tree-building protocol. This document specifies the protocol and procedures that let MVPN use BIER to carry multicast traffic over a service provider's backbone network 💅

Status of This Memo 📜

This is an Internet Standards Track document ✨

It's a product of the Internet Engineering Task Force (IETF), so 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 more 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/rfc8556 🧚

Copyright (c) 2018 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, which you can find at https://trustee.ietf.org/license-info as they stood on the publication date. Please read them carefully, because they spell out your rights and restrictions for this document 👀 Code Components pulled from this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as the Simplified BSD License describes 🙈

Table of Contents 📚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  2.  Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes . . . .   5
    2.1.  MPLS Label  . . . . . . . . . . . . . . . . . . . . . . .   7
    2.2.  Explicit Tracking . . . . . . . . . . . . . . . . . . . .   9
      2.2.1.  Using the LIR Flag  . . . . . . . . . . . . . . . . .  10
      2.2.2.  Using the LIR-pF Flag . . . . . . . . . . . . . . . .  10
  3.  Use of the PMSI Tunnel Attribute in Leaf A-D Routes . . . . .  11
  4.  Data Plane  . . . . . . . . . . . . . . . . . . . . . . . . .  12
    4.1.  Encapsulation and Transmission  . . . . . . . . . . . . .  12
    4.2.  Disposition . . . . . . . . . . . . . . . . . . . . . . .  14
      4.2.1.  At a BFER That Is an Egress PE  . . . . . . . . . . .  14
      4.2.2.  At a BFER That Is a P-tunnel Segmentation Boundary  .  14
  5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
  6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
  7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
    7.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
    7.2.  Informative References  . . . . . . . . . . . . . . . . .  16
  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
  Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction ✨

okay so [RFC6513] and [RFC6514] are the specs that tell a Service Provider (SP) how to offer Multicast Virtual Private Network (MVPN) service to customers 💅 Multicast tunnels get built through the SP's backbone, and those are the "P-tunnels". They carry multicast traffic across the backbone, and the MVPN specs let you use several different kinds of P-tunnel technology 🌈

Bit Index Explicit Replication (BIER) ([RFC8279]) is the architecture that gives you optimal multicast forwarding through a "multicast domain" 🦋 Intermediate routers don't need per-flow state, and they don't need an explicit tree-building protocol either, which is so iconic. The purpose of this document is to specify the protocols and procedures needed to provide MVPN service using BIER to transport the multicast traffic over the backbone 🫶

Although BIER doesn't explicitly build and maintain multicast tunnels, you can think of BIER as using a bunch of implicitly created tunnels through a "BIER domain" 🧚 Specifically, you can picture one Point-to-Multipoint (P2MP) tunnel from each Bit Forwarding Ingress Router (BFIR) to all the Bit Forwarding Egress Routers (BFERs) in the BIER domain. A BIER domain is generally co-extensive with an IGP network. These "tunnels" aren't tied to any particular VPN 🌸 However, the MVPN architecture has protocols and procedures that let the traffic of multiple MVPNs get aggregated on a single P-tunnel. In this document, we specify how to use these multi-VPN aggregation procedures so BIER can transport traffic from multiple MVPNs 💖

Now, MVPN traffic sometimes has to cross more than one IGP domain, but BIER only carries multicast traffic within a single IGP domain 😭 That's where segmentation comes in. The MVPN specs let P-tunnels be segmented (the concept of MVPN segmentation is defined in [RFC6513] and [RFC6514]). The segmentation points can be either Autonomous System Border Routers (ASBRs), as described in [RFC6514], or Area Border Routers (ABRs), as described in [RFC7524]. As long as the segmentation points can act as BFIRs and BFERs, BIER can provide some or all of the segments of a P-tunnel 🔥

Procedures for supporting MVPN customers who use Bidirectional PIM (BIDIR-PIM) are outside the scope of this document 🙈

This document uses the following terminology from [RFC8279]:

  • BFR: Bit-Forwarding Router.
  • BFIR: Bit-Forwarding Ingress Router.
  • BFER: Bit-Forwarding Egress Router.

This document uses the following terminology from [RFC6513]:

  • MVPN: Multicast Virtual Private Network, which is a VPN [RFC4364] in which multicast service is offered.
  • P-tunnel: A multicast tunnel through the network of one or more SPs. P-tunnels are used to transport MVPN multicast data.
  • PMSI: Provider Multicast Service Interface. This is an abstraction that represents a multicast service for carrying packets. A PMSI is instantiated via one or more P-tunnels.
  • C-S: A multicast source address, identifying a multicast source located at a VPN customer site.
  • C-G: A multicast group address used by a VPN customer.
  • C-flow: A customer multicast flow. Each C-flow is identified by the ordered pair (source address, group address), where each address is in the customer's address space. The identifier of a particular C-flow is usually written as (C-S,C-G).
    • Sets of C-flows can be identified by using the "C-" wildcard (see [RFC6625]), e.g., (C-,C-G).
  • I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route. These routes are carried in BGP Update messages and are used to advertise the default P-tunnel for a particular MVPN.
  • S-PMSI A-D route: Selective PMSI Auto-Discovery route. These routes are carried in BGP Update messages and are used to advertise the fact that particular C-flows are bound to (i.e., are traveling through) particular P-tunnels.
  • x-PMSI A-D route: A route that is either an I-PMSI A-D route or an S-PMSI A-D route.
  • Leaf A-D route: A route that a multicast egress node sends in order to join a particular P-tunnel.
  • PMSI Tunnel attribute (PTA): In an x-PMSI A-D route, the Network Layer Reachability Information (NLRI) of the route identifies a PMSI. The BGP attribute known as the PMSI Tunnel attribute is attached to such a route in order to identify a particular P-tunnel that is associated with the PMSI. When C-flows of multiple VPNs are carried in a single P-tunnel, this attribute also carries the information needed to multiplex and demultiplex the C-flows. A PTA can also be carried by a Leaf A-D route. In this case, it contains information that is needed in order for the originator of the route to join the specified P-tunnel.

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 💜

2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes ✨

okay so bestie, [RFC6514] says the PMSI Tunnel attribute (PTA) riding on an x-PMSI A-D route tells everyone which P-tunnel is used to set up a particular PMSI 🎀 And if a PMSI is gonna be instantiated by BIER, the BFIR is the one who builds the PTA 💅

If segmented P-tunnels aren't being used, the PTA on a given x-PMSI A-D route gets built by whoever originated the route (usually the ingress Provider Edge (PE) router) 🌸 and it stays the same as the route gets passed along 🤍

If segmented P-tunnels are being used, the originator's PTA can get swapped out at a segmentation point (a BFER) for a PTA that names the next segment of the P-tunnel 🦋 And if that next segment is BIER, the segmentation point acts as the BFIR for that next segment 👑

Either way, a BFIR builds the PTA like this (see Figure 1) 🧚

The PTA has these fields:

  • Tunnel Type: IANA assigned 0x0B as the codepoint for "BIER" in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry 💖 It's how we say "this PMSI runs on BIER" ✨

Even though BIER doesn't actually create tunnels, the MVPN procedures treat BIER as if it were a type of tunnel, ngl 🙈

  • Tunnel Identifier: when the tunnel type is BIER, this field has three subfields 🍓
    1. First, a single octet with a BIER sub-domain-id (see [RFC8279]). This means packets sent on the PMSI go out on that BIER sub-domain. How that sub-domain gets chosen is outside the scope of this document 🔥
    2. Next, a two-octet field with the BFR-id in the sub-domain from the first subfield, belonging to the router that's building the PTA 💅
    3. Last, the BFR-prefix (see [RFC8279]) of the router (a BFIR) building the PTA. The BFR-prefix is either a /32 IPv4 address or a /128 IPv6 address, and you can tell which one from the total length of the PTA 🫶

The BFR-prefix doesn't have to be the same IP address carried in any other field of the x-PMSI A-D route, even if the BFIR is the originating router of that route 🌈

Failure to properly set the Tunnel Identifier field can't be detected by the protocol, and it'll result in improper delivery of the data packets sent on the PMSI 😭

  • MPLS Label: this field MUST contain an upstream-assigned non-zero MPLS label. It's assigned by the router (a BFIR) that constructs the PTA. The constraints on how a BFIR picks this label are covered in Section 2.1.

Failure to follow the constraints on label assignment can't be detected by the protocol, and it may result in improper handling of data packets by the egress PE routers 💀

  • Flags: when the tunnel type is BIER, two of the flags in the PTA Flags field are meaningful. You can find the details about using these flags in Section 2.2.
    • Leaf Information Required per Flow (LIR-pF): this flag is introduced in [RFC8534]. A BFIR SHOULD NOT set this flag UNLESS it knows that all the BFERs in the BIER domain (or at least all the BFERs to which it needs to transmit) support this flag. (How it knows that is outside the scope of this document.) Procedures for using this flag are given in Section 2.2.2. Support for this flag is OPTIONAL. 🦋
    • Leaf Information Required (LIR): see Section 2.2.1. 🌸
          +---------------------------------+
          |  Flags (1 octet)                |
          +---------------------------------+
          |  Tunnel Type = 0x0B (1 octet)   |
          +---------------------------------+
          |  MPLS Label (3 octets)          |
          +---------------------------------+
          |  Sub-domain-id (1 octet)        |  <---
          +---------------------------------+     |
          |  BFR-id (2 octets)              |     |-- Tunnel
          +---------------------------------+     |   Identifier
          |  BFR-prefix (4 or 16 octets)    |  <---
          +---------------------------------+

                 Figure 1: PMSI Tunnel Attribute for BIER

If a PTA specifying tunnel type BIER is attached to an x-PMSI A-D route, the route MUST NOT be distributed beyond the boundaries of a BIER domain. That means any routers that receive the route have to be in the same BIER domain as the route's originator. If the originator is in more than one BIER domain, the route must be distributed only within the BIER domain in which the BFR-prefix in the PTA uniquely identifies the originator. As with all MVPN routes, distribution of these routes is controlled by how the Route Targets (RTs) are provisioned. So the requirement in this paragraph is really a requirement on the way the Route Targets are provisioned 🎀

2.1. MPLS Label 💜

The MPLS Label carried in the PTA is an upstream-assigned label 🧚

If two PTAs contain the same BFR-prefix in their respective Tunnel Identifier fields, then the labels carried in those PTAs MUST come from the same label space (see Section 7 of [RFC5331]). An implementation may choose to use this fact when setting up the tables it uses to interpret the upstream-assigned labels 🔥

Suppose a BFIR attaches a PTA to each of two x-PMSI A-D routes, and both PTAs specify a tunnel type of BIER 💅

  • If the two routes do not carry the same set of RTs, then their respective PTAs MUST contain different MPLS label values.
  • If the two routes do not have the same Address Family Identifier (AFI) value, then their respective PTAs MUST contain different MPLS label values. This ensures that when an egress PE receives a data packet with the given label, the egress PE can infer from the label whether the payload is an IPv4 packet or an IPv6 packet. 🫶
  • If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900]) functionality, and if the two routes originate from different VPN Routing and Forwarding tables (VRFs) on this ingress PE, then the respective PTAs of the two routes MUST contain different MPLS label values.
  • If the BFIR is an ingress PE supporting the "Extranet Separation" feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if one of the routes carries the "Extranet Separation" extended community but the other does not, then the respective PTAs of the two routes MUST contain different MPLS label values. 🌈
  • If segmented P-tunnels are being used, then the respective PTAs of the two routes MUST contain different MPLS label values whenever the respective NLRIs of the two routes are not identical. The MPLS label can then be used at the next segmentation point to switch packets from one P-tunnel segment directly to the next, without requiring the segmentation points to contain any other multicast forwarding state. This is explained further below; see also Section 4. 👑

When segmented P-tunnels are being used, a segmentation point, call it "B1", may receive an x-PMSI A-D route whose PTA specifies BIER from within a given BIER domain. That means BIER is being used for the previous segment of a segmented P-tunnel. If the next segment is also of type BIER, B1 will be the BFIR for the next segment. So B1 is a BFER of one BIER domain (the one for the previous segment) and a BFIR of another BIER domain (the one for the next segment) 🦋 B1 needs to replace the PTA of the x-PMSI A-D route with a new PTA, specifying its own BFR-prefix and an upstream-assigned label that B1 assigns itself 💖

Suppose B1 has received two x-PMSI A-D routes, R1 and R2, where:

  • R1 and R2 each have a PTA specifying BIER.
  • R1's PTA specifies BFR-prefix B2 and Label L2.
  • R2's PTA specifies BFR-prefix B3 and Label L3.

Suppose B1 decides to propagate both R1 and R2, replacing each PTA with a new PTA specifying BIER. Suppose these new PTAs specify labels L4 and L5 respectively. Then L4 and L5 MUST be different (upstream-assigned) label values, UNLESS both of the following conditions hold:

  • R1 and R2 have the same value in the Originating Router field of their respective NLRIs, and
  • B2 is equal to B3, and
  • L2 is equal to L3.
The segmentation point (B1, in this example) MUST also program its data plane appropriately. 🍓

For example, when:

  • B1 receives a BIER packet for which it is a BFER, and
  • the BIER header specifies the BFIR-id that corresponds to B2, and
  • the BIER payload is an MPLS packet with upstream-assigned label, and
  • the top label value is L2,

then the data plane must be programmed to replace L2 with L4 and to re-encapsulate the packet in a BIER header with B1's BFR-id in the BFIR-id field. The BitString of the new BIER header is determined by applying the procedures for MVPN explicit tracking (see Section 2.2) in the BIER domain of the next segment, i.e., in the BIER domain for which B1 is the BFIR. ✨

2.2. Explicit Tracking 🌸

When using BIER to transport an MVPN data packet through a BIER domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR must determine the set of BFERs to which the packet needs to be delivered. This can be done in either of two ways:

  1. Using the explicit tracking mechanism based on the "Leaf Information Required" flag specified in [RFC6513] and [RFC6514]. This method is further described in Section 2.2.1.
  2. Using the OPTIONAL explicit tracking mechanism based on the LIR-pF flag specified in [RFC8534]. This method, further described in Section 2.2.2, may be used if (and only if) segmented P-tunnels are not being used. 🦋

2.2.1. Using the LIR Flag 💖

To figure out the set of BFERs that the packets of a given C-flow must be sent to, a BFIR MUST originate a (C-S,C-G) S-PMSI A-D route for the given C-flow. It MUST attach a PTA to that route and MUST set the Leaf Information Required (LIR) flag in the PTA. Per [RFC6514], the BFERs that need to receive that C-flow will respond with (C-S,C-G) Leaf A-D routes. By matching the received Leaf A-D routes to the originated S-PMSI A-D routes, the originator of the S-PMSI A-D route determines the set of BFERs that need to receive the multicast data flow identified in the NLRI of the S-PMSI A-D route. 🔥

Suppose an ingress PE has originated an I-PMSI A-D route or a wildcard S-PMSI A-D route [RFC6625] with a PTA specifying a tunnel type of BIER. Now suppose the ingress PE originates an S-PMSI A-D route specifying (C-S,C-G), where (C-S,C-G) "matches" (according to the rules of [RFC6625]) the wildcard S-PMSI A-D route or the I-PMSI A-D route. Instead of attaching a PTA specifying BIER to the (C-S,C-G) route, the ingress PE MAY attach a PTA specifying a tunnel type of "no tunnel information". This is equivalent to attaching the same PTA attached to the matching "less specific" route. 🫶

2.2.2. Using the LIR-pF Flag

okay so, if segmented P-tunnels are not being used 💅 the BFIR can figure out which BFERs need the packets of a given (C-S,C-G) C-flow like this. The BFIR MUST originate a wildcard S-PMSI A-D route (either (C-*,C-*), (C-*,C-G), or (C-S,C-G)), and the PTA of that route MUST use these settings:

  • The LIR-pF flag MUST be set.
  • The tunnel type MUST be set to BIER.
  • A non-zero MPLS label MUST be specified.

Per [RFC8534], a BFER that needs to receive (C-S,C-G) traffic from the BFIR will respond with a Leaf A-D route. 🦋

A BFIR MUST NOT use this method of finding the set of BFERs needing to receive a given C-flow unless it knows that all those BFERs support the LIR-pF flag. How this is known is outside the scope of this document. 🙈

This method is highkey iconic because it greatly reduces the number of S-PMSI A-D routes a BFIR needs to originate. It can now originate as few as one such route (a (C-*,C-*) S-PMSI A-D route), instead of one for each C-flow. 🌸 The tradeoff is that it doesn't give the BFIR a way to assign a distinct label to each C-flow. So it cannot be used when segmented P-tunnels are in use (see Section 4 for an explanation). ✨

Note: If a BFIR originates a (C-*,C-*) S-PMSI A-D route with the LIR-pF flag set, but also originates a more specific wildcard route that matches a particular (C-S,C-G), the BFERs will not originate Leaf A-D routes for that (C-S,C-G) unless the LIR-pF flag is also set in the more specific wildcard route. If the BFIR also originates a (C-S,C-G) S-PMSI A-D route without the LIR flag set, the BFERs will not originate Leaf A-D routes for that (C-S,C-G) unless the LIR flag is also set in that route. 🎀 Main character energy, but make sure your flags match!

3. Use of the PMSI Tunnel Attribute in Leaf A-D Routes

okay bestie, before an egress PE can receive a (C-S,C-G) flow from a given ingress PE via BIER, the egress PE has to have received one of the following x-PMSI A-D routes from that ingress PE: 🧚

  • A (C-S,C-G) S-PMSI A-D route (aka an S-PMSI A-D route whose NLRI encodes (C-S,C-G)) whose PTA specifies a tunnel type of BIER. If one of these shows up, we call it the "matching x-PMSI A-D route."
  • A "less specific" x-PMSI A-D route (one specifying (C-*,C-*), (C-*,C-G), or (C-S,C-G)) whose PTA specifies a tunnel type of BIER, and that is the egress PE's "match for reception" of (C-S,C-G).

The rules for figuring out which x-PMSI A-D route is the match for reception are given in [RFC6625]. However, these rules are modified here to exclude any x-PMSI A-D route that does not have a PTA or whose PTA specifies "no tunnel type". 💅

If one of these shows up, we call it the "matching x-PMSI A-D route."

If no matching x-PMSI A-D route for (C-S,C-G) is found, the egress PE cannot receive the (C-S,C-G) flow from the ingress PE via BIER until a matching route is received. 💀

When an egress PE figures out that it needs to receive a (C-S,C-G) flow from a particular ingress PE via BIER, it originates a Leaf A-D route. Building the Leaf A-D route generally follows the procedures in [RFC6514], or optionally the procedures in [RFC8534]. 🌈 BUT when BIER is being used, the Leaf A-D route MUST carry a PTA that is built like this:

  1. The tunnel type MUST be set to BIER.
  2. The MPLS Label field SHOULD be set to zero.
  3. The sub-domain-id subfield of the Tunnel Identifier field (as defined in Section 2) MUST be set to the corresponding value from the PTA of the matching x-PMSI A-D route.
  4. The BFR-id subfield of the Tunnel Identifier field MUST be set to the BFR-id in the sub-domain identified by the sub-domain-id subfield of the egress PE (BFER).
  5. The BFR-prefix field of the Tunnel Identifier field (as defined in Section 2) MUST be set to the egress PE's (BFER's) BFR-prefix.

The BFR-prefix need not be the same IP address that is carried in any other field of the Leaf A-D route. 🫶

When an ingress PE receives a Leaf A-D route like this, it learns the BFR-prefix of the egress PE from the PTA. The ingress PE does not make any use of the value of the PTA's MPLS label field. 🙈

Failure to properly construct the PTA cannot always be detected by the protocol, and it will cause improper delivery of the data packets. 😭 Be careful, bestie!

4. Data Plane

The MVPN application plays the role of the "multicast flow overlay" as described in [RFC8279]. 👑

4.1. Encapsulation and Transmission

okay so to transmit an MVPN data packet, an ingress PE follows the rules of [RFC6625] to find the x-PMSI A-D route that is a "match for transmission" for that packet. (When applying the rules of [RFC6625], any S-PMSI A-D route with a PTA specifying "no tunnel information" is ignored.) If the matching route has a PTA specifying BIER, the (upstream-assigned) MPLS label from that PTA gets pushed on the packet's label stack. Then the packet is encapsulated in a BIER header. That is, the ingress PE functions as a BFIR. 🦋 The BIER sub-domain used for transmitting the packet is specified in the PTA of the above-mentioned x-PMSI A-D route.

To make the proper BIER header for a given packet, the BFIR must know all the BFERs that need to receive that packet. It figures this out by finding all the Leaf A-D routes that correspond to the S-PMSI A-D route that is the packet's match for transmission. There are two different cases to consider: ✨

  1. The S-PMSI A-D route that is the match for transmission carries a PTA that has the LIR flag set but does not have the LIR-pF flag set.

In this case, the corresponding Leaf A-D routes are those whose "route key" field is identical to the NLRI of the S-PMSI A-D route.

  1. The S-PMSI A-D route that is the match for transmission carries a PTA that has the LIR-pF flag.

In this case, the corresponding Leaf A-D routes are those whose "route key" field is derived from the NLRI of the S-PMSI A-D route according to the procedures described in Section 5.2 of [RFC8534].

The Leaf A-D route from a given BFER will contain a PTA that specifies the BFER's BFR-prefix. With this info, the BFIR can construct the BIER BitString. 🌸

However, if the PTA of the Leaf A-D route from a given BFER specifies a sub-domain other than the one being used for transmitting the packet, the bit for that BFER cannot be determined, and that BFER will not receive the packet. 💔

The BIER-encapsulated packet is then forwarded according to the procedures described in [RFC8279] and [RFC8296]. (See especially Section 3, "Imposing and Processing the BIER Encapsulation" in [RFC8296].) 🧚

4.2. Disposition

When a BFER receives an MVPN multicast data packet that has been BIER-encapsulated, the BIER layer passes the following info to the multicast flow overlay:

  • The sub-domain-id and the BFIR-id from the BIER header. (As the sub-domain-id is inferred from the BIFT-id field of the BIER header, an implementation might choose to pass the BIFT-id rather than the sub-domain-id. This is an implementation matter.)
  • The "payload", which is an MPLS packet whose top label is an upstream-assigned label. In the data plane, the BFIR-id and the sub-domain-id provide the context in which the upstream-assigned label is interpreted. 🎀

By looking up the upstream-assigned label in the appropriate context, the multicast flow overlay determines whether the BFER is an egress PE for the packet.

Note that if segmented P-tunnels are in use, a BFER might be a P-tunnel segmentation border router rather than an egress PE, or a BFER might be both an egress PE and a P-tunnel segmentation border router. Depending on the role of the BFER for the given packet, it may need to follow the procedures of Section 4.2.1, the procedures of Section 4.2.2, or both. 🙌

4.2.1. At a BFER That Is an Egress PE

From looking up the packet's upstream-assigned label in the context of the packet's BFIR-prefix, the egress PE determines the egress VRF for the packet. From the IP header of the payload, the multicast states of the VRF, the upstream-assigned label, and the BFR-prefix, the egress PE can determine whether the packet needs to be forwarded out one or more VRF interfaces. 💖

4.2.2. At a BFER That Is a P-tunnel Segmentation Boundary

When segmented P-tunnels are being used, a BFER that receives a BIER-encapsulated MVPN multicast data packet may need to forward it on its next P-tunnel segment. Which next P-tunnel segment the packet gets depends on the C-flow the packet belongs to. As long as the BFIR has assigned the MPLS label according to the constraints in Section 2.1, the BFIR will have assigned distinct upstream-assigned MPLS labels to distinct C-flows. So the BFER can pick the proper "next P-tunnel segment" for a given packet simply by looking up the upstream-assigned label that immediately follows the BIER header. 🍓

5. IANA Considerations

IANA has assigned the codepoint 0x0B to BIER in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. 🌈

6. Security Considerations

The procedures of this document do not, in themselves, provide privacy, integrity, or authentication for the control plane or the data plane. 🚨 For a discussion of the security considerations regarding the use of BIER, please see [RFC8279] and [RFC8296]. Security considerations regarding VPN technology based on [RFC4364], [RFC6513], and [RFC6514] can be found in those RFCs.

7. References

7.1. Normative References

[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. 📚✨

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, https://www.rfc-editor.org/info/rfc4364. 🎀

[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, https://www.rfc-editor.org/info/rfc5331. 🦋

[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, https://www.rfc-editor.org/info/rfc6513. 🌸

[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, https://www.rfc-editor.org/info/rfc6514. 💅

[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012, https://www.rfc-editor.org/info/rfc6625. 🧚

[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. 💜

[RFC8534] Dolganow, A., Kotalwar, J., Rosen, E., Ed., and Z. Zhang, "Explicit Tracking with Wildcard Routes in Multicast VPN", RFC 8534, DOI 10.17487/RFC8534, February 2019, https://www.rfc-editor.org/info/rfc8534. ⭐

7.2. Informative References

[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, https://www.rfc-editor.org/info/rfc7524. 🍓

[RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", RFC 7900, DOI 10.17487/RFC7900, June 2016, https://www.rfc-editor.org/info/rfc7900. 🫶

Acknowledgments

Okay bestie, huge thank-you hugs to Jeffrey Zhang 🫶💖 for his ideas and contributions to this work, because they were seriously iconic. We also send a big thanks to Stig Venaas for reviewing it and sharing his comments. ✨

Contributors

IJsbrand Wijnands
Cisco Systems, Inc.
De Kleetlaan 6a
Diegem  1831
Belgium
Email: ice@cisco.com

Authors' Addresses

Eric C. Rosen (editor)
Juniper Networks, Inc.
10 Technology Park Drive
Westford, Massachusetts  01886
United States of America

Email: erosen52@gmail.com


Mahesh Sivakumar
Juniper Networks, Inc.
1137 Innovation Way
Sunnyvale, California  94089
United States of America

Email: sivakumar.mahesh@gmail.com


Tony Przygienda
Juniper Networks, Inc.
1137 Innovation Way
Sunnyvale, California  94089
United States of America

Email: prz@juniper.net


Sam K Aldrin
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, California
United States of America

Email: aldrin.ietf@gmail.com


Andrew Dolganow
Nokia
438B Alexandra Rd #08-07/10
Alexandra Technopark
Singapore  119968

Email: andrew.dolganow@nokia.com
📦 where this page comes from