RFC 7582

Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels

📅 published July 2015, from ietf

Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels 🎀

Okay bestie, let's get into it. This RFC is on the Standards Track 💅, published in July 2015 (ISSN 2070-1721 ✨). It was written by E. Rosen of Juniper Networks, IJ. Wijnands of Cisco Systems, Y. Cai of Microsoft, and A. Boers 🫶. It updates [RFC6513], [RFC6514], and [RFC6625], and it doesn't obsolete anything. So it's basically the glow-up sequel to those three, and it's here to fill in the missing pieces 🦋.

Abstract

So here's the tea ☕. Some earlier RFCs already explain how to do multicast in BGP/MPLS IP VPNs, meaning customer multicast data gets to hop across a service provider's backbone through a set of multicast tunnels. Those tunnels get advertised in certain BGP multicast auto-discovery routes, using a BGP attribute called the "Provider Multicast Service Interface (PMSI) Tunnel" attribute 🌈. The PMSI Tunnel attribute can also name bidirectional (multipoint-to-multipoint) multicast distribution trees, and the encodings for that already exist.

BUT, and this is a big but 😭, the older RFCs never gave us all the procedures for actually using bidirectional tunnels for multicast VPNs. This document fixes that by updating RFCs 6513, 6514, and 6625. It spells out how to assign customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone 🍓. It also covers how those assignments get advertised, and how you figure out which flows are assigned to which tunnels. Iconic behaviour, honestly 👑.

Status of This Memo

This is an Internet Standards Track document, so it's officially a real standard 💜.

It's a product of the Internet Engineering Task Force (IETF) ✨, and it represents the consensus of the IETF community. 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 out Section 2 of RFC 5741 📚.

For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7582 🧚.

Copyright (c) 2015 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 (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please actually read these, because they explain your rights and restrictions for this document 🙈. Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️.

Table of Contents

   1. Introduction ....................................................4
      1.1. Terminology ................................................4
      1.2. Overview ...................................................9
           1.2.1. Bidirectional P-Tunnel Technologies ................10
           1.2.2. Reasons for Using Bidirectional P-Tunnels ..........11
           1.2.3. Knowledge of Group-to-RP and/or
                  Group-to-RPA Mappings ..............................12
           1.2.4. PMSI Instantiation Methods .........................12
   2. The All BIDIR-PIM Wildcard .....................................15
   3. Using Bidirectional P-Tunnels ..................................15
      3.1. Procedures Specific to the Tunneling Technology ...........15
           3.1.1. BIDIR-PIM P-Tunnels ................................16
           3.1.2. MP2MP LSPs .........................................17
      3.2. Procedures Specific to the PMSI Instantiation Method ......17
           3.2.1. Flat Partitioning ..................................17
                  3.2.1.1. When an S-PMSI Is a 'Match for
                           Transmission' .............................19
                  3.2.1.2. When an I-PMSI Is a 'Match for
                           Transmission' .............................20
                  3.2.1.3. When an S-PMSI Is a 'Match for Reception' .21
                  3.2.1.4. When an I-PMSI Is a 'Match for Reception' .22
           3.2.2. Hierarchical Partitioning ..........................23
                  3.2.2.1. Advertisement of PE Distinguisher Labels ..24
                  3.2.2.2. When an S-PMSI Is a 'Match for
                           Transmission' .............................25
                  3.2.2.3. When an I-PMSI Is a 'Match for
                           Transmission' .............................26
                  3.2.2.4. When an S-PMSI Is a 'Match for Reception' .27
                  3.2.2.5. When an I-PMSI Is a 'Match for Reception' .27
           3.2.3. Unpartitioned ......................................28
                  3.2.3.1. When an S-PMSI Is a 'Match for
                           Transmission' .............................30
                  3.2.3.2. When an S-PMSI Is a 'Match for Reception' .30
           3.2.4. Minimal Feature Set for Compliance .................31
   4. Security Considerations ........................................32
   5. References .....................................................32
      5.1. Normative References ......................................32
      5.2. Informative References ....................................33
   Acknowledgments ...................................................34
   Authors' Addresses ................................................34

1. Introduction ✨

Okay, so the RFCs that set up multicast support for BGP/MPLS IP VPNs ([RFC6513], [RFC6514], and [RFC6625]) let customer multicast data travel across a service provider's network through a set of multicast tunnels 🚇. These tunnels get advertised in BGP multicast auto-discovery (A-D) routes, using a BGP attribute called the "Provider Multicast Service Interface (PMSI) Tunnel" attribute 💅.

The base specs already let you use bidirectional (multipoint-to-multipoint) multicast distribution trees, and they explain how to encode the identifiers for those trees into the PMSI Tunnel attribute 🦋. But, ngl, they don't include all the detailed procedures for actually using bidirectional tunnels 😩. Those full procedures were considered out of scope for those documents, so this one exists to give us everything we need. Its purpose is to lay out all the necessary procedures for using bidirectional trees in a service provider's network to carry VPN customers' multicast data 🌸💖.

1.1. Terminology ✨

Okay, so this doc borrows its vocab from [RFC6513] 💅 and leans on the "C-" and "P-" prefixes from Section 3.1 of [RFC6513] to keep the customer address space separate from the provider address space 🫶. Here are the key terms you need to know:

  • MVPN: Multicast Virtual Private Network. It's a VPN [RFC4364] that offers multicast service 🦋.
  • VRF: VPN Routing and Forwarding table [RFC4364] 🌸.
  • PE: A Provider Edge router, as defined in [RFC4364] 🎀.
  • SP: Service Provider 💜.
  • LSP: An MPLS Label Switched Path 🧚.
  • P2MP: Point-to-Multipoint 🍓.
  • MP2MP: Multipoint-to-multipoint 🌈.
  • Unidirectional: An adjective for a multicast distribution tree where all traffic flows downstream from the root. Traffic can only come in at the root. A P2MP LSP is one kind of unidirectional tree, and multicast distribution trees built by Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601] are unidirectional too. Data traffic moving along one of these trees is sometimes called "unidirectional traffic" in this document ⭐.
  • Bidirectional: An adjective for a multicast distribution tree where traffic can travel both upstream (towards the root) and downstream (away from the root). Traffic can enter a bidirectional tree at any node 🔥. An MP2MP LSP is one kind of bidirectional tree, and multicast distribution trees created by Bidirectional Protocol Independent Multicast (BIDIR-PIM) [RFC5015] are bidirectional too.

Data traffic moving along a bidirectional multicast distribution tree is sometimes called "bidirectional traffic" in this document 🫶.

  • P-tunnel: A tunnel through the network of one or more SPs. In this document, the P-tunnels we talk about are set up as bidirectional multicast distribution trees 🦋.
  • SSM: Source-Specific Multicast. When SSM is in use, a multicast distribution tree carries traffic from only a single source 💖.
  • ASM: Any Source Multicast. When ASM is in use, some multicast distribution trees ("share trees") carry traffic from multiple sources 🌸.
  • C-S: Multicast Source. A multicast source address in the address space of a customer network 🎀.
  • C-G: Multicast Group. A multicast group address (destination address) in the address space of a customer network. When used without qualification, "C-G" can refer to either a unidirectional group address or a bidirectional group address 💜.
  • C-G-BIDIR: A bidirectional multicast group address, meaning a group address whose IP multicast distribution tree is built by BIDIR-PIM 🧚.
  • C-multicast flow or C-flow: A customer multicast flow. A C-flow travels through VPN customer sites on a multicast distribution tree that the customer sets up. These trees can be unidirectional or bidirectional, depending on the multicast routing protocol the customer uses. A C-flow travels between VPN customer sites by going through P-tunnels 🍓.

A C-flow from a particular customer source is identified by the ordered pair (source address, group address), where each address is in the customer's address space. The identifier of such a C-flow is usually written as (C-S,C-G) ✨.

If a customer uses the ASM model, some or all of their C-flows may travel along the same "shared tree". In that case, we'll talk about a "(C-*,C-G)" flow to mean a set of C-flows that travel along the same shared tree in the customer sites 🌈.

  • C-BIDIR flow or bidirectional C-flow: A C-flow that, in the VPN customer sites, travels along a bidirectional multicast distribution tree. The term "C-BIDIR flow" means the customer's bidirectional tree was set up by BIDIR-PIM 👑.
  • RP: A Rendezvous Point, as defined in [RFC4601] 💅.
  • C-RP: A Rendezvous Point whose address is in the customer's address space 🎀.
  • RPA: A Rendezvous Point Address, as defined in [RFC5015] 🦋.
  • C-RPA: An RPA in the customer's address space 🌸.
  • P-RPA: An RPA in the SP's address space 🧚.
  • Selective P-tunnel: A P-tunnel that is joined only by the PE routers that need to receive one or more of the C-flows traveling through that P-tunnel 💜.
  • Inclusive P-tunnel: A P-tunnel that is joined by all PE routers attached to sites of a given MVPN 🌈.
  • PMSI: Provider Multicast Service Interface. A PMSI is a conceptual overlay on a Service Provider backbone that lets a PE in a given MVPN multicast to the other PEs in that MVPN. PMSIs are instantiated by P-tunnels ✨.
  • I-PMSI: Inclusive PMSI. Traffic multicast by a PE on an I-PMSI is received by all other PEs in the MVPN. I-PMSIs are instantiated by Inclusive P-tunnels 🍓.
  • S-PMSI: Selective PMSI. Traffic multicast by a PE on an S-PMSI is received by some (but not necessarily all) of the other PEs in the MVPN. S-PMSIs are instantiated by Selective P-tunnels 🫶.
  • Intra-AS I-PMSI A-D route: Intra-AS (Autonomous System) Inclusive Provider Multicast Service Interface Auto-Discovery route. These routes are carried in BGP Update messages and can be used to advertise the use of Inclusive P-tunnels. See [RFC6514], Section 4.1 🦋.
  • S-PMSI A-D route: Selective Provider Multicast Service Interface Auto-Discovery route. Carried in BGP Update messages, these routes advertise the fact that a particular C-flow, or a particular set of C-flows, is bound to (that is, traveling through) a particular P-tunnel. See [RFC6514], Section 4.3 💖.
  • (C-S,C-G) S-PMSI A-D route: An S-PMSI A-D route whose NLRI (Network Layer Reachability Information) contains C-S in its Multicast Source field and C-G in its Multicast Group field 🌸.
  • (C-*,C-G) S-PMSI A-D route: An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its Multicast Source field and C-G in its Multicast Group field. See [RFC6625] 🎀.
  • (C-*,C-G-BIDIR) S-PMSI A-D route: An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its Multicast Source field and C-G-BIDIR in its Multicast Group field. See [RFC6625] 🧚.
  • (C-*,C-*) S-PMSI A-D route: An S-PMSI A-D route whose NLRI contains the wildcard C-* in its Multicast Source field and the wildcard C-* in its Multicast Group field. See [RFC6625] 🌈.
  • (C-*,C-*-BIDIR) S-PMSI A-D route: An S-PMSI A-D route whose NLRI contains the wildcard C-* in its Multicast Source field and the wildcard "C-*-BIDIR" in its Multicast Group field. See Section 2 of this document 👑.
  • (C-S,C-*) S-PMSI A-D route: An S-PMSI A-D route whose NLRI contains C-S in its Multicast Source field and the wildcard C-* in its Multicast Group field. See [RFC6625] ⭐.
  • Wildcard S-PMSI A-D route: A (C-*,C-G) S-PMSI A-D route, a (C-*,C-*) S-PMSI A-D route, a (C-S,C-*) S-PMSI A-D route, or a (C-*,C-*-BIDIR) S-PMSI A-D route 💅.
  • PTA: PMSI Tunnel attribute, a BGP attribute that identifies a P-tunnel. See [RFC6514], Section 8 🫶.

The terms used for categorizing S-PMSI A-D routes also get used for categorizing the S-PMSIs advertised by those routes. For example, the S-PMSI advertised by a (C-*,C-G) S-PMSI A-D route is known as a "(C-*,C-G) S-PMSI" 🦋.

Familiarity with multicast concepts and terminology [RFC4601] is also presupposed 🌸.

This specification uses the terms "match for transmission" and "match for reception" as they are defined in [RFC6625] 🎀. When it's clear from context whether we're talking about transmission or reception, we'll sometimes just say a C-flow "matching" an I-PMSI or S-PMSI A-D route 💖.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, when and only when appearing in all caps, are to be interpreted as described in [RFC2119] 🔥. Lowercase versions don't count, so this is the rule to know 💅.

1.2. Overview 🌸

The base documents for MVPN ([RFC6513] and [RFC6514]) define a "PMSI Tunnel attribute" (PTA) 🎀. This is a BGP Path attribute that may be attached to the BGP "I-PMSI A-D routes" and "S-PMSI A-D routes" defined in those documents 🦋. The base documents define how the identifier of a bidirectional P-tunnel is encoded in the PTA 💜. However, those documents don't contain the full set of specifications for using bidirectional P-tunnels. Instead, they declare the full set of specifications for using bidirectional P-tunnels to be outside their scope 🙈. In the same way, [RFC6625] declares the use of bidirectional P-tunnels advertised in wildcard S-PMSI A-D routes to be "outside the scope" of that document 💀.

This document gives the specifications for using bidirectional P-tunnels to provide MVPN support ✨. That includes the procedures for assigning C-flows to specific bidirectional P-tunnels, for advertising the fact that a particular C-flow has been assigned to a particular bidirectional P-tunnel, and for working out which bidirectional P-tunnel a given C-flow can be expected on 👑.

The C-flows carried on bidirectional P-tunnels can be either unidirectional or bidirectional themselves 🌈. Procedures are provided for both cases 💅.

This document does not specify any new data encapsulations for bidirectional P-tunnels. Section 12 ("Encapsulations") of [RFC6513] applies unchanged 🧚.

When it comes to the procedures for using bidirectional P-tunnels to instantiate PMSIs, if there's any conflict between the procedures in this document and the procedures of [RFC6513], [RFC6514], or [RFC6625], the procedures of this document take precedence 🔥.

The use of bidirectional P-tunnels to support extranets [MVPN-XNET] is outside the scope of this document 🍓. The use of bidirectional P-tunnels as "segmented P-tunnels" (see Section 8 of [RFC6513] and various sections of [RFC6514]) is also outside the scope of this document 🫶.

1.2.1. Bidirectional P-Tunnel Technologies 🦋

This document supports two different technologies for creating and maintaining bidirectional P-tunnels 💖:

  • Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs) that are created through the use of the Label Distribution Protocol (LDP) Multipoint-to-Multipoint extensions [RFC6388] 🌸.
  • Multicast distribution trees that are created through the use of BIDIR-PIM [RFC5015] 🎀.

Other bidirectional tunnel technologies are outside the scope of this document 🙈.

1.2.2. Reasons for Using Bidirectional P-Tunnels ✨

okay so bidirectional P-tunnels can be used to instantiate I-PMSIs and/or S-PMSIs 🫶

An SP might decide to use bidirectional P-tunnels to instantiate certain I-PMSIs and/or S-PMSIs so it can give its customers C-BIDIR support 💅 It does this with the "Partitioned Set of PEs" technique from Section 11.2 of [RFC6513] and Section 3.6 of [RFC6517]. This technique works whether the C-BIDIR flows are riding on an I-PMSI or an S-PMSI. Iconic 👑

Even if an SP doesn't need C-BIDIR support, it can still choose bidirectional P-tunnels to save state in the network's transit nodes 🧚 For example, say an MVPN has n PEs attached to sites with multicast sources, and there's an I-PMSI for that MVPN. If you instantiate that I-PMSI with unidirectional P-tunnels (that's P2MP multicast distribution trees), you need n multicast distribution trees, each one rooted at a different PE 😭 But if the I-PMSI uses a bidirectional P-tunnel, a single multicast distribution tree can do the job, assuming the provisioning system supports it properly 🌸

An SP can pick bidirectional P-tunnels for either or both of these reasons. Also, even if the whole point is C-BIDIR support, the same P-tunnels can still carry unidirectional C-flows if that's what the SP wants 🦋

ngl these two reasons kinda clash, because (as we'll see in later sections) using bidirectional P-tunnels for C-BIDIR support may need multiple bidirectional P-tunnels per VPN 💀 Each one of those P-tunnels is tied to a specific "distinguished PE", and it can only carry the C-BIDIR flows whose C-RPAs are reachable through that distinguished PE. BUT, on platforms that support MPLS upstream-assigned labels ([RFC5331]), PE Distinguisher Labels (Section 4 of [RFC6513] and Section 8 of [RFC6514]) can be used to bundle multiple bidirectional P-tunnels into one outer bidirectional P-tunnel. So you get C-BIDIR support with minimal state at the transit nodes. Main character energy 🎀

Since there are two totally different reasons for using bidirectional P-tunnels, and since lots of deployed router platforms don't support upstream-assigned labels right now, this document specifies several methods of using bidirectional P-tunnels to instantiate PMSIs. We call these "PMSI Instantiation Methods" 🌈 Which method or methods an SP ends up using depends on its goals, its engineering trade-offs, and the platforms it has deployed ⭐

The rules for using bidirectional P-tunnels in I-PMSI or S-PMSI A-D routes are not exactly the same as the rules for unidirectional P-tunnels, and the rules also differ between the PMSI instantiation methods. Later sections of this document spell out the rules in detail 📖

1.2.3. Knowledge of Group-to-RP and/or Group-to-RPA Mappings 🍓

If a VPN customer is using a particular ASM group address, the PEs of that VPN generally need to know the group-to-RP mappings used within the VPN. If a VPN customer is using BIDIR-PIM group addresses, the PEs need to know the group-to-RPA mappings used within the VPN. Usually the PEs get this knowledge either through provisioning or by joining a dynamic "group-to-RP(A) mapping discovery protocol" that runs within the VPN. How that knowledge gets obtained is outside the scope of this document 🙈

The PEs also need to be able to forward traffic towards the C-RPs and/or C-RPAs, and to figure out whether the next-hop interface of the route to a particular C-RP(A) is a VRF interface or a PMSI. This is handled by following the procedures in Section 5.1 of [RFC6513] 💜

1.2.4. PMSI Instantiation Methods 🦋

This document specifies three methods for using bidirectional P-tunnels to instantiate PMSIs: two partitioned methods (the Flat Partitioned Method and the Hierarchical Partitioned Method) and the Unpartitioned Method. 🫧

  • Partitioned Methods

In the Partitioned Methods, a particular PMSI is instantiated by a set of bidirectional P-tunnels. These P-tunnels can be aggregated (as inner P-tunnels) into a single outer bidirectional P-tunnel ("Hierarchical Partitioning"), or they can stay unaggregated ("Flat Partitioning"). Any PE that joins one of these P-tunnels can transmit a packet on it, and the packet will be received by all the other PEs that have joined the P-tunnel. For each such P-tunnel (each inner P-tunnel, in the case of Hierarchical Partitioning) there is one PE that is its distinguished PE. When a PE receives a packet from a given P-tunnel, it can tell from the packet's encapsulation which P-tunnel the packet arrived on, and so it can infer the identity of the distinguished PE associated with the packet. This association plays an important role in how the packet is treated, as specified later in this document 🔥

The number of P-tunnels needed (the number of inner P-tunnels needed, if Hierarchical Partitioning is used) depends on a number of factors that are described later in this document.

The Hierarchical Partitioned Method requires the use of upstream-assigned MPLS labels (PE Distinguisher Labels) and requires the use of the PE Distinguisher Labels attribute in BGP. The Flat Partitioned Method requires neither of these 💅

The Partitioned Method (either Flat or Hierarchical) is a prerequisite for implementing the "Partitioned Sets of PEs" technique of supporting C-BIDIR, as discussed in [RFC6513], Section 11.2. The Partitioned Method (either Flat or Hierarchical) is also a prerequisite for applying the "Discarding Packets from Wrong PE" technique, discussed in [RFC6513], Section 9.1.1, to a PMSI that is instantiated by a bidirectional P-tunnel 🌸

The Flat Partitioned Method is a prerequisite for implementing the "Partial Mesh of MP2MP P-Tunnels" technique for carrying customer bidirectional (C-BIDIR) traffic, as discussed in [RFC6513], Section 11.2.3 ✨

The Hierarchical Partitioned Method is a prerequisite for implementing the "Using PE Distinguisher Labels" technique of carrying customer bidirectional (C-BIDIR) traffic, as discussed in [RFC6513], Section 11.2.2 🧚

Note that a particular deployment may use the Partitioned Methods for carrying C-BIDIR traffic on bidirectional P-tunnels, while carrying other traffic either on unidirectional P-tunnels or on bidirectional P-tunnels using the Unpartitioned Method. Routers in a given deployment must be provisioned to know which PMSI instantiation method to use for which PMSIs 🎀

There may be ways of implementing the Partitioned Methods with PMSIs that are instantiated by unidirectional P-tunnels. (See, e.g., [MVPN-BIDIR-IR].) However, that is outside the scope of the current document 🙃

  • Unpartitioned Method

In the Unpartitioned Method, a particular PMSI can be instantiated by a single bidirectional P-tunnel. Any PE that joins the tunnel can transmit a packet on it, and the packet will be received by all the other PEs that have joined the tunnel. The receiving PEs can determine the tunnel the packet was transmitted on, but they cannot determine which PE transmitted the packet, nor can they associate the packet with any particular distinguished PE 💀

When the Unpartitioned Method is used, this document does not mandate that only one bidirectional P-tunnel be used to instantiate each PMSI. It allows for the case where more than one P-tunnel is used. In that case, the transmitting PEs have a choice of which such P-tunnel to use when transmitting, and the receiving PEs must be prepared to receive from any of those P-tunnels. Using multiple P-tunnels here gives additional robustness, but it doesn't give additional functionality 🫶

If bidirectional P-tunnels are being used to instantiate the PMSIs of a given MVPN, one of these methods must be chosen for that MVPN. All the PEs of that MVPN must be provisioned to know the method being used for that MVPN 🌈

I-PMSIs may be instantiated by bidirectional P-tunnels using either the Partitioned (either Flat or Hierarchical) Methods or the Unpartitioned Method. The method used for a given MVPN is determined by provisioning. It SHOULD be possible to provision this on a per-MVPN basis, but all the VRFs of a single MVPN MUST be provisioned to use the same method for the given MVPN's I-PMSI 🍓

If a bidirectional P-tunnel is used to instantiate an S-PMSI (including the case of a (C-,C-) S-PMSI), either the Partitioned Methods (either Flat or Hierarchical) or the Unpartitioned Method may be used. The method used by a given VRF is determined by provisioning. It is desirable to be able to provision this on a per-MVPN basis. All the VRFs of a single MVPN MUST be provisioned to use the same method for those of their S-PMSIs that are instantiated by bidirectional P-tunnels ⭐

If one of the Partitioned Methods is used, all the VRFs of a single MVPN MUST be provisioned to use the same variant of the Partitioned Methods, i.e., either they must all use the Flat Partitioned Method or they must all use the Hierarchical Partitioned Method 🔥

It is valid to use the Unpartitioned Method to instantiate the I-PMSIs, while using one of the Partitioned Methods to instantiate the S-PMSIs 💜

It is valid to instantiate some S-PMSIs by unidirectional P-tunnels and others by bidirectional P-tunnels 🌸

The procedures for using bidirectional P-tunnels, specified in later sections of this document, depend on both the tunnel technology and the PMSI instantiation method. Note that this document does not specify procedures for every possible combination of tunnel technology and PMSI instantiation method 🧚

2. The All BIDIR-PIM Wildcard ✨

Okay so [RFC6514] is the spec that explains how to squish C-multicast source and group addresses into the NLRI of certain BGP routes 🧚. Then [RFC6625] comes along and lets the source and/or group address get swapped out for a wildcard 💅. Iconic.

Now, when an MVPN customer is running BIDIR-PIM, it's really useful to advertise an S-PMSI A-D route that basically says "by default, all BIDIR-PIM C-multicast traffic (within a given VPN) that hasn't been bound to any other P-tunnel goes into the bidirectional P-tunnel named in this route's PTA" 🦋. This is especially helpful if you're using a bidirectional P-tunnel for the C-BIDIR flows and unidirectional P-tunnels for everything else. To make that work, you need a way to encode a (C-*,C-*) wildcard that only covers BIDIR-PIM C-groups. Main character energy 👑.

So we define a special value of the group wildcard that means "all BIDIR-PIM groups" 🌸. The "BIDIR-PIM groups wildcard" is a group field with a length of 8 bits and a value of zero. In other words, the multicast group length field holds 0x08, and the multicast group field is a single octet holding 0x00. (This encoding is different from the group wildcard encoding in [RFC6625], so don't mix them up 🙈.) We'll use the notation (C-*,C-*-BIDIR) to refer to the "all BIDIR-PIM groups" wildcard.

3. Using Bidirectional P-Tunnels 🎀

A bidirectional P-tunnel can be advertised in the PTA of an Intra-AS I-PMSI A-D route or in the PTA of an S-PMSI A-D route. Advertising a bidirectional P-tunnel in the PTA of an Inter-AS I-PMSI A-D route is outside the scope of this document, so we're not going there today 🙅‍♀️.

3.1. Procedures Specific to the Tunneling Technology 🧩

This section covers the procedures that are specific to a given tunneling technology (BIDIR-PIM, or the MP2MP procedures of mLDP (Multipoint LDP)). These procedures don't depend on which method (Unpartitioned, Flat Partitioned, or Hierarchical Partitioned) is used to instantiate a PMSI, so they're a whole vibe on their own 💜.

3.1.1. BIDIR-PIM P-Tunnels 🦋

Each BIDIR-PIM P-tunnel is identified by a unique P-group address ([RFC6513], Section 3.1). (The P-group address is called a "P-Multicast Group" in [RFC6514].) Section 5 of [RFC6514] tells you how to identify a particular BIDIR-PIM P-tunnel in the PTA of an I-PMSI or S-PMSI A-D route 📜.

Ordinary BIDIR-PIM procedures are used to set up the BIDIR-PIM P-tunnels. A BIDIR-PIM P-group address is always associated with one unique Rendezvous Point Address (RPA) in the SP's address space. We'll call this the "P-RPA" 🌈. Every PE that needs to join a particular BIDIR-PIM P-tunnel must be able to work out the P-RPA that matches the P-tunnel's P-group address. To build the P-tunnel, PIM Join/Prune messages get sent along the path from the PE to the P-RPA. Any P routers on that path must also be able to determine the P-RPA, so they can send their own PIM Join/Prune messages toward it 🚀. The way you map a P-group address to an RPA can be static configuration, or some automated means of RPA discovery. That automated part is outside the scope of this specification, so it's not covered here 🤷‍♀️.

If a BIDIR-PIM P-tunnel is used to instantiate an I-PMSI or an S-PMSI, it is RECOMMENDED that the path from each PE in the tunnel to the RPA consist entirely of point-to-point links. On a point-to-point link there's no ambiguity about which router is upstream toward a particular RPA, so the BIDIR-PIM "Designated Forwarder Election" is super quick and simple ✨. Using a BIDIR-PIM P-tunnel with multiaccess links is possible, but it's considerably more complex 😭.

Using BIDIR-PIM P-tunnels to support the Hierarchical Partitioned Method is outside the scope of this document 🙅‍♀️.

When the PTA of an Intra-AS I-PMSI A-D route or an S-PMSI A-D route identifies a BIDIR-PIM tunnel, the originator of the route SHOULD NOT include a PE Distinguisher Labels attribute. If it does, that attribute MUST be ignored. When we say the attribute is "ignored", we don't mean its normal BGP processing is skipped. We mean the attribute has no effect on the data plane. However, it MUST be treated by BGP as if it were an unsupported optional transitive attribute 💅. (PE Distinguisher Labels are used for the Hierarchical Partitioning Method, but this document doesn't support the Hierarchical Partitioning Method with BIDIR-PIM P-tunnels, so it's not giving for this combo 💀.)

3.1.2. MP2MP LSPs 🌊

Each MP2MP LSP is identified by a unique "MP2MP FEC (Forwarding Equivalence Class) element" [RFC6388]. The FEC element contains the IP address of the root node, followed by an opaque value that uniquely identifies the MP2MP LSP within the context of the root node's IP address. That opaque value can be configured or autogenerated, and there's no need for different root nodes to use the same opaque value for a given MVPN 🍓.

The mLDP specification supports several different ways of constructing tunnel identifiers. The current specification doesn't restrict which type or types of tunnel identifier a deployment can use. A given implementation isn't expected to be able to advertise (in the PTAs of I-PMSI or S-PMSI A-D routes) tunnel identifiers of every possible type. However, an implementation SHOULD be able to accept and properly process a PTA that uses any legal type of tunnel identifier 🫶.

Section 5 of [RFC6514] specifies the way to identify a particular MP2MP P-tunnel in the PTA of an I-PMSI or S-PMSI A-D route 📜.

Ordinary mLDP procedures for MP2MP LSPs are used to set up the MP2MP LSP 🧚.

3.2. Procedures Specific to the PMSI Instantiation Method 🎯

When either the Flat Partitioned Method or the Hierarchical Partitioned Method is used to implement the "Partitioned Sets of PEs" method of supporting C-BIDIR (as discussed in Section 11.2 of [RFC6513] and Section 3.6 of [RFC6517]), a C-BIDIR flow MUST be carried only on an I-PMSI or on a (C-*,C-G-BIDIR), (C-*,C-*-BIDIR), or (C-*,C-*) S-PMSI. A PE MUST NOT originate any (C-S,C-G-BIDIR) S-PMSI A-D routes. (A PE can still originate (C-S,C-G) S-PMSI A-D routes for C-Gs that aren't C-BIDIR groups, obviously 💖.) Packets of a C-BIDIR flow MUST NOT be carried on a (C-S,C-*) S-PMSI 🙅‍♀️.

Sections 3.2.1 and 3.2.2 spell out additional details for the two Partitioned Methods 📖.

3.2.1. Flat Partitioning 🌸

The procedures in this section and its subsections apply when (and only when) the Flat Partitioned Method is used. This method is introduced in [RFC6513], Section 11.2.3, where it's called "Partial Mesh of MP2MP P-Tunnels". It can be used with MP2MP LSPs or with BIDIR-PIM P-tunnels 🦋.

When a PE originates an I-PMSI or S-PMSI A-D route whose PTA specifies a bidirectional P-tunnel, the PE MUST be the root node of the specified P-tunnel 👑.

If BIDIR-PIM P-tunnels are used, each advertised P-tunnel MUST have a distinct P-group address. The PE advertising the tunnel is considered to be the root node of the tunnel. Note that this creates a unique mapping from P-group address to root node. The assignment of P-group addresses to MVPNs is done by provisioning 🛠️.

If MP2MP LSPs are used, each P-tunnel MUST have a distinct MP2MP FEC (i.e., a distinct combination of root node and opaque value). The PE advertising the tunnel MUST be the same PE identified in the root node field of the MP2MP FEC that's encoded in the PTA 🌈.

It follows that two different PEs may not advertise the same bidirectional P-tunnel. Any PE that receives a packet from the P-tunnel can infer the identity of the P-tunnel from the packet's encapsulation. Once the identity of the P-tunnel is known, the root node of the P-tunnel is also known. The root node of the P-tunnel that the packet arrived on is treated as the distinguished PE for that packet 🔥.

The Flat Partitioned Method doesn't use upstream-assigned labels in the data plane, so it doesn't use the BGP PE Distinguisher Labels attribute. When this method is used, I-PMSI and/or S-PMSI A-D routes SHOULD NOT contain a PE Distinguisher Labels attribute. If such an attribute is present in a received I-PMSI or S-PMSI A-D route, it MUST be ignored. (When we say the attribute is "ignored", we don't mean its normal BGP processing is skipped. We mean the attribute has no effect on the data plane. It MUST, however, be treated by BGP as if it were an unsupported optional transitive attribute 💅.)

When the Flat Partitioned Method is used to instantiate the I-PMSIs of a given MVPN, every PE in that MVPN that originates an Intra-AS I-PMSI A-D route MUST include a PTA that specifies a bidirectional P-tunnel. If the goal is to carry C-BIDIR traffic on the I-PMSI, a PE MUST originate an Intra-AS I-PMSI A-D route if one of its VRF interfaces is the next-hop interface on its best path to the C-RPA of any bidirectional C-group of the MVPN 🫶.

When the Flat Partitioned Method is used to instantiate a (C-*,C-*) S-PMSI, a (C-*,C-*-BIDIR) S-PMSI, or a (C-*,C-G-BIDIR) S-PMSI, a PE that originates the corresponding S-PMSI A-D route MUST include in that route a PTA specifying a bidirectional P-tunnel. Per the procedures of [RFC6513] and [RFC6514], a PE will originate such an S-PMSI A-D route only if one of the PE's VRF interfaces is the next-hop interface on the PE's best path to the C-RPA of a C-BIDIR group that's supposed to be carried on the specified S-PMSI 🎀.

PMSIs instantiated via the Flat Partitioned Method may carry customer bidirectional traffic AND customer unidirectional traffic 🌈. The rules in Sections 3.2.1.1 and 3.2.1.2 determine when a given customer multicast packet matches for transmission to a given PMSI. However, if the "Partitioned Set of PEs" method of supporting C-BIDIR traffic is being used for a given MVPN, the PEs must be provisioned so that packets from a C-BIDIR flow of that MVPN never match any PMSI that isn't instantiated by a bidirectional P-tunnel. (For example, if the given MVPN's (C-*,C-*) S-PMSI weren't instantiated by a bidirectional P-tunnel, one way to meet this requirement is to carry all C-BIDIR traffic of that MVPN on a (C-*,C-*-BIDIR) S-PMSI 🧠.)

When a PE receives a customer multicast data packet from a bidirectional P-tunnel, it associates that packet with a distinguished PE. The distinguished PE for a given packet is the root node of the tunnel the packet was received from. The rules in Sections 3.2.1.1 and 3.2.1.2 ensure that:

  • If the received packet is part of a unidirectional C-flow, its distinguished PE is the PE that transmitted the packet onto the P-tunnel.
  • If the received packet is part of a bidirectional C-flow, its distinguished PE is not necessarily the PE that transmitted it, but rather the transmitter's upstream PE [RFC6513] for the C-RPA of the bidirectional C-group.

The rules in Sections 3.2.1.3 and 3.2.1.4 let the receiving PEs work out the expected distinguished PE for each C-flow, and they make sure a packet gets discarded if its distinguished PE isn't the expected distinguished PE for the C-flow it belongs to. That's how duplicate data is prevented for both bidirectional and unidirectional C-flows 🎉.

3.2.1.1. When an S-PMSI Is a 'Match for Transmission' 💖

Okay so, say PE1 needs to send multicast data packets for a particular C-flow 🦋. [RFC6625] Section 3.1 has a four-step algorithm for working out which S-PMSI A-D route, if any, matches that C-flow for transmission. Main character energy 👑

If the C-flow is not a BIDIR-PIM C-flow, those rules just apply unchanged 💅. The rest of this section is only for C-BIDIR flows. If a C-BIDIR flow has group address C-G-BIDIR, these are the rules PE1 follows:

  • If the C-RPA for C-G-BIDIR is a C-address of PE1, or if PE1's route to the C-RPA is via a VRF interface, then:
    • If there is a (C-*,C-G-BIDIR) S-PMSI A-D route currently originated by PE1, the C-flow matches that route.
    • Otherwise, if there is a (C-*,C-*-BIDIR) S-PMSI A-D route currently originated by PE1, the C-flow matches that route.
    • Otherwise, if there is a (C-*,C-*) S-PMSI A-D route currently originated by PE1, the C-flow matches that route.
  • If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be some other PE, say PE2, then:
    • If there is an installed (C-*,C-G-BIDIR) S-PMSI A-D route originated by PE2, the C-flow matches that route.
    • Otherwise, if there is an installed (C-*,C-*-BIDIR) S-PMSI A-D route originated by PE2, the C-flow matches that route.
    • Otherwise, if there is an installed (C-*,C-*) S-PMSI A-D route originated by PE2, the C-flow matches that route.

If there is an S-PMSI A-D route that matches a given C-flow, and PE1 needs to transmit packets of that C-flow or other PEs, then it MUST transmit those packets on the bidirectional P-tunnel identified in the PTA of the matching S-PMSI A-D route. ✨

3.2.1.2. When an I-PMSI Is a 'Match for Transmission' 🌸

Suppose PE1 needs to transmit packets of a given C-flow (of a given MVPN) to other PEs 🫶. But under the conditions of Section 3.2.1.1 and/or Section 3.1 of [RFC6625], that C-flow doesn't match any S-PMSI A-D route. So its packets need to go out on the MVPN's I-PMSI. Okay, that's the fallback, and it's giving backup plan 🧚.

If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel the C-flow MUST be transmitted on is the one identified in the PTA of the Intra-AS I-PMSI A-D route PE1 originated for the given MVPN.

If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, these are the rules PE1 applies:

  • Suppose that the C-RPA for C-G-BIDIR is a C-address of PE1, or that PE1's route to the C-RPA is via a VRF interface. Then, if there is an I-PMSI A-D route currently originated by PE1, the C-flow MUST be transmitted on the P-tunnel identified in the PTA of that I-PMSI A-D route.
  • If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be some other PE, say PE2, then if there is an installed I-PMSI A-D route originated by PE2, the C-flow MUST be transmitted on the P-tunnel identified in the PTA of that route.

If there is no I-PMSI A-D route meeting the above conditions, the C-flow MUST NOT be transmitted. 🙈

3.2.1.3. When an S-PMSI Is a 'Match for Reception' 🎀

Suppose PE1 needs to receive multicast data packets of a particular C-flow. [RFC6625] Section 3.2 spells out how to figure out which S-PMSI A-D route, if any, matches that C-flow for reception. Those rules apply unchanged for C-flows that aren't BIDIR-PIM C-flows. The rest of this section is only for C-BIDIR flows 💜.

The rules of [RFC6625] Section 3.2.1 don't apply to C-BIDIR flows at all. The rules of [RFC6625] Section 3.2.2 get replaced by the following rules ✨.

Suppose PE1 needs to receive (C-*,C-G-BIDIR) traffic. Suppose also that PE1 has determined that PE2 is the upstream PE [RFC6513] for the C-RPA of C-G-BIDIR. Then:

  • If PE1 is not the same as PE2, and PE1 has an installed (C-*,C-G-BIDIR) S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR) matches this route.
  • Otherwise, if PE1 is the same as PE2, and PE1 has currently originated a (C-*,C-G-BIDIR) S-PMSI A-D route, then (C-*,C-G-BIDIR) matches this route.
  • Otherwise, if PE1 is not the same as PE2, and PE1 has an installed (C-*,C-*-BIDIR) S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR) matches this route.
  • Otherwise, if PE1 is the same as PE2, and PE1 has currently originated a (C-*,C-*-BIDIR) S-PMSI A-D route, then (C-*,C-G-BIDIR) matches this route.
  • Otherwise, if PE1 is not the same as PE2, and PE1 has an installed (C-*,C-*) S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR) matches this route.
  • Otherwise, if PE1 is the same as PE2, and PE1 has currently originated a (C-*,C-*) S-PMSI A-D route, then (C-*,C-G-BIDIR) matches this route.

If there is an S-PMSI A-D route matching (C-*,C-G-BIDIR) under these rules, the root node of that P-tunnel is considered to be the distinguished PE for that (C-*,C-G-BIDIR) flow. If a (C-*,C-G-BIDIR) packet arrives on a P-tunnel whose root node is not the distinguished PE for the C-flow, the packet MUST be discarded. 🚫

3.2.1.4. When an I-PMSI Is a 'Match for Reception' 🦋

Suppose PE1 needs to receive packets of a given C-flow (of a given MVPN) from another PE. But under the conditions of Section 3.2.1.3 and/or [RFC6625] Section 3.2, that C-flow doesn't match any S-PMSI A-D route. So the packets of the C-flow need to be received on the MVPN's I-PMSI 🌈.

If the C-flow is not a BIDIR-PIM C-flow, the rules for working out the P-tunnel that packets of the C-flow are expected on are in [RFC6513]. The rest of this section only applies to C-BIDIR flows.

Suppose PE1 needs to receive (C-*,C-G-BIDIR) traffic from other PEs. Suppose also that PE1 has determined that PE2 is the upstream PE [RFC6513] for the C-RPA of C-G-BIDIR. Then PE1 considers PE2 to be the distinguished PE for (C-*,C-G-BIDIR). If PE1 has an installed Intra-AS I-PMSI A-D route originated by PE2, PE1 will expect to receive packets of the C-flow from the tunnel specified in that route's PTA. (If all VRFs of the MVPN have been properly provisioned to use the Flat Partitioned Method for the I-PMSI, the PTA will specify a bidirectional P-tunnel.) Note that if PE1 is the same as PE2, then the relevant Intra-AS I-PMSI A-D route is the one currently originated by PE1 🙌.

If a (C-*,C-G-BIDIR) packet is received on a P-tunnel other than the expected one, the packet MUST be discarded. 💀

3.2.2. Hierarchical Partitioning 🧩

The procedures in this section and its subsections apply when (and only when) the Hierarchical Partitioned Method is used. This method is introduced in [RFC6513] Section 11.2.2. This document only provides procedures for using this method when MP2MP LSPs are the P-tunnels 🔥.

The Hierarchical Partitioned Method gives you the same functionality as the Flat Partitioned Method, but it needs a smaller amount of state kept in the core of the network. The catch is that it REQUIRES upstream-assigned MPLS labels ("PE Distinguisher Labels"), which aren't necessarily supported by all hardware platforms 😭. The upstream-assigned labels are used to build an LSP hierarchy, where an outer MP2MP LSP carries multiple inner MP2MP LSPs. Transit routers along the path between PE routers then only need to keep state for the outer MP2MP LSP 🍓.

When this method is used to instantiate a particular PMSI, the bidirectional P-tunnel advertised in the PTA of the corresponding I-PMSI or S-PMSI A-D route is the outer P-tunnel. When a PE receives a packet from a P-tunnel, it can work out the identity of the outer P-tunnel from the MPLS label that has risen to the top of the packet's label stack. However, the packet's distinguished PE is not necessarily the root node of the outer P-tunnel. Instead, the identity of the packet's distinguished PE is inferred from the PE Distinguisher Label further down in the label stack (see [RFC6513] Section 12.3). You can think of the PE Distinguisher Label as identifying an inner MP2MP LSP whose root is the PE corresponding to that label 🦋.

In the context of a given MVPN, if it's desired to use the Hierarchical Partitioned Method to instantiate an I-PMSI, a (C-*,C-*) S-PMSI, or a (C-*,C-*-BIDIR) S-PMSI, the corresponding A-D routes MUST be originated by some of the PEs attached to that MVPN. The PEs that are REQUIRED to originate these routes are the ones that satisfy one of the following conditions:

  • There is a C-BIDIR group for which the best path from the PE to the C-RPA of that C-group is via a VRF interface.
  • The PE might have to transmit unidirectional customer multicast traffic on the PMSI identified in the route (of course, this condition does not apply to (C-*,C-*-BIDIR) or to (C-*,C-G-BIDIR) S-PMSIs).
  • The PE is the root node of the MP2MP LSP that is used to instantiate the PMSI.

When the Hierarchical Partitioned Method is used to instantiate a (C-*,C-G-BIDIR) S-PMSI, the corresponding (C-*,C-G-BIDIR) S-PMSI route MUST NOT be originated by a given PE unless either (a) that PE's best path to the C-RPA for C-G-BIDIR is via a VRF interface, or (b) the C-RPA is a C-address of the PE. Further, that PE MUST be the root node of the MP2MP LSP identified in the PTA of the S-PMSI A-D route. 🚦

If any VRF of a given MVPN uses this method to instantiate an S-PMSI with a bidirectional P-tunnel, all VRFs of that MVPN must use this method 💅.

Suppose that for a given MVPN, the Hierarchical Partitioned Method is used to instantiate the I-PMSI. In general, more than one of the PEs in the MVPN will originate an Intra-AS I-PMSI A-D route for that MVPN. This document allows the PTAs of those routes to all specify the same MP2MP LSP as the "outer tunnel". However, it does not require that those PTAs all specify the same MP2MP LSP as the outer tunnel. If all the PEs specify the same outer tunnel for the I-PMSI, you can minimise the amount of state in the transit nodes 🧚. If they're allowed to specify different outer tunnels, you use more state, but the system may get more robust 🌈.

The considerations of the previous paragraph apply as well when the Hierarchical Partitioned Method is used to instantiate an S-PMSI. 🫶

3.2.2.1. Advertisement of PE Distinguisher Labels ✨

Okay so, a PE Distinguisher Label is an upstream-assigned MPLS label [RFC5331] 💖 that can be used, in the context of an MP2MP LSP, to point at a particular PE that either has joined or might join that LSP later 🦋.

To use upstream-assigned MPLS labels with an outer MP2MP LSP, there has to be a convention that says which router is in charge of allocating the labels and advertising them to the PEs that might join the MP2MP LSP 🫶. This document REQUIRES that the PE Distinguisher Labels used with a given MP2MP LSP be allocated and advertised by the router that is the root node of that LSP 👑.

This convention lines up with the rules in Section 7 of [RFC5331]. Heads up, though: according to Section 7 of [RFC5331], upstream-assigned labels are unique in the context of the IP address of the root node. So if two MP2MP LSPs have the same root node IP address, the upstream-assigned labels used in those two LSPs come from the same label space 🌈.

This document assumes that the root node address of an MP2MP LSP is an IP address that is uniquely assigned to the node. Using an "anycast address" as the root node address is outside the scope of this document 🙈.

A PE Distinguisher Labels attribute SHOULD NOT be attached to an I-PMSI or S-PMSI A-D route unless that route also contains a PTA that specifies an MP2MP LSP. (While PE Distinguisher Labels could in theory also be used if the PTA specifies a BIDIR-PIM P-tunnel, that use is outside the scope of this document 💅.)

The PE Distinguisher Labels attribute specifies a set of <MPLS label, IP address> bindings. Within a given PE Distinguisher Labels attribute, each such IP address MUST appear at most once, and each MPLS label MUST appear only once. If that isn't the case, the attribute is considered to be malformed, and the "treat-as-withdraw" error-handling approach described in Section 2 of [BGP-ERROR] MUST be used 💀.

When a PE Distinguisher Labels attribute is included in a given I-PMSI or S-PMSI A-D route, it MUST assign a label to the IP address of each of the following PEs:

  • The root node of the MP2MP LSP identified in the PTA of the route.
  • Any PE that is possibly the ingress PE for a C-RPA of any C-BIDIR group.
  • Any PE that may need to transmit non-C-BIDIR traffic on the MP2MP LSP identified in the PTA of the route.

One simple way to meet these requirements is to assign a PE Distinguisher label to every PE that has originated an Intra-AS I-PMSI A-D route 🍓.

3.2.2.2. When an S-PMSI Is a 'Match for Transmission' 🦋

Suppose a given PE, let's call it PE1, needs to transmit multicast data packets of a particular C-flow. Section 3.1 of [RFC6625] gives a four-step algorithm for figuring out which S-PMSI A-D route, if any, matches that C-flow for transmission 🔍.

If the C-flow is not a BIDIR-PIM C-flow, those rules apply unchanged ✨. If there is a matching S-PMSI A-D route, the P-tunnel on which the C-flow MUST be transmitted is the one identified in the PTA of the matching route. Each packet of the C-flow MUST carry the PE Distinguisher Label that the root node of that P-tunnel assigned to the IP address of PE1. See Section 12.3 of [RFC6513] for encapsulation details 🎀.

The rest of this section only applies to C-BIDIR flows. If a C-BIDIR flow has group address C-G-BIDIR, the rules PE1 applies are the same as the rules in Section 3.2.1.1 💜.

If there is a matching S-PMSI A-D route, PE1 MUST transmit the C-flow on the P-tunnel identified in its PTA. Now, suppose PE1 has determined that PE2 is the upstream PE for the C-RPA of the given C-flow. When PE1 builds the packet's MPLS label stack, it has to use the PE Distinguisher Label that the P-tunnel's root node assigned to the IP address of "PE2", not the label assigned to the IP address of "PE1" (unless, of course, PE1 is the same as PE2). See Section 12.3 of [RFC6513] for encapsulation details. Also, the root of the P-tunnel might be a PE other than PE1 or PE2 🌸.

3.2.2.3. When an I-PMSI Is a 'Match for Transmission' 🌈

Suppose a given PE, PE1 again, needs to transmit packets of a given C-flow (of a given MVPN) to other PEs. But according to the conditions in Section 3.2.2.2 and/or Section 3.1 of [RFC6625], that C-flow doesn't match any S-PMSI A-D route. In that case, the packets of the C-flow need to be transmitted on the MVPN's I-PMSI 🧚.

If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the C-flow MUST be transmitted is the one identified in the PTA of the Intra-AS I-PMSI A-D route that PE1 originated for the given MVPN. Each packet of the C-flow MUST carry the PE Distinguisher Label that the root node of that P-tunnel assigned to the IP address of PE1 💖.

If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the rules PE1 applies are the same as the ones in Section 3.2.1.2 🦋.

If there is a matching I-PMSI A-D route, PE1 MUST transmit the C-flow on the P-tunnel identified in its PTA. When building the packet's MPLS label stack, PE1 has to use the PE Distinguisher Label that the P-tunnel's root node assigned to the IP address of "PE2", not the label assigned to the IP address of "PE1" (unless, of course, PE1 is the same as PE2). (Section 3.2.1.2 explains the difference between PE1 and PE2 🫶.) See Section 12.3 of [RFC6513] for encapsulation details. The root of the P-tunnel might also be a PE other than PE1 or PE2.

If, for a packet of a particular C-flow, there is no S-PMSI A-D route or I-PMSI A-D route that is a match for transmission, the packet MUST NOT be transmitted 🚫.

3.2.2.4. When an S-PMSI Is a 'Match for Reception' 📥

Suppose a given PE, PE1, needs to receive multicast data packets of a particular C-flow. Section 3.2 of [RFC6625] specifies the procedures for working out which S-PMSI A-D route, if any, matches that C-flow for reception. Those rules require that the matching S-PMSI A-D route was originated by the upstream PE for the C-flow. This section modifies those rules, as follows 🔧:

Consider a particular C-flow. Suppose either:

  • the C-flow is unidirectional, and PE1 determines that its upstream PE is PE2, or
  • the C-flow is bidirectional, and PE1 determines that the upstream PE for its C-RPA is PE2.

Then, the C-flow may match an installed S-PMSI A-D route that was not originated by PE2, as long as:

  1. the PTA of that A-D route identifies an MP2MP LSP,
  2. there is an installed S-PMSI A-D route originated by the root node of that LSP, or PE1 itself is the root node of the LSP and there is a currently originated S-PMSI A-D route from PE1 whose PTA identifies that LSP, and
  3. the latter S-PMSI A-D route (the one identified in 2 just above) contains a PE Distinguisher Labels attribute that assigned an MPLS label to the IP address of PE2.

However, a bidirectional C-flow never matches an S-PMSI A-D route whose NLRI contains (C-S,C-G) 🙅‍♀️.

If a multicast data packet is received over a matching P-tunnel but does not carry the value of the PE Distinguisher Label that has been assigned to the upstream PE for its C-flow, then the packet MUST be discarded 🗑️.

3.2.2.5. When an I-PMSI Is a 'Match for Reception' 🎀

If a PE needs to receive packets of a given C-flow (of a given MVPN) from another PE, and according to the conditions in Section 3.2.2.4 that C-flow doesn't match any S-PMSI A-D route, then the packets of the C-flow need to be received on the MVPN's I-PMSI 💜. The P-tunnel on which those packets are expected to arrive is determined by the Intra-AS I-PMSI A-D route originated by the distinguished PE for the given C-flow. The PTA of that route specifies the "outer P-tunnel," and so it determines the top label that packets of that C-flow will carry when they're received. A PE that needs to receive packets of a given C-flow has to work out the expected value of the second label for those packets. That will be the value of a PE Distinguisher Label, taken from the PE Distinguisher Labels attribute of the Intra-AS I-PMSI A-D route of the root node of that outer tunnel. The expected value of the second label on received packets (corresponding to the "inner tunnel") of a given C-flow is determined by the following rules 🧠.

First, the distinguished PE for the C-flow is determined:

  • If the C-flow is not a BIDIR-PIM C-flow, the distinguished PE for the C-flow is its upstream PE, as determined by the rules of [RFC6513].
  • If the C-flow is a BIDIR-PIM C-flow, the distinguished PE for the C-flow is its upstream PE of the C-flow's C-RPA, as determined by the rules of [RFC6513].

The expected value of the second label is the value that the root PE of the outer tunnel has assigned, in the PE Distinguisher Labels attribute of its Intra-AS I-PMSI A-D route, to the IP address of the distinguished PE 🌟.

Packets addressed to C-G that arrive on other than the expected inner and outer P-tunnels (that is, packets that arrive with unexpected values of the top two labels) MUST be discarded 🚮.

3.2.3. Unpartitioned ✨

okay bestie, the Unpartitioned Method is where things get kinda chaotic (in a fun way 🦋). when an MVPN uses it to set up an I-PMSI with a bidirectional P-tunnel, at least one VRF in that MVPN MUST originate an Intra-AS I-PMSI A-D route that carries a PTA naming a bidirectional P-tunnel. when a VRF has to originate those routes is decided by [RFC6514], not by us 💅. this document lets all but one of those routes skip the PTA, but any of them MAY still include one. if a PTA is there, it MUST name a bidirectional P-tunnel. and per [RFC6513] and [RFC6514], any PE that imports such a route into one of its VRFs MUST join the P-tunnel in the PTA (if there is one) 🫶

packets that show up on any of these P-tunnels get treated as if they came in over the I-PMSI. the disposition of a packet MUST NOT depend on which particular P-tunnel it came over. literally the whole point 😭

when a PE needs to send a packet on this I-PMSI, if it advertised a P-tunnel in the PTA of an Intra-AS I-PMSI A-D route it originated, it SHOULD send on that one. BUT any PE sending on the I-PMSI MAY use any P-tunnel advertised in any currently installed Intra-AS I-PMSI A-D route for its VPN 🌈

so one bidirectional P-tunnel can instantiate the I-PMSI, but you can also have several. more P-tunnels can be a robustness win 🛡️, but the count doesn't change how things function at all. with two P-tunnels, each one can be advertised by a single PE, or by several PEs. also, the PE that advertises a P-tunnel doesn't have to be its root node. the root might not even be a PE, and it might not originate any BGP routes at all 🧚

heads up: in the Unpartitioned Method, packets on the I-PMSI can't be tied to a specific distinguished PE. so duplicate detection with the Section 9.1.1 technique of [RFC6513] is off the table. you'd have to use Section 9.1.2 or Section 9.1.3 of [RFC6513] instead 💀

C-BIDIR with the "Partitioned set of PEs" technique (Section 11.2 of [RFC6513] and Section 3.6 of [RFC6517]) is NOT possible with the Unpartitioned Method. if you want that technique for C-BIDIR but still want the Unpartitioned Method for the I-PMSI, all the C-BIDIR traffic has to go on an S-PMSI instantiated with one of the Partitioned Methods 🎀

when PE1 needs to send multicast data packets of a C-flow to other PEs and doesn't have a match-for-transmission S-PMSI for that C-flow (see Section 3.2.3.1), it sends them on one of the P-tunnel(s) instantiating the I-PMSI. when PE1 needs to receive multicast data packets of a C-flow from another PE and doesn't have a match-for-reception S-PMSI for it (see Section 3.2.3.2), it expects them on any of the P-tunnels instantiating the I-PMSI 🦋

for an S-PMSI that instantiates (C-,C-) or (C-,C--BIDIR) with a bidirectional P-tunnel under the Unpartitioned Method, the same rules as an I-PMSI apply. the only difference is that a PE doesn't have to join the P-tunnel instantiating that S-PMSI unless it actually needs to receive multicast packets on it 🍓

when bidirectional P-tunnels instantiate other S-PMSIs (ones that aren't (C-,C-) or (C-,C--BIDIR)), different S-PMSI A-D routes from the same or different PEs MAY have PTAs that name the same bidirectional tunnel, and they MAY have PTAs that don't 💜

the Unpartitioned Method MAY be used for an S-PMSI carrying one or more C-BIDIR flows, but the "Partitioned Set of PEs" method from Section 11.2 of [RFC6513] and Section 3.6 of [RFC6517] can't be supported with it. C-BIDIR support would have to come from the procedures in Section 11.1 of [RFC6513] 🌸

3.2.3.1. When an S-PMSI Is a 'Match for Transmission' 💖

okay so, suppose a PE needs to send multicast data packets of a certain customer C-flow. [RFC6625], Section 3.1 gives a four-step algorithm for finding the S-PMSI A-D route (if there is one) that matches that C-flow for transmission. quick reminder: BIDIR-PIM groups are also ASM groups 🙈

when bidirectional P-tunnels are used in the Unpartitioned Method, the same algorithm applies with one change. when an S-PMSI A-D route's PTA names a bidirectional P-tunnel, one extra step gets added. it goes before the fourth step, and it reads:

o Otherwise, if there is a (C-,C--BIDIR) S-PMSI A-D route currently originated by PE1, and if C-G is a BIDIR group, the C-flow matches that route.

when the Unpartitioned Method is in use, the PE SHOULD transmit the C-flow on the P-tunnel advertised in the matching S-PMSI A-D route. it MAY transmit the C-flow on any P-tunnel advertised in the PTA of any installed S-PMSI A-D route that contains the same (C-S,C-G) as the matching one ✨

3.2.3.2. When an S-PMSI Is a 'Match for Reception' 🎀

suppose a PE needs to receive multicast data packets of a certain customer C-flow. Section 3.2 of [RFC6625] lays out the procedures for finding the S-PMSI A-D route (if any) that advertised the P-tunnel the PE should expect that C-flow on 🫶

when bidirectional P-tunnels are used in the Unpartitioned Method, the same procedures apply, with one tweak 🌈

the last paragraph of Section 3.2.2 of [RFC6625] begins:

If (C-,C-G) does not match a (C-,C-G) S-PMSI A-D route from PE2, but PE1 has an installed (C-,C-) S-PMSI A-D route from PE2, then (C-,C-G) matches the (C-,C-*) route if one of the following conditions holds:

and that gets changed to:

If (C-,C-G) does not match a (C-,C-G) S-PMSI A-D route from PE2, but C-G is a BIDIR group and PE1 has an installed (C-,C--BIDIR) S-PMSI A-D route, then (C-,C-G) matches that route. Otherwise, if PE1 has an installed (C-,C-) S-PMSI A-D route from PE2, then (C-,C-G) matches the (C-,C-) route if one of the following conditions holds:

when the Unpartitioned Method is used, the PE MUST join the P-tunnel advertised in the matching S-PMSI A-D route. it MUST ALSO join the P-tunnels advertised in other installed S-PMSI A-D routes that contain the same (C-S,C-G) as the matching route 💅

Oops, I need to correct that last line: the BCP 14 key word is MUST, so it reads "it MUST also join" in capitals only where it appears in the original. Here is the corrected version:

when the Unpartitioned Method is used, the PE MUST join the P-tunnel advertised in the matching S-PMSI A-D route. it MUST also join the P-tunnels advertised in other installed S-PMSI A-D routes that contain the same (C-S,C-G) as the matching route 💅

3.2.4. Minimal Feature Set for Compliance 👑

implementing bidirectional P-tunnels is OPTIONAL 🍓 if you don't implement them, compliance to this spec doesn't even come up. but if you DO implement them, this section lists the minimum features that MUST be implemented to claim compliance 💅

to be compliant, an implementation that provides bidirectional P-tunnels MUST support at least one of the two P-tunnel technologies mentioned in Section 1.2.1 🫶

a PE that does NOT provide C-BIDIR support with the "partitioned set of PEs" method is compliant if it supports the Unpartitioned Method, using either MP2MP LSPs or BIDIR-PIM multicast distribution trees as P-tunnels ✨

a PE that DOES provide C-BIDIR support with the "partitioned set of PEs" method MUST, at a minimum, be able to do it with the "Partial Mesh of MP2MP P-tunnels" variant (see Section 11.2 of [RFC6513]). it's deemed compliant with that minimum if it can carry all of a VPN's C-BIDIR traffic on a (C-,C--BIDIR) S-PMSI instantiated by a bidirectional P-tunnel, using the Flat Partitioned Method 🌸

Note on the above: I've put the BCP 14 key words back as they appear in the original (MUST, OPTIONAL, MUST, NOT, DOES, and the rest), and kept the Section 3.2.3.2 wording exactly where the original has it.

5.2. Informative References ✨

Okay so these are the informative refs, bestie 📚 They're not required reading to implement, but they're the drafts and RFCs the authors pointed to for context. Here's the lineup 💅

[BGP-ERROR] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", Work in Progress, draft-ietf-idr-error-handling-19, April 2015.

[MVPN-BIDIR-IR] Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating 'Partial Mesh of MP2MP P-Tunnels' with Ingress Replication", Work in Progress, draft-ietf-bess-mvpn-bidir-ingress-replication-00, January 2015.

[MVPN-XNET] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", Work in Progress, draft-ietf-bess-mvpn-extranet-02, May 2015.

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

[RFC6517] Morin, T., Ed., Niven-Jenkins, B., Ed., Kamite, Y., Zhang, R., Leymann, N., and N. Bitar, "Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution", RFC 6517, DOI 10.17487/RFC6517, February 2012, <http://www.rfc-editor.org/info/rfc6517>.

Acknowledgments 🙏

The authors wanted to shoutout Karthik Subramanian, Rajesh Sharma, and Apoorva Karan for their input 🫶 They also thanked Yakov Rekhter for his valuable critique 💜

Special thanks go to Jeffrey (Zhaohui) Zhang for his careful review, probing questions, and useful suggestions 🌈👑

Authors' Addresses 💌

Meet the crew! 🎀 Here's where to find each author.

Eric C. Rosen
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA  01886
United States

Email: erosen@juniper.net
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a
Diegem  1831
Belgium

Email: ice@cisco.com
Yiqun Cai
Microsoft
1065 La Avenida
Mountain View, CA  94043
United States

Email: yiqunc@microsoft.com
Arjen Boers

Email: arjen@boers.com
📦 where this page comes from