RFC 6514

BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs

📅 published February 2012, from ietf

RFC 6514 💖 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs

okay bestie, this is RFC 6514 🎀 It's a Standards Track document from the IETF stream, published February 2012, ISSN 2070-1721. Four people wrote it: R. Aggarwal (Juniper Networks), E. Rosen (Cisco Systems, Inc.), T. Morin (France Telecom - Orange), and Y. Rekhter (Juniper Networks). The title block doesn't list anything it obsoletes or updates 🦋

Abstract ✨

this doc is all about the BGP encodings and procedures for swapping the info elements that Multicast in MPLS/BGP IP VPNs needs, as laid out in RFC 6513 💅

Status of This Memo 🌸

This is an Internet Standards Track document. 💜

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 🧚

For the current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6514 🔥

Copyright Notice 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these documents carefully, because they spell out your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. ⭐

Table of Contents 📜

1. Introduction ....................................................4
2. Specification of Requirements ...................................4
3. Terminology .....................................................4
4. MCAST-VPN NLRI ..................................................5
  4.1. Intra-AS I-PMSI A-D Route ...................................6
  4.2. Inter-AS I-PMSI A-D Route ...................................7
  4.3. S-PMSI A-D Route ............................................7
  4.4. Leaf A-D Route ..............................................8
  4.5. Source Active A-D Route .....................................9
  4.6. C-Multicast Route ..........................................10
5. PMSI Tunnel Attribute ..........................................10
6. Source AS Extended Community ...................................13
7. VRF Route Import Extended Community ............................14
8. PE Distinguisher Labels Attribute ..............................15
9. MVPN Auto-Discovery/Binding ....................................16
  9.1. MVPN Auto-Discovery/Binding - Intra-AS Operations ..........16
    9.1.1. Originating Intra-AS I-PMSI A-D Routes .................16
    9.1.2. Receiving Intra-AS I-PMSI A-D Routes ...................19
  9.2. MVPN Auto-Discovery/Binding - Inter-AS Operations ..........20
    9.2.1. Originating Inter-AS I-PMSI A-D Routes .................22
    9.2.2. When Not to Originate Inter-AS I-PMSI A-D Routes .......23
    9.2.3. Propagating Inter-AS I-PMSI A-D Routes .................23
      9.2.3.1. Propagating Inter-AS I-PMSI A-D Routes - Overview ..23
      9.2.3.2. Inter-AS I-PMSI A-D Route Received via EBGP ........24
        9.2.3.2.1. Originating Leaf A-D Route into EBGP ...........25
      9.2.3.3. Leaf A-D Route Received via EBGP ...................26
      9.2.3.4. Inter-AS I-PMSI A-D Route Received via IBGP ........27
        9.2.3.4.1. Originating Leaf A-D Route into IBGP ...........28
      9.2.3.5. Leaf A-D Route Received via IBGP ...................29
      9.2.3.6. Optimizing Bandwidth by IP Filtering on ASBRs ......30
10. Non-Congruent Unicast and Multicast Connectivity ..............30
11. Exchange of C-Multicast Routing Information among PEs .........32
  11.1. Originating C-Multicast Routes by a PE ....................32
    11.1.1. Originating Routes: PIM as the C-Multicast Protocol ...32
      11.1.1.1. Originating Source Tree Join C-Multicast Route ....33
      11.1.1.2. Originating Shared Tree Join C-Multicast Route ....33
    11.1.2. Originating Routes: mLDP as the C-Multicast Protocol ..34
    11.1.3. Constructing the Rest of the C-Multicast Route ........34
    11.1.4. Unicast Route Changes .................................35
  11.2. Propagating C-Multicast Routes by an ASBR .................36
  11.3. Receiving C-Multicast Routes by a PE ......................37
    11.3.1. Receiving Routes: PIM as the C-Multicast Protocol .....37
      11.3.1.1. Receiving Source Tree Join C-Multicast Route ......38
      11.3.1.2. Receiving Shared Tree Join C-Multicast Route ......38
    11.3.2. Receiving Routes: mLDP as the C-Multicast Protocol ....39
  11.4. C-Multicast Routes Aggregation ............................39

12. Using S-PMSI A-D Routes to Bind C-Trees to P-Tunnels ..........40
  12.1. Originating S-PMSI A-D Routes .............................40
  12.2. Handling S-PMSI A-D Routes by ASBRs .......................43
    12.2.1. Merging S-PMSI into an I-PMSI .........................43
  12.3. Receiving S-PMSI A-D Routes by PEs ........................44
13. Switching from Shared a C-Tree to a Source C-Tree .............45
  13.1. Source within a Site - Source Active Advertisement ........46
  13.2. Receiving Source Active A-D Route .........................47
    13.2.1. Pruning Sources off the Shared Tree ...................48
14. Supporting PIM-SM without Inter-Site Shared C-Trees ...........49
  14.1. Discovering Active Multicast Sources ......................50
  14.2. Receiver(s) within a Site .................................51
  14.3. Receiving C-Multicast Routes by a PE ......................52
15. Carrier's Carrier .............................................52
16. Scalability Considerations ....................................52
  16.1. Dampening C-Multicast Routes ..............................54
    16.1.1. Dampening Withdrawals of C-Multicast Routes ...........54
    16.1.2. Dampening Source/Shared Tree Join C-Multicast Routes ..55
  16.2. Dampening Withdrawals of Leaf A-D Routes ..................55
17. Security Considerations .......................................55
18. IANA Considerations ...........................................56
19. Acknowledgements ..............................................57
20. References ....................................................57
  20.1. Normative References ......................................57
  20.2. Informative References ....................................58

1. Introduction ✨

okay so this doc covers the BGP encodings and procedures for trading the info elements that Multicast in MPLS/BGP IP VPNs needs, as specified in [MVPN] 💅 It assumes you already have a thorough familiarity with the procedures, concepts, and terms in [MVPN], so read that one first, bestie 🧚

this doc defines a brand new Network Layer Reachability Information (NLRI) called the MCAST-VPN NLRI 🦋 It's the one that does all the heavy lifting for:

MVPN auto-discovery
advertising an MVPN to Inclusive P-Multicast Service Interface (I-PMSI) tunnel binding
advertising (C-S,C-G) to Selective PMSI (S-PMSI) tunnel binding
VPN customer multicast routing information exchange among Provider Edge routers (PEs)
choosing a single forwarder PE
procedures in support of co-locating a Customer Rendezvous Point (C-RP) on a PE

it also specifies two new BGP attributes: the P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute and the PE Distinguisher Label attribute 💖

and it defines two new BGP Extended Communities: the Source Autonomous System (AS) Extended Community and the VPN Routing and Forwarding (VRF) Route Import Extended Community 🌸

2. Specification of Requirements 🎀

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in [RFC2119] 💅

3. Terminology 📚

in this doc we call the MVPN auto-discovery/binding info carried in BGP "auto-discovery routes" ("A-D routes"). for a given MVPN, there are these types of A-D routes:

Intra-AS I-PMSI A-D route
Inter-AS I-PMSI A-D route
S-PMSI A-D route
Leaf A-D route
Source Active A-D route

we also call the MVPN customers' multicast routing info carried in BGP "C-multicast routes" 🦋 For a given MVPN, there are these types of C-multicast routes:

Shared Tree Join route;
Source Tree Join route;

for each MVPN present on a PE, the PE keeps a Tree Information Base (MVPN-TIB) 🧚 This is the same as TIB defined in [RFC4601], except that instead of one single TIB, a PE keeps multiple MVPN-TIBs: one per each MVPN ✨

and throughout this doc, "VPN-IP route" means a route that is either in the VPN-IPv4 address family [RFC4364] or in the VPN-IPv6 address family [RFC4659] 💜

4. MCAST-VPN NLRI 💅

okay so this whole document is about a brand-new BGP NLRI called the MCAST-VPN NLRI 🦋 it's literally the main character of the spec ✨ here's what its format looks like:

   +-----------------------------------+
   |    Route Type (1 octet)           |
   +-----------------------------------+
   |     Length (1 octet)              |
   +-----------------------------------+
   | Route Type specific (variable)    |
   +-----------------------------------+

so the Route Type field tells you how to read the rest of the MCAST-VPN NLRI (the Route Type specific part) 🧚 and the Length field tells you how many octets the Route Type specific field is 💜

the document defines these Route Types for A-D routes 🌸

1 - Intra-AS I-PMSI A-D route;
2 - Inter-AS I-PMSI A-D route;
3 - S-PMSI A-D route;
4 - Leaf A-D route;
5 - Source Active A-D route.

and these Route Types for C-multicast routes 🍓

6 - Shared Tree Join route;
7 - Source Tree Join route;

the MCAST-VPN NLRI rides along in BGP [RFC4271] using BGP Multiprotocol Extensions [RFC4760], with an Address Family Identifier (AFI) of 1 or 2 and a Subsequent AFI (SAFI) of MCAST-VPN. the NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute holds the MCAST-VPN NLRI (encoded as described above) 🫶 and the AFI value in that attribute decides whether the multicast source and multicast group addresses in S-PMSI A-D routes, Source Active A-D routes, and C-multicast routes are IPv4 or IPv6 addresses. AFI 1 means IPv4 and AFI 2 means IPv6 🌈

if two BGP speakers want to swap labeled MCAST-VPN NLRIs, they must use a BGP Capabilities Advertisement so they both know they can actually process one 🔥 that's done as specified in [RFC4760], using capability code 1 (multiprotocol BGP) with an AFI of 1 or 2 and a SAFI of MCAST-VPN.

here's how each Route Type specific MCAST-VPN NLRI is laid out for the Route Types in this document 🎀

4.1. Intra-AS I-PMSI A-D Route

an Intra-AS I-PMSI A-D Route Type specific MCAST-VPN NLRI is made of:

   +-----------------------------------+
   |      RD   (8 octets)              |
   +-----------------------------------+
   |   Originating Router's IP Addr    |
   +-----------------------------------+

the Route Distinguisher (RD) is encoded as described in [RFC4364] 💖 for how this route gets used, see Section 9.2.

4.2. Inter-AS I-PMSI A-D Route

an Inter-AS I-PMSI A-D Route Type specific MCAST-VPN NLRI is made of:

   +-----------------------------------+
   |      RD   (8 octets)              |
   +-----------------------------------+
   |      Source AS (4 octets)         |
   +-----------------------------------+

the RD is encoded as described in [RFC4364] 🦋

the Source AS holds an Autonomous System Number (ASN) ✨ two-octet ASNs go in the two low-order octets of the Source AS field, and the two high-order octets are set to zero 🙈 for how this route gets used, see Section 9.1.

4.3. S-PMSI A-D Route

an S-PMSI A-D Route Type specific MCAST-VPN NLRI is made of:

   +-----------------------------------+
   |      RD   (8 octets)              |
   +-----------------------------------+
   | Multicast Source Length (1 octet) |
   +-----------------------------------+
   |  Multicast Source (variable)      |
   +-----------------------------------+
   |  Multicast Group Length (1 octet) |
   +-----------------------------------+
   |  Multicast Group   (variable)     |
   +-----------------------------------+
   |   Originating Router's IP Addr    |
   +-----------------------------------+

the RD is encoded as described in [RFC4364] 💅

the Multicast Source field holds the C-S address. if it's an IPv4 address, the Multicast Source Length field is 32. if it's an IPv6 address, the Multicast Source Length field is 128 💜

the Multicast Group field holds the C-G address or the C-LDP (Label Distribution Protocol) MP Opaque Value Element (use of the C-LDP MP Opaque Value Element is described in the Section 11.3.2. 🧚 if it's an IPv4 address, the Multicast Group Length field is 32. if it's an IPv6 address, the Multicast Group Length field is 128 🍓

using any other values in the Multicast Source Length and Multicast Group Length fields is outside the scope of this document 🙅‍♀️ for how this route gets used, see Section 12.

4.4. Leaf A-D Route

a Leaf A-D Route Type specific MCAST-VPN NLRI is made of:

   +-----------------------------------+
   |      Route Key (variable)         |
   +-----------------------------------+
   |   Originating Router's IP Addr    |
   +-----------------------------------+

so a Leaf A-D route can get originated after processing a received Inter-AS I-PMSI A-D route or S-PMSI A-D route 🌸 but only in those situations, and only if the received route has a PMSI Tunnel attribute whose "Leaf Information Required" bit is set to 1 🔥

when a Leaf A-D route is originated from one of those received routes, its Route Key is set to the NLRI of the received route 🫶

for more on how the Leaf A-D route gets used, check out Sections 9.2.3.2.1, 9.2.3.3, 9.2.3.4.1, 9.2.3.5, and 12.3 ✨

4.5. Source Active A-D Route

a Source Active A-D Route Type specific MCAST-VPN NLRI is made of:

   +-----------------------------------+
   |      RD   (8 octets)              |
   +-----------------------------------+
   | Multicast Source Length (1 octet) |
   +-----------------------------------+
   |   Multicast Source (variable)     |
   +-----------------------------------+
   |  Multicast Group Length (1 octet) |
   +-----------------------------------+
   |  Multicast Group (variable)       |
   +-----------------------------------+

the RD is encoded as described in [RFC4364] 🦋

the Multicast Source field holds the C-S address. if it's an IPv4 address, the Multicast Source Length field is 32. if it's an IPv6 address, the Multicast Source Length field is 128 💖

using a Multicast Source Length field of 0 with Source Active A-D routes is outside the scope of this document 🙈

the Multicast Group field holds the C-G address. if it's an IPv4 address, the Multicast Group Length field is 32. if it's an IPv6 address, the Multicast Group Length field is 128 🍓

🚨 okay this part is serious bestie: Source Active A-D routes with a Multicast group in the Source Specific Multicast (SSM) range (as defined in [RFC4607], and potentially extended locally on a router) MUST NOT be advertised by a router, and MUST be discarded if received. no exceptions, no vibes-based workarounds 💀

for how this route gets used, see Sections 13 and 14 👑

4.6. C-Multicast Route

a Shared Tree Join route and a Source Tree Join Route Type specific MCAST-VPN NLRI is made of:

   +-----------------------------------+
   |      RD   (8 octets)              |
   +-----------------------------------+
   |    Source AS (4 octets)           |
   +-----------------------------------+
   | Multicast Source Length (1 octet) |
   +-----------------------------------+
   |   Multicast Source (variable)     |
   +-----------------------------------+
   |  Multicast Group Length (1 octet) |
   +-----------------------------------+
   |  Multicast Group   (variable)     |
   +-----------------------------------+

the RD is encoded as described in [RFC4364] 💜

the Source AS holds an ASN, and two-octet ASNs go in the low-order two octets of the Source AS field 🧚

for a Shared Tree Join route, the Multicast Source field holds the C-RP address. for a Source Tree Join route, it holds the C-S address instead 🌈 if it's an IPv4 address, the Multicast Source Length field is 32. if it's an IPv6 address, the Multicast Source Length field is 128 ✨

the Multicast Group field holds the C-G address or the C-MP Opaque Value Element 💅 if it's an IPv4 address, the Multicast Group Length field is 32. if it's an IPv6 address, the Multicast Group Length field is 128 🫶

for how C-multicast routes get used, see Section 11 🎀

5. PMSI Tunnel Attribute ✨

okay bestie, this part defines a brand new BGP attribute called the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" 🎀 It's an optional transitive BGP attribute, and the layout goes like this:

   +---------------------------------+
   |  Flags (1 octet)                |
   +---------------------------------+
   |  Tunnel Type (1 octets)         |
   +---------------------------------+
   |  MPLS Label (3 octets)          |
   +---------------------------------+
   |  Tunnel Identifier (variable)   |
   +---------------------------------+

The Flags field is laid out like this 🦋

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |  reserved   |L|
   +-+-+-+-+-+-+-+-+

and this document only defines one flag so far:

Leaf Information Required (L) 💜

The Tunnel Type tells you which tunneling tech is being used to set up the PMSI tunnel. That type decides what the Tunnel Identifier field looks like and how it works. This document defines these Tunnel Types:

0 - No tunnel information present
1 - RSVP-TE P2MP LSP
2 - mLDP P2MP LSP
3 - PIM-SSM Tree
4 - PIM-SM Tree
5 - BIDIR-PIM Tree
6 - Ingress Replication
7 - mLDP MP2MP LSP

If the MPLS Label field is non-zero, it holds an MPLS label in 3 octets, and the high-order 20 bits are the label value. No MPLS Label? Just set the MPLS Label field to zero 🌸

When the Tunnel Type is set to "No tunnel information present", the PMSI Tunnel attribute carries no tunnel information at all, so there is no Tunnel Identifier. This type is only meant for one case: you want explicit tracking for a specific customer multicast flow (by setting the Leaf Information Required flag to 1), but you don't want to tie that flow to any particular provider tunnel (so you leave out the tunnel info). It's giving very specific energy 🙈

When the Tunnel Type is set to RSVP - Traffic Engineering (RSVP-TE) Point-to-Multipoint (P2MP) Label Switched Path (LSP), the Tunnel Identifier is <Extended Tunnel ID, Reserved, Tunnel ID, P2MP ID>, as carried in the RSVP-TE P2MP LSP SESSION Object [RFC4875] ✨

When the Tunnel Type is set to multipoint Label Distribution Protocol (mLDP) P2MP LSP, the Tunnel Identifier is a P2MP Forwarding Equivalence Class (FEC) Element [mLDP] 🧚

When the Tunnel Type is set to Protocol Independent Multicast - Sparse Mode (PIM-SM) tree, the Tunnel Identifier is <Sender Address, P-Multicast Group>. The node that originated the attribute MUST use the address carried in the Sender Address as the source IP address for the IP/GRE (Generic Routing Encapsulation) encapsulation of the MVPN data. No skipping this one, periodt 💅

When the Tunnel Type is set to PIM-SSM tree, the Tunnel Identifier is <P-Root Node Address, P-Multicast Group>. The node that originates the attribute MUST use the address carried in the P-Root Node Address as the source IP address for the IP/GRE encapsulation of the MVPN data. Also, the P-Multicast Group in the Tunnel Identifier of the Tunnel attribute MUST NOT be expected to be the same group for all Intra-AS A-D routes for the same MVPN. Per [RFC4607], the originating PE can locally allocate that group address without caring what group address other PEs on the same MVPN are using. Wild, right? 🦋

When the Tunnel Type is set to BIDIR-PIM tree, the Tunnel Identifier is <Sender Address, P-Multicast Group>. The node that originated the attribute MUST use the address carried in the Sender Address as the source IP address for the IP/GRE encapsulation of the MVPN data 🌈

When the Tunnel Type is set to PIM-SM or BIDIR-PIM tree, the P-Multicast Group in the Tunnel Identifier of the Tunnel attribute SHOULD contain the same multicast group address for all Intra-AS I-PMSI A-D routes for the same MVPN that are originated by PEs within a given AS. How that group address gets picked is outside the scope of this spec, so we're not going there today 🫶

When the Tunnel Type is set to Ingress Replication, the Tunnel Identifier carries the unicast tunnel endpoint IP address of the local PE. That address is this PE's receiving endpoint for the tunnel 💖

When the Tunnel Type is set to mLDP Multipoint-to-Multipoint (MP2MP) LSP, the Tunnel Identifier is an MP2MP FEC Element [mLDP] 🍓

Using mLDP MP2MP LSPs as Provider tunnels (P-tunnels) needs procedures that are outside the scope of this document. Not our problem, bestie 👑

A router that supports the PMSI Tunnel attribute treats the attribute as malformed if either (a) the Tunnel Type field has an undefined tunnel type in it, or (b) the router can't parse the Tunnel Identifier field as a tunnel identifier for the tunnel types listed in the Tunnel Type field. Yikes 💀

When a router gets a BGP Update carrying a PMSI Tunnel attribute with its Partial bit set, and it decides the attribute is malformed, the router SHOULD treat that Update as though every route in it had been withdrawn. Harsh, but that's the vibe 😭

An implementation MUST provide debugging facilities so issues caused by a malformed PMSI Tunnel attribute can be diagnosed. At a minimum, those facilities MUST include logging an error whenever such an attribute is detected. Debugging is not optional, babe 🔥

The PMSI Tunnel attribute is used together with Intra-AS I-PMSI A-D routes, Inter-AS I-PMSI A-D routes, S-PMSI A-D routes, and Leaf A-D routes ✨

6. Source AS Extended Community 🌸

This document defines a new BGP Extended Community called "Source AS" 💅

The Source AS is an AS-specific Extended Community of an extended type, and it's transitive across AS boundaries [RFC4360] 🦋

The Global Administrator field of this Community MUST be set to the ASN of the PE. The Local Administrator field of this Community MUST be set to 0. Those two rules are non-negotiable 🫶

Picture a given MVPN that uses BGP to exchange C-multicast routes, and/or uses segmented inter-AS tunnels. A PE with sites of that MVPN attached to it, and it originates a (unicast) route to VPN-IP addresses for destinations inside those sites, MUST include the Source AS Extended Community in the BGP Update message that carries that route 🧚

The way a received Source AS Extended Community gets used is described in Section 11.1.3 ✨

7. VRF Route Import Extended Community 🎀

This document defines a new BGP Extended Community called "VRF Route Import" 🌈

The VRF Route Import is an IP-address-specific Extended Community of an extended type, and it's transitive across AS boundaries [RFC4360] 💜

Here's the deal: to support MVPN alongside the import/export Route Target(s) Extended Communities that unicast routing already uses, each VRF on a PE MUST have an import Route Target Extended Community. The exception is when it's known a priori that none of the (local) MVPN sites tied to the VRF contain multicast source(s) and/or C-RP. In that case the VRF doesn't need this import Route Target. Easy 🍓

We'll call this Route Target the "C-multicast Import RT", because it controls which C-multicast routes get imported into a particular VRF 🔥

A PE builds the C-multicast Import RT like this:

The Global Administrator field of the C-multicast Import RT MUST be set to an IP address of the PE. This address SHOULD be common for all the VRFs on the PE. For example, it could be the PE's loopback address 🦋
The Local Administrator field of the C-multicast Import RT associated with a given VRF holds a 2-octet number that uniquely identifies that VRF within the PE that contains it. How those numbers get assigned is purely local to the PE and outside the scope of this document 🌸

Built this way, the C-multicast Import RT uniquely identifies a VRF. Chef's kiss 👑

A PE that has sites of a given MVPN attached to it needs to tell every other PE with sites of that MVPN what the C-multicast Import RT is for its VRF of that MVPN. So a PE that originates a (unicast) route to VPN-IP addresses MUST include the VRF Route Import Extended Community in the BGP Updates message carrying that route, set to the value of the C-multicast Import RT of the VRF associated with the route. The exception is when it's known a priori (e.g., via provisioning) that none of these addresses could act as multicast sources and/or RP. In that case the (unicast) route MUST NOT carry the VRF Route Import Extended Community 💖

If a PE uses Route Target Constraint [RT-CONSTRAIN], the PE SHOULD advertise all of its C-multicast Import RTs using Route Target Constraints. (Doing this takes just a single Route Target Constraint advertisement from the PE, so it's a total win 🧚) This way each C-multicast route only reaches the relevant PE. To keep the Route Target Constraint routes from spreading beyond the AS of the advertising PE, these routes SHOULD carry the NO_EXPORT Community [RFC1997] 🫶

Usage of the VRF Route Import Extended Community is described in Section 11.1.3 ✨

8. PE Distinguisher Labels Attribute 💜

This document defines a new BGP attribute called the "PE Distinguisher Labels" attribute. It's an optional transitive BGP attribute, and the format goes like this:

   +---------------------------------+
   |           PE Address            |
   +---------------------------------+
   |     Label (3 octets)            |
   +---------------------------------+
   .......
   +---------------------------------+
   |           PE Address            |
   +---------------------------------+
   |     Label (3 octets)            |
   +---------------------------------+

The Label field holds an MPLS label in 3 octets, where the high-order 20 bits are the label value 🌈

A router that supports the PE Distinguisher Labels attribute considers the attribute malformed if the PE Address field doesn't contain a unicast address. The attribute is also malformed if: (a) the PE Address field is expected to be an IPv4 address and the length of the attribute is not a multiple of 7, or (b) the PE Address field is expected to be an IPv6 address and the length of the attribute is not a multiple of 19. The length of the Route Type field in the MCAST-VPN NLRI of the route carrying the PE Distinguisher Labels attribute tells you whether the PE Address field holds an IPv4 or IPv6 address. Every PE address in the PE Distinguisher Labels attribute MUST be of the same address family as the "Originating Router's IP Address" of the route carrying the attribute 🦋

When a router gets a BGP Update carrying the PE Distinguisher Labels attribute with its Partial bit set, and it decides the attribute is malformed, the router SHOULD treat that Update as though every route in it had been withdrawn 😭

An implementation MUST provide debugging facilities so issues caused by a malformed PE Distinguisher Label attribute can be diagnosed. At a minimum, those facilities MUST include logging an error whenever such an attribute is detected 🔥

Usage of this attribute is described in [MVPN] 🎀

9. MVPN Auto-Discovery/Binding ✨

okay bestie, this section is all about how PEs find out who's in an MVPN and share the info they need to set up I-PMSIs 💖 there are two mechanisms, called "intra-AS" and "inter-AS" 🦋

the intra-AS mechanisms handle auto-discovery/binding inside a single AS 🌸

the intra-AS mechanisms also cover multiple ASes when non-segmented inter-AS tunnels are in use ✨

the inter-AS mechanisms cover multiple ASes when segmented inter-AS tunnels are in use 🎀

and note: if a multi-AS system uses option (a) of section 10 of [RFC4364], inter-AS tunnels don't even apply, so it only needs the intra-AS mechanisms 💅

9.1. MVPN Auto-Discovery/Binding - Intra-AS Operations 🧚

this part covers the exchanges of Intra-AS I-PMSI A-D routes that PEs originate and receive within the same AS. if non-segmented inter-AS tunnels are used, then it's all PEs, no exceptions 🫶

9.1.1. Originating Intra-AS I-PMSI A-D Routes 📣

to join the MVPN auto-discovery/binding party, a PE that has a given VRF of a given MVPN MUST originate an Intra-AS I-PMSI A-D route and advertise it in IBGP 💅 the only exceptions are the ones called out in this section. here's how the route gets built 🎀

the route carries one MCAST-VPN NLRI, with the RD set to the RD of the VRF. the Originating Router's IP Address field gets set to the IP address the PE puts in the Global Administrator field of the VRF Route Import Extended Community on its VPN-IP routes 🦋 and the <RD, Originating Router's IP Address> tuple is what uniquely identifies a given multicast VRF, so that combo is literally the main character 👑

the route carries the PMSI Tunnel attribute if and only if an I-PMSI is used for the MVPN (you can find the conditions for that in [MVPN]) 🌈 depending on which technology the PE uses for the P-tunnel, the PMSI Tunnel attribute of the Intra-AS I-PMSI A-D route gets built like this:

if the PE originating the advertisement uses a P-multicast tree for the P-tunnel, the PMSI Tunnel attribute MUST contain the identity of the tree. (the PE can make up the tree's identity before the tree is actually instantiated, which is so smart ✨)
a PE that uses a P-multicast tree for the P-tunnel MAY aggregate two or more MVPNs on the PE onto the same tree 🍓 in that case, on top of the tree identity, the PMSI Tunnel attribute of the Intra-AS I-PMSI A-D route MUST carry an MPLS upstream-assigned label that the PE has bound uniquely to the MVPN tied to this route (as determined by its RTs) 💜 If the PE has already advertised Intra-AS I-PMSI A-D routes for two or more MVPNs that it now wants to aggregate, then the PE MUST re-advertise those routes. the re-advertised routes MUST be the same as the originals, except for the PMSI Tunnel attribute and the label in that attribute 🫠
if the PE originating the advertisement uses ingress replication for the P-tunnel, the route MUST include the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication and the Tunnel Identifier set to a routable address of the PE 🩷 the PMSI Tunnel attribute MUST carry a downstream-assigned MPLS label, and that label is what demultiplexes the MVPN traffic the PE receives over a unicast tunnel 🔥
the Leaf Information Required flag of the PMSI Tunnel attribute MUST be set to zero and MUST be ignored on receipt 💀

discovering which tunnel types a PE supports is totally outside the scope of this doc 🙈 within a given AS, PEs in an MVPN are expected to advertise tunnel bindings whose tunnel types are supported by all the other PEs in that MVPN that live in the same AS. and in the inter-AS scenario with non-segmented inter-AS tunnels, the tunnel types have to be supported by all PEs in the MVPN, no matter which AS they're in 🌸

the Next Hop field of the MP_REACH_NLRI attribute of the route MUST be set to the same IP address as the one carried in the Originating Router's IP Address field 🎀

by default, the distribution of Intra-AS I-PMSI A-D routes is controlled by the same Route Targets used to distribute VPN-IP unicast routes 🦋 so, by default, the Intra-AS I-PMSI A-D route MUST carry the export Route Target used by unicast routing. if any other PE has one of those Route Targets configured as an import Route Target for a VRF on that PE, it treats the advertising PE as a member of the MVPN that VRF belongs to 🫶 the default can be changed through configuration, by using a set of Route Targets for Intra-AS I-PMSI A-D routes that's different from the ones used for VPN-IP unicast routes (see also Section 10) ✨

to keep the intra-AS membership/binding info within the AS of the advertising PE, the BGP Update message the advertising PE originates SHOULD carry the NO_EXPORT Community [RFC1997] 🔒

heads up: if non-segmented inter-AS P-tunnels are being used, the Intra-AS I-PMSI routes need to go out to other ASes too, so they MUST NOT carry the NO_EXPORT Community 🚫

when BGP is used to exchange C-multicast routes, and (a) it's known a priori that, as a matter of policy, none of the MVPN sites connected to a given PE are allowed to send multicast traffic to other sites of that MVPN (all of those sites are only in the Receiver Sites set), and (b) the PE doesn't use ingress replication for the incoming traffic of that MVPN, and (c) none of the other PEs with VRFs of that MVPN use RSVP-TE P2MP LSP for that MVPN, then the local PE SHOULD NOT originate an Intra-AS I-PMSI A-D route 🙅‍♀️

when BGP is used to exchange C-multicast routes, and it's known a priori that, as a matter of policy, none of the MVPN sites connected to a given PE can receive multicast traffic from other sites of that MVPN (all of those sites are only in the Sender Sites set), and the PE uses ingress replication for that MVPN, then the PE SHOULD NOT originate an Intra-AS I-PMSI A-D route for that MVPN 🥹

9.1.2. Receiving Intra-AS I-PMSI A-D Routes 👂

when a PE gets a BGP Update message carrying an Intra-AS I-PMSI A-D route, the PE does the following, as long as all three of these are true 💖 (a) at least one of the route's Route Targets matches one of the import Route Targets configured for a particular VRF on the local PE, (b) either the route was originated by another PE in the same AS as the local PE, or the MVPN tied to the VRF uses non-segmented inter-AS tunnels, and (c) BGP route selection says this is the best route for the NLRI it carries 🏆

if the route does NOT carry the PMSI Tunnel attribute and ingress replication isn't used, then either (a) the PE that originated the route is only using S-PMSIs to send traffic to remote PEs, or (b) as a matter of policy, that originating PE can't send multicast traffic from its MVPN sites to other sites of that MVPN (the sites connected to it are only in the Receiver Sites set) 🫣

when BGP is used to exchange C-multicast routes, the VRF Route Import Extended Community in the unicast VPN routes is how you tell (a) and (b) apart 🕵️‍♀️ as Section 7 explains, if it's known a priori that none of the addresses in the NLRI of a given (unicast) VPN route could act as multicast sources and/or C-RP, then that route doesn't carry the VRF Route Import Extended Community. so, based on the Upstream Multicast Hop (UMH) selection algorithm in [MVPN], that route is ineligible for UMH selection. this means that if a VPN route gets picked by the UMH selection procedures, and the PE that originates it also originates an Intra-AS I-PMSI A-D route, but that route doesn't carry the PMSI Tunnel attribute, then that PE is only using S-PMSIs for sending multicast data 🧠

if the route DOES carry the PMSI Tunnel attribute, then:

if the Tunnel Type in the PMSI Tunnel attribute is set to Ingress Replication, then the MPLS label and the address in the Tunnel Identifier field of the PMSI Tunnel attribute should be used when the local PE sends multicast traffic to the PE that originated the route 🌷
if the Tunnel Type in the PMSI Tunnel attribute is set to mLDP P2MP LSP, mLDP MP2MP LSP, PIM-SSM tree, PIM-SM tree, or BIDIR-PIM tree, the PE SHOULD join, as soon as possible, the P-multicast tree whose identity is carried in the Tunnel Identifier 🏃‍♀️💨
if the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE P2MP LSP, then the PE that originated the route MUST establish an RSVP-TE P2MP LSP with the local PE as a leaf. that LSP might already exist before the local PE gets the route, or it might get set up after 🧚
the receiving PE has to set up the right state so it can handle the traffic it receives on the P-multicast tree 🛠️
if the PMSI Tunnel attribute doesn't carry a label, then all packets received on the P-multicast tree (as identified by the PMSI Tunnel attribute) get forwarded using the VRF that has at least one import Route Target matching one of the Route Targets of the received Intra-AS I-PMSI A-D route 🎀
if the PMSI Tunnel attribute has the Tunnel Type set to mLDP P2MP LSP, PIM-SSM tree, PIM-SM tree, BIDIR-PIM tree, or RSVP-TE P2MP LSP, and the attribute also carries an MPLS label, then that's an upstream-assigned label. all packets received on the P-multicast tree (as identified by the PMSI Tunnel attribute) with that upstream-assigned label get forwarded using the VRF that has at least one import Route Target matching one of the Route Targets of the received Intra-AS I-PMSI A-D route 🦄

no matter whether the route carries the PMSI Tunnel attribute, if the local PE uses RSVP-TE P2MP LSP to send (multicast) traffic from the VRF to sites attached to other PEs, then the local PE uses the Originating Router's IP address info carried in the route to add the PE that originated the route as a leaf node on the LSP 🌈

9.2. MVPN Auto-Discovery/Binding - Inter-AS Operations ✨

Okay bestie, this section only matters when segmented inter-AS tunnels are in play 🧩

An Autonomous System Border Router (ASBR) may be configured to support a particular MVPN like this 💅

An ASBR MUST be configured with a set of (import) Route Targets (RTs) that tells it which MVPNs it supports 🎀 These Route Targets decide which Intra-AS/Inter-AS I-PMSI A-D routes the ASBR accepts. If unicast and multicast connectivity line up, this can be the same set of Route Targets used for unicast, so you don't need any extra config beyond what unicast already needs 🫶 Also, instead of configuring them by hand, the ASBR MAY get this set of (import) Route Targets (RTs) using Route Target Constraint [RT-CONSTRAIN] 🦋
The ASBR MUST be (auto-)configured with an import Route Target called "ASBR Import RT" 👑 ASBR Import RT decides which Leaf A-D routes and C-multicast routes the ASBR accepts, and it's also used to limit where those Leaf A-D routes and C-multicast routes get sent (see Section 11) 🌸

ASBR Import RT is an IP-address-specific Route Target 🌐 The Global Administrator field of the ASBR Import RT MUST be set to the IP address carried in the Next Hop of all the Inter-AS I-PMSI A-D routes and S-PMSI A-D routes this ASBR advertises. If the ASBR uses different Next Hop values, then the ASBR MUST be (auto-)configured with multiple ASBR Import RTs, one for each of those Next Hop values 💖 The Local Administrator field of the ASBR Import RT MUST be set to 0 ✨

If the ASBR supports Route Target Constraint [RT-CONSTRAIN], the ASBR SHOULD advertise its ASBR Import RT inside its own AS using Route Target Constraints 🧚 To keep those Route Target Constraint routes from leaving the AS of the advertising ASBR, these routes SHOULD carry the NO_EXPORT Community [RFC1997] 🙈

The ASBR MUST be configured with the tunnel types for the intra-AS segments of the MVPNs it supports, plus (depending on the tunnel type) whatever info is needed to build the PMSI attribute for those tunnel types 🍓 Also, instead of configuring that, the ASBR MAY work out the tunnel types from the Intra-AS I-PMSI A-D routes it receives 💜
If the ASBR originates an Inter-AS I-PMSI A-D route for a particular MVPN that has PEs in its own AS, the ASBR MUST be (auto-)configured with an RD for that MVPN 🌈 It is RECOMMENDED to use one of the following two options 🎀

To get more aggregation of Inter-AS I-PMSI A-D routes, it is recommended that all the ASBRs in an AS that are set up to originate an Inter-AS I-PMSI A-D route for a particular MVPN use the same RD. (Each AS can still pick this RD on its own for a given MVPN, with no coordination with other ASes 🌸)
To get more control over spreading MVPN traffic across multiple ASBRs in a given AS, it is recommended that each ASBR have a distinct RD per MVPN. In that case, such an RD SHOULD be auto-configured 💅

If an ASBR is set up to support a particular MVPN, the ASBR MUST take part in the intra-AS MVPN auto-discovery/binding procedures for that MVPN inside its own AS, as laid out in Section 9.1 🫶

Plus, on top of all of that, the ASBR does the procedures described in Sections 9.2.1, 9.2.2, and 9.2.3 🔥

9.2.1. Originating Inter-AS I-PMSI A-D Routes

For a given MVPN configured on an ASBR, once the ASBR figures out (using the intra-AS auto-discovery procedures) that at least one of the PEs in its own AS has (directly) connected site(s) of that MVPN, the ASBR originates an Inter-AS I-PMSI A-D route and advertises it over External BGP (EBGP) 👑 The route is built like this 🦋

The route carries a single MCAST-VPN NLRI with the RD set to the RD configured for that MVPN on the ASBR, and the Source AS set to the ASN of the ASBR 🎀
The route carries the PMSI Tunnel attribute if and only if an I-PMSI is used for the MVPN 💖 The Tunnel Type in the attribute is set to Ingress Replication, the Leaf Information Required flag is set to 1, and the attribute carries no MPLS labels ✨
The Next Hop field of the MP_REACH_NLRI attribute is set to a routable IP address of the ASBR 🌐
The default policy for aggregating Intra-AS I-PMSI A-D routes into an Inter-AS I-PMSI A-D route is that a given Inter-AS I-PMSI A-D route only aggregates the Intra-AS I-PMSI A-D routes that carry exactly the same set of RTs (this set can be just one RT, so don't panic 🙈). In this case, an Inter-AS I-PMSI A-D route originated by an ASBR carries exactly the same RT(s) as the RT(s) carried by the Intra-AS I-PMSI A-D routes that the ASBR aggregates into it 🧚 An implementation MUST support the default policy for aggregating Intra-AS I-PMSI A-D routes into an Inter-AS I-PMSI A-D route 💅
The default aggregation policy can be changed through configuration on the ASBR 🌸 An implementation MAY support this functionality. A modified policy MUST include rules for building the RTs carried by the Inter-AS I-PMSI A-D routes originated by the ASBR 🫶

An Inter-AS I-PMSI A-D route for a given <AS, MVPN> shows that there are MVPN sites connected to one or more PEs in that AS 👑

An Inter-AS I-PMSI A-D route originated by an ASBR aggregates the Intra-AS I-PMSI A-D routes originated inside the ASBR's own AS. So the Intra-AS I-PMSI A-D routes inside an AS are at the granularity of <PE, MVPN> within that AS, but outside that AS, the (aggregated) Inter-AS I-PMSI A-D routes can be at the granularity of <AS, MVPN> 🦋

9.2.2. When Not to Originate Inter-AS I-PMSI A-D Routes

If, for a given MVPN and a given AS, every site connected to the PEs in that AS is known a priori to have no multicast sources, then the ASBRs of that AS MAY skip originating an Inter-AS I-PMSI A-D route for that MVPN altogether 🙈

9.2.3. Propagating Inter-AS I-PMSI A-D Routes

An Inter-AS I-PMSI A-D route for a given MVPN that an ASBR originates inside a given AS gets propagated over BGP to other ASes 🌈

9.2.3.1. Propagating Inter-AS I-PMSI A-D Routes - Overview

Say ASBR A installs an Inter-AS I-PMSI A-D route for MVPN V that came from a particular AS, AS1 🧚 The BGP Next Hop of that route becomes A's "upstream multicast hop" on a multicast distribution tree for V rooted at AS1 💖 Once the Inter-AS I-PMSI A-D routes have reached all the ASes that need them, they define a "reverse path" from any AS that supports MVPN V back to AS1 ✨ For example, if AS2 supports MVPN V, there will be a reverse path for MVPN V from AS2 to AS1 🎀 That path is a sequence of ASBRs, where the first one is in AS2 and the last one is in AS1, and each ASBR in the sequence is the BGP Next Hop of the previous ASBR in the sequence on that Inter-AS I-PMSI A-D route 🌸

That reverse path info can be used to build a unidirectional multicast distribution tree for MVPN V that includes all the ASes supporting V, with AS1 at the root 🦋 We call this an "inter-AS tree" 🫶 Multicast data that starts in MVPN sites connected to PEs in a given AS flows downstream along the tree rooted at that AS 💅

The path along an inter-AS tree is a sequence of ASBRs, but we still need to say how the multicast data gets from one ASBR to the set of ASBRs right below it on the tree 🧩 That's done by creating "segments": ASBRs in adjacent ASes are connected by inter-AS segments, and ASBRs in the same AS are connected by "intra-AS segments" 👑

An ASBR starts creating an intra-AS segment when it receives an Inter-AS I-PMSI A-D route from an EBGP neighbor 🌐 The segment creation is finished once that route gets distributed over IBGP inside the ASBR's own AS 💖

For a given inter-AS tunnel, each of its intra-AS segments could be built by its own independent mechanism 🧚 Also, by using upstream-assigned labels inside a given AS, multiple intra-AS segments from different inter-AS tunnels, of either the same or different MVPNs, may share the same P-multicast tree 🌈

If the P-multicast tree serving as a particular intra-AS segment of an inter-AS tunnel is created by a multicast control protocol that uses receiver-initiated joins (e.g., mLDP, any PIM variant), and that P-multicast tree doesn't aggregate multiple segments, then all the info needed to create the segment is already in the PMSI Tunnel attribute of the Inter-AS I-PMSI A-D routes 🎀 But if the P-multicast tree serving as the segment is created by a protocol that doesn't use receiver-initiated joins (e.g., RSVP-TE, ingress unicast replication), or if that P-multicast tree aggregates multiple segments (no matter which multicast control protocol built the tree), then Leaf A-D routes are needed too 🔥 The exact conditions for when Leaf A-D routes need to be used are described in the later sections 💅

Since (aggregated) Inter-AS I-PMSI A-D routes can have a granularity of <AS, MVPN>, an MVPN present in N ASes could have a total of N inter-AS tunnels 🦋 So for a given MVPN, the number of inter-AS tunnels making up the I-PMSIs doesn't depend on how many PEs have that MVPN 🌸

The precise rules for distributing and processing Inter-AS I-PMSI A-D routes across ASes are given in the following sections 🫶

9.2.3.2. Inter-AS I-PMSI A-D Route Received via EBGP ✨

okay so picture this, bestie: an ASBR gets a BGP Update from one of its EBGP neighbors, and it's carrying an Inter-AS I-PMSI A-D route 🦋 The ASBR only re-advertises it if both of these are true: (a) at least one of the Route Targets in the message matches one of the import Route Targets configured on the ASBR, and (b) the ASBR decides the received route is the best route for its NLRI. If that's a yes, it passes the route along to other PEs and ASBRs in its own AS. (How those guys handle it is in Section 9.2.3.4 💅)

When the ASBR re-advertises an Inter-AS I-PMSI A-D route, it MUST set the Next Hop field of the MP_REACH_NLRI attribute to a routable IP address of the ASBR. No skipping this one, periodt 💖

Now, if the received route carries the PMSI Tunnel attribute, the ASBR builds the re-advertised version differently depending on what technology it uses for the intra-AS segment of the inter-AS tunnel 🎀

If the ASBR uses ingress replication for that intra-AS segment, the re-advertised route MUST carry the PMSI Tunnel attribute with Tunnel Type set to Ingress Replication, but no MPLS labels. Simple and clean ✨
If the ASBR uses a P-multicast tree for that intra-AS segment, the PMSI Tunnel attribute MUST contain the identity of the tree. (Quick bonus: the ASBR could create that identity before the tree is actually instantiated 🧚) If the ASBR needs to know the leaves of the tree in order to instantiate it, it gets that info from the Leaf A-D routes that other PEs/ASBRs in its own AS sent (see Section 9.2.3.5), and it does that by setting the Leaf Information Required flag in the PMSI Tunnel attribute to 1 🫶
An ASBR using a P-multicast tree as the intra-AS segment of the inter-AS tunnel MAY aggregate two or more MVPNs present on the ASBR onto the same tree. In that case, the PMSI Tunnel attribute of the Inter-AS I-PMSI A-D route MUST carry, along with the identity of the tree, an MPLS upstream-assigned label that the PE has bound uniquely to the MVPN associated with this route (as determined by its RTs). Main character energy 👑

Here's the tricky bit: if the ASBR has already advertised Inter-AS I-PMSI A-D routes for two or more MVPNs that it now wants to aggregate, then the ASBR MUST re-advertise those routes. The re-advertised routes MUST be the same as the original ones, except for the PMSI Tunnel attribute and the MVPN label 🙈 Literally only those two things change, bestie.

9.2.3.2.1. Originating Leaf A-D Route into EBGP

okay so in addition, the ASBR MUST send, to the EBGP neighbor it got the Inter-AS I-PMSI A-D route from, a BGP Update message carrying a Leaf A-D route. Here's how that route gets built 🌸

The route carries a single MCAST-VPN NLRI, with the Route Key field set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route received from that neighbor, and the Originating Router's IP address set to the IP address of the ASBR (this MUST be a routable IP address 💅).
The Leaf A-D route MUST include the PMSI Tunnel attribute with Tunnel Type set to Ingress Replication and the Tunnel Identifier set to a routable address of the advertising router. The PMSI Tunnel attribute MUST also carry a downstream-assigned MPLS label, which the advertising router uses to demultiplex the MVPN traffic it receives over a unicast tunnel from the EBGP neighbor 🦋
The ASBR builds an IP-based Route Target Extended Community by putting the IP address carried in the Next Hop of the received Inter-AS I-PMSI A-D route into the Global Administrator field, with the Local Administrator field of this Community set to 0. Then it sets the Extended Communities attribute of the Leaf A-D route to that Community. Fun fact that's giving full circle: this Route Target is the same as the ASBR Import RT of the EBGP neighbor the ASBR got the Inter-AS I-PMSI A-D route from 🔥
The Next Hop field of the MP_REACH_NLRI attribute of the route MUST be set to the same IP address as the one carried in the Originating Router's IP Address field of the route ✨
To constrain the distribution scope of this route, the route MUST carry the NO_ADVERTISE BGP Community [RFC1997] 🤫

How the EBGP neighbor handles this Leaf A-D route is covered in Section 9.2.3.3.

Now the ASBR MUST set up its forwarding state so that packets arriving on the one-hop ASBR-ASBR LSP (as specified in the PMSI Tunnel attribute of the Leaf A-D route) get transmitted on the intra-AS segment (as specified in the PMSI Tunnel attribute of the Inter-AS I-PMSI A-D route the ASBR re-advertises in its own AS). BUT the packets MAY be filtered before forwarding, as described in Section 9.2.3.6 🧚

9.2.3.3. Leaf A-D Route Received via EBGP

okay so when an ASBR gets a Leaf A-D route over EBGP from its neighbor ASBR, and the Route Target in the route's Extended Communities attribute matches one of the ASBR Import RTs (auto-)configured on the ASBR, the ASBR does the following 💖

The ASBR finds the Inter-AS I-PMSI A-D route whose MCAST-VPN NLRI has the same value as the Route Key field of the Leaf A-D route.
If the ASBR itself originated that Inter-AS I-PMSI A-D route, then the ASBR sets up its forwarding state so that packets received on the intra-AS tunnels originating in the ASBR's own AS get transmitted on the one-hop ASBR-ASBR LSP specified by the MPLS label in the PMSI Tunnel attribute of the received Leaf A-D route. (However, the packets MAY be filtered before transmission, as specified in Section 9.2.3.6.) The intra-AS tunnels are the ones specified in the PMSI Tunnel attribute of all the Intra-AS I-PMSI A-D routes the ASBR received and aggregated into the Inter-AS I-PMSI A-D route. For each of these intra-AS tunnels, if a non-zero MPLS label is carried in the PMSI Tunnel attribute (i.e., aggregation is used), then only packets received on the inner LSP corresponding to that label MUST be forwarded, NOT the packets received on the outer LSP, because the outer LSP possibly carries the traffic of other VPNs 🙈 Protect the vibes, protect the VPNs.
If some other ASBR originated the found Inter-AS I-PMSI A-D route, then the ASBR sets up its forwarding state so that packets received on the intra-AS tunnel segment (as specified in the PMSI Tunnel attribute of the found Inter-AS I-PMSI A-D route) get transmitted on the one-hop ASBR-ASBR LSP, as specified by the MPLS label in the PMSI Tunnel attribute of the Leaf A-D route 🌈

9.2.3.4. Inter-AS I-PMSI A-D Route Received via IBGP

okay so quick terminology check 🎀 In this section, "PE/ASBR router" means either a PE or an ASBR router. Got it? Good.

If a BGP route reflector receives a given Inter-AS I-PMSI A-D route via IBGP, the route reflector MUST NOT modify the Next Hop field of the MP_REACH_NLRI attribute when re-advertising the route into IBGP. This is because the info carried in the Next Hop is used to control the flow of C-multicast routes, as specified in Section 11.2 💅

If a given Inter-AS I-PMSI A-D route is advertised within an AS by multiple ASBRs of that AS, the BGP best route selection done by the other PE/ASBR routers in that AS does NOT require all of them to pick the route from the same ASBR. Quite the opposite, honestly: different PE/ASBR routers may pick routes advertised by different ASBRs 🦋

When a PE/ASBR router gets a BGP Update from one of its IBGP neighbors carrying an Inter-AS I-PMSI A-D route, and (a) at least one of the Route Targets in the message matches one of the import Route Targets configured on the PE/ASBR, and (b) the PE/ASBR decides the received route is the best route to the destination in the NLRI of the route, then the PE/ASBR does the following 🔥

If the router is a PE, it imports the route into the VRF(s) that have the matching import Route Targets.
If the router is an ASBR, it propagates the route to its EBGP neighbors. When propagating, the ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a routable IP address of the ASBR. If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel attribute, the propagated route MUST carry the PMSI Tunnel attribute with Tunnel Type set to Ingress Replication, and the attribute carries no MPLS labels 💖
If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel attribute with Tunnel Type set to mLDP P2MP LSP, PIM-SSM tree, PIM-SM tree, or BIDIR-PIM tree, the PE/ASBR SHOULD join, as soon as possible, the P-multicast tree whose identity is carried in the Tunnel Identifier ✨
If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR that originated the route MUST establish an RSVP-TE P2MP LSP with the local PE/ASBR as a leaf. That LSP MAY have been established before the local PE/ASBR receives the route, OR it MAY be established after the local PE receives the route 🧚
If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel attribute with Tunnel Type set to mLDP P2MP LSP, RSVP-TE P2MP LSP, PIM-SSM, PIM-SM tree, or BIDIR-PIM tree, but the attribute carries no label, then the P-multicast tree identified by the PMSI Tunnel attribute is an intra-AS LSP segment. It's part of the inter-AS tunnel for the MVPN advertised by the Inter-AS I-PMSI A-D route, and it's rooted at the AS that originated that route. If the PMSI Tunnel attribute carries an (upstream-assigned) label, then the tree plus the label together identify the intra-AS segment. If the receiving router is an ASBR, this intra-AS segment may further be stitched to the ASBR-ASBR inter-AS segment of the inter-AS tunnel. And if the PE/ASBR has local receivers in the MVPN, packets received over the intra-AS segment must be forwarded to those local receivers using the local VRF 🌸

9.2.3.4.1. Originating Leaf A-D Route into IBGP ✨

okay so if the Leaf Information Required flag in the PMSI Tunnel attribute of the received Inter-AS I-PMSI A-D route is set to 1, then the PE/ASBR MUST originate a new Leaf A-D route. here's how it gets built 🧚

the route carries a single MCAST-VPN NLRI with the Route Key field set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route received from that neighbor, and the Originating Router's IP address set to the IP address of the PE/ASBR (this MUST be a routable IP address) 🫶
if the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication, then the Leaf A-D route MUST carry the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication. the Tunnel Identifier MUST carry a routable address of the PE/ASBR. the PMSI Tunnel attribute MUST carry a downstream-assigned MPLS label that is used to demultiplex the MVPN traffic received over a unicast tunnel by the PE/ASBR 💅
the PE/ASBR constructs an IP-based Route Target Extended Community by placing the IP address carried in the Next Hop of the received Inter-AS I-PMSI A-D route in the Global Administrator field of the Community, with the Local Administrator field of this Community set to 0, and sets the Extended Communities attribute of the Leaf A-D route to that Community. it's giving precision 🎀
the Next Hop field of the MP_REACH_NLRI attribute of the route MUST be set to the same IP address as the one carried in the Originating Router's IP Address field of the route 🌸
to constrain the distribution scope of this route, the route MUST carry the NO_EXPORT Community [RFC1997] 🔒
once the Leaf A-D route is constructed, the PE/ASBR advertises this route into IBGP 👑

9.2.3.5. Leaf A-D Route Received via IBGP 🦋

okay so when an ASBR receives a Leaf A-D route via IBGP, and the Route Target carried in the Extended Communities attribute of the route matches one of the ASBR Import RT (auto-)configured on the ASBR, the ASBR does the following.

the ASBR finds an Inter-AS I-PMSI A-D route whose MCAST-VPN NLRI has the same value as the Route Key field of the Leaf A-D route. 🔍

the received route may carry either (a) no PMSI Tunnel attribute, or (b) the PMSI Tunnel attribute, but only with the Tunnel Type set to Ingress Replication. ngl that's two possible vibes 🍓

if the received route does not carry the PMSI Tunnel attribute, the ASBR uses the information from the received route to determine the leaves of the P-multicast tree rooted at the ASBR that would be used for the intra-AS segment associated with the found Inter-AS I-PMSI A-D route. the IP address of a leaf is the IP address carried in the Originating Router's IP address field of the received Leaf A-D route. 🌈

if the received route carries the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication, the ASBR uses the information carried by the route to construct the intra-AS segment with ingress replication. ✨

9.2.3.6. Optimizing Bandwidth by IP Filtering on ASBRs 💜

an ASBR that has a given Inter-AS I-PMSI A-D route MAY discard some of the traffic carried in the tunnel specified in the PMSI Tunnel attribute of this route, if the ASBR determines that there are no downstream receivers for that traffic. bandwidth saver era 🙈

when BGP is being used to distribute C-multicast routes, an ASBR that has a given Inter-AS I-PMSI A-D route MAY discard traffic from a particular customer multicast source C-S and destined to a particular customer multicast group address C-G that is carried over the tunnel specified in the PMSI Tunnel attribute of the route, if none of the C-multicast routes on the ASBR with RD and Source AS being the same as the RD and Source AS of the Inter-AS I-PMSI A-D route matches the (C-S,C-G) tuple. a C-multicast route is said to match a (C-S,C-G) tuple if it is a Source Tree Join route with Multicast Source set to C-S and Multicast Group set to C-G, or a Shared Tree Join route with Multicast Group set to C-G. 🫶

the above procedures MAY also apply to an ASBR that originates a given Inter-AS I-PMSI A-D route. in this case, the ASBR applies them to the traffic carried over the tunnels specified in the PMSI Tunnel attribute of the Intra-AS I-PMSI A-D routes that the ASBR aggregates into the Inter-AS I-PMSI A-D route, and whose tails are stitched to the one-hop ASBR-ASBR tunnel specified in the Inter-AS I-PMSI A-D route. 🦋

10. Non-Congruent Unicast and Multicast Connectivity 🌸

it is possible to deploy MVPN such that the multicast routing and the unicast routing are "non-congruent". 🙃 for instance, the CEs may be distributing to the PEs a special set of unicast routes that are to be used exclusively for the purpose of upstream multicast hop selection, and not used for unicast routing at all. (for example, when BGP is the CE-PE unicast routing protocol, the CEs may be using SAFI 2 ("Network Layer Reachability Information used for multicast forwarding" [IANA-SAFI]), and either IPv4 or IPv6 AFI to distribute a special set of routes that are to be used for, and only for, upstream multicast hop selection.) in such a situation, we will speak of the MVPN as having two VRFs on a given PE: one containing the routes that are used for unicast, the other containing the unicast routes that are used for UMH selection. we will call the former the "unicast routing VRF" and the latter the "UMH VRF" (upstream-multicast-hop VRF). 🧚‍♀️

in this document, when we speak without qualification of the MVPN's VRF, then if the MVPN has both a unicast VRF and a UMH VRF, we are speaking of the UMH VRF. (of course, if there is no separate UMH VRF, then we are speaking of the unicast VRF.) 💅

if there is a separate UMH VRF, it MAY have its own import and export Route Targets, different from the ones used by the unicast VRF. these Route Targets MUST be used to control distribution of auto-discovery routes. in addition, the export Route Targets of the UMH VRF are added to the Route Targets used by the unicast VRF when originating (unicast) VPN-IP routes. the import Route Targets associated with a given UMH VRF are used to determine which of the received (unicast) VPN-IP routes should be accepted into the UMH VRF. 🎀

if a PE maintains an UMH VRF for that MVPN, then it is RECOMMENDED that the UMH VRF use the same RD as the one used by the unicast VRF of that MVPN. ✨

if an MVPN site is multihomed to several PEs, then to support non-congruent unicast and multicast connectivity, on each of these PEs, the UMH VRF of the MVPN MUST use its own distinct RD (although on a given PE, the RD used by the UMH VRF SHOULD be the same as the one used by the unicast VRF). 🍓

if an MVPN has a UMH VRF distinct from its unicast VRF, then one option to support non-congruency is to exchange the routes to/from that UMH VRF by using the same AFI/SAFI as used by the routes from the unicast VRF. 🌈

another option is to exchange the routes to/from the UMH VRF using the IPv4 or IPv6 AFI (as appropriate), but with the SAFI set to SAFI 129 "Multicast for BGP/MPLS IP Virtual Private Networks (VPNs)" [IANA-SAFI]. the NLRI carried by these routes is defined as follows:

+---------------------------+
|   Length (1 octet)        |
+---------------------------+
|   Prefix (variable)       |
+---------------------------+

the use and the meaning of these fields are as follows:

a) Length:

The Length field indicates the length, in bits, of the address prefix. 📏

b) Prefix:

The Prefix field contains a Route Distinguisher as defined in [RFC4364] prepended to an IPv4 or IPv6 address prefix, followed by enough trailing bits to make the end of the field fall on an octet boundary. note that the value of trailing bits is irrelevant. 🤷‍♀️

these routes MUST carry the VRF Route Import Extended Community. if, for a given MVPN, BGP is used for exchanging C-multicast routes, or if segmented inter-AS tunnels are used, then these routes MUST also carry the Source AS Extended Community. 🔥

the detailed procedures for selecting forwarder PE in the presence of such routes are outside the scope of this document. however, this document requires these procedures to preserve the constraints imposed by the single forwarder PE selection procedures, as specified in [MVPN]. 💖

11. Exchange of C-Multicast Routing Information among PEs 👑

VPN C-Multicast Routing Information is exchanged among PEs by using C-multicast routes that are carried using an MCAST-VPN NLRI. these routes are originated and propagated as follows. 🦋

11.1. Originating C-Multicast Routes by a PE 🧚

part of the procedures for constructing MCAST-VPN NLRI depends on the multicast routing protocol between CE and PE (C-multicast protocol). 🌸

11.1.1. Originating Routes: PIM as the C-Multicast Protocol 💅

the following specifies the construction of MCAST-VPN NLRI of C-multicast routes for the case where the C-multicast protocol is PIM. these C-multicast routes are originated as a result of updates in the (C-S,C-G), or (C-*,C-G) state learned by a PE via the C-multicast protocol. 🎀

note that creation and deletion of (C-S,C-G,rpt) states on a PE when the C-multicast protocol is PIM do not result in any BGP actions. 🙈

11.1.1.1. Originating Source Tree Join C-Multicast Route ✨

whenever (a) a C-PIM instance on a particular PE creates a new (C-S,C-G) state, and (b) the selected upstream PE for C-S (see [MVPN]) is not the local PE, then the local PE MUST originate a C-multicast route of type Source Tree Join. the Multicast Source field in the MCAST-VPN NLRI of the route is set to C-S; the Multicast Group field is set of C-G. 🍓

this C-multicast route is said to "correspond" to the C-PIM (C-S,C-G) state. 🌈

the semantics of the route are such that the PE has one or more receivers for (C-S,C-G) in the sites connected to the PE (the route has the (C-S,C-G) Join semantics). 🫶

whenever a C-PIM instance on a particular PE deletes a (C-S,C-G) state, the corresponding C-multicast route MUST be withdrawn. (the withdrawal of the route has the (C-S,C-G) Prune semantics). the MCAST-VPN NLRI of the withdrawn route is carried in the MP_UNREACH_NLRI attribute. 💀

11.1.1.2. Originating Shared Tree Join C-Multicast Route 🦋

whenever (a) a C-PIM instance on a particular PE creates a new (C-*,C-G) state, and (b) the selected upstream PE for the C-RP corresponding to the C-G (see [MVPN]) is not the local PE, then the local PE MUST originate a C-multicast route of type Shared Tree Join. the Multicast Source field in the MCAST-VPN NLRI of the route is set to the C-RP address. the Multicast Group field in the MCAST-VPN NLRI is set to the C-G address. 🧚‍♀️

this C-multicast route is said to "correspond" to the C-PIM (C-*,C-G) state. 💜

the semantics of the route are such that the PE has one or more receivers for (C-,C-G) in the sites connected to the PE (the route has the (C-,C-G) Join semantics). 👑

whenever a C-PIM instance on a particular PE deletes a (C-*,C-G) state, the corresponding C-multicast route MUST be withdrawn. (the withdrawal of the route has the (C-S,C-G) Prune semantics). the MCAST-VPN NLRI of the withdrawn route is carried in the MP_UNREACH_NLRI attribute. 🥺

11.1.2. Originating Routes: mLDP as the C-Multicast Protocol 🎀

okay bestie, this section is for when mLDP [mLDP] is the C-multicast protocol 💖 here's how the MCAST-VPN NLRI of C-multicast routes gets built 🧚

whenever a PE gets a P2MP Label Map <X, Y, L> from one of its CEs over interface I (where X is the Root Node Address, Y is the Opaque Value, and L is an MPLS label), it checks whether it already has state for <X, Y> in the VRF tied to that CE 👀 if it does, the PE literally just updates its forwarding state by adding <I, L> to the forwarding state for <X, Y> ✨ easy peasy

if the PE does NOT have state for <X, Y> in that VRF, it builds a Source Tree Join C-multicast route. the MCAST-VPN NLRI carries X as the Multicast Source field and Y as the Multicast Group field 🦋

whenever a PE deletes a previously created <X, Y> state that had led to originating a C-multicast route, the PE withdraws that route 💅 the MCAST-VPN NLRI of the withdrawn route rides along in the MP_UNREACH_NLRI attribute 🫶

11.1.3. Constructing the Rest of the C-Multicast Route 🌸

the rest of the C-multicast route gets built like this (and it's the same procedure whether PIM or mLDP is the C-Multicast protocol, so no drama 💜)

the local PE runs the [MVPN] procedures to find the selected Upstream Multicast Hop (UMH) route and the selected upstream PE for the address carries in the Multicast Source field of the MCAST-VPN NLRI 🔍

from the selected UMH route, the local PE pulls out two things 💖:

(a) the ASN of the upstream PE (as carried in the Source AS Extended Community of the route)
(b) the C-multicast Import RT of the VRF on the upstream PE (the value of this C-multicast Import RT is the value of the VRF Route Import Extended Community carried by the route)

then the Source AS field in the C-multicast route gets set to that AS, and the Route Target Extended Community of the C-multicast route gets set to that C-multicast Import RT 🎀

if there's more than one (remote) PE originating the (unicast) route to the address in the Multicast Source field of the MCAST-VPN NLRI, the procedures for picking the UMH route and the upstream PE to reach that address are as specified in [MVPN] 🧠

if the local and upstream PEs are in the same AS, the RD of the advertised MCAST-VPN NLRI is set to the RD of the VPN-IP route that contains the address in the Multicast Source field 🌈

the C-multicast route is then advertised into IBGP ✨

if the local and upstream PEs are in different ASes, it's a little more involved 🫠 the local PE looks in its VRF for an Inter-AS I-PMSI A-D route whose Source AS field carries the ASN of the upstream PE. the RD of that found Inter-AS I-PMSI A-D route becomes the RD of the advertised C-multicast route 💅

the local PE then builds an IP-based Route Target Extended Community by putting the Next Hop of the found Inter-AS I-PMSI A-D route in the Global Administrator field, with the Local Administrator field set to 0. it adds this Community to the Extended Communities attribute of the C-multicast route 🦋 (fun fact: this Route Target is the same as the ASBR Import RT of the ASBR identified by that Next Hop 💜)

Inter-AS I-PMSI A-D routes are not used to support non-segmented inter-AS tunnels. 🙈 for those, if the local and upstream PEs are in different ASes, the local system looks in its VRF for an Intra-AS I-PMSI A-D route from the upstream PE. the Originating Router's IP Address field of that route has the same value as the one carried in the VRF Route Import of the (unicast) route to the address in the Multicast Source field 🧩 the RD of that found Intra-AS I-PMSI A-D route becomes the RD of the advertised C-multicast route, and the Source AS field in the C-multicast route is set to the value of the Originating Router's IP Address field of that found route 🌷

the Next Hop field of the MP_REACH_NLRI attribute MUST be set to a routable IP address of the local PE 🔥

if the Next Hop of the found (Inter-AS or Intra-AS) I-PMSI A-D route is an EBGP neighbor of the local PE, then the PE advertises the C-multicast route to that neighbor 📮 if that Next Hop is within the same AS as the local PE, the PE advertises the C-multicast route into IBGP 🫶

11.1.4. Unicast Route Changes 🔄

the UMH route a given PE picks for a given C-S can be influenced by the network's unicast routing 🌊 so if unicast routing changes, the old UMH choice for some C-S might be invalid 💀 when that happens, the local PE MUST run the UMH route selection procedures for C-S again 🔁 if that leads to a different UMH route being selected, then for all C-G, any previously originated C-multicast routes for (C-S,C-G) MUST be re-originated 🦋

same vibe for C-RP 🧚 if a unicast routing change results in a change of the UMH route for a C-RP, then for all C-G where C-RP is the RP associated with C-G, any previously originated C-multicast routes for (C-*,C-G) MUST be re-originated 💖

11.2. Propagating C-Multicast Routes by an ASBR 📣

when an ASBR gets a BGP Update message carrying a C-multicast route, it checks whether at least one of the route's Route Targets matches one of the ASBR Import RTs (auto-)configured on the ASBR 🎯 if so, the ASBR looks for an Inter-AS I-PMSI A-D route whose RD and Source AS match the RD and Source AS in the C-multicast route. no match? the ASBR takes no further action 🙅‍♀️ match found? then it goes through the steps below ✨

for non-segmented inter-AS tunnels, the ASBR instead of matching the RD and Source AS against an Inter-AS I-PMSI A-D route should match them against the RD and the Originating Router's IP Address of the Intra-AS I-PMSI A-D routes 🌸

the ASBR first checks if it already has one or more C-multicast routes with the same MCAST-VPN NLRI as the newly received route 👀 if one (or more) already exists, the ASBR keeps the newly received route but SHALL NOT re-advertise it 🙈 otherwise, the ASBR re-advertises the route as described in this section 💅

when an ASBR gets a BGP Update message carrying a withdrawal of a previously advertised C-multicast route, it first checks whether it already has at least one other C-multicast route with the same MCAST-VPN NLRI 🔍 if such a route exists, the ASBR processes the withdrawn route but SHALL NOT re-advertise the withdrawal 🫠 otherwise, it re-advertises the withdrawal of the previously advertised C-multicast route, as described below 🦋

if the ASBR is the one that originated the found Inter-AS I-PMSI A-D route, then before re-advertising the C-multicast route into IBGP, it removes from the route the Route Target that matches one of the ASBR Import RTs (auto-)configured on the ASBR 🧹

if the ASBR is NOT the one that originated the found Inter-AS I-PMSI A-D route, then before re-advertising the C-multicast route, the ASBR changes the Extended Communities attribute of the C-multicast route. it swaps the Route Target that matches one of its ASBR Import RTs for a new one 🔄 the new Route Target is an IP-based Route Target with the Global Administrator field set to the Next Hop of the found Inter-AS I-PMSI A-D route and the Local Administrator field set to 0. this newly built Route Target is the same as the ASBR Import RT of the ASBR identified by that Next Hop 💜 the rest of the Extended Communities attribute of the route SHOULD be passed unmodified 🎀

the Next Hop field of the MP_REACH_NLRI attribute SHOULD be set to an IP address of the ASBR 🌈

if the Next Hop field of the MP_REACH_NLRI of the found (Inter-AS or Intra-AS) I-PMSI A-D route is an EBGP neighbor of the ASBR, the ASBR re-advertises the C-multicast route to that neighbor 📮 if it's an IBGP neighbor of the ASBR, the ASBR re-advertises the C-multicast route into IBGP 🫶 and if the ASBR is the one that originated the found Inter-AS I-PMSI A-D route in the first place, it just re-advertises the C-multicast route into IBGP ✨

11.3. Receiving C-Multicast Routes by a PE 💌

when a PE receives a C-multicast route, it checks whether any Route Target Extended Communities in the route's Extended Communities attribute match any of the C-multicast Import RTs associated with the VRFs of any MVPN the PE maintains 👀 no match? the PE SHOULD discard the route 🗑️ if there IS a match, the PE checks whether the address in the Multicast Source field of the C-multicast route matches one of the (unicast) VPN-IP routes the PE advertised from the VRF 🔍 no match there? the PE SHOULD discard the route too 🙅‍♀️ if a match is found, the PE carries on depending on the multicast routing protocol between the CE and the PE (the C-multicast protocol) 💖

11.3.1. Receiving Routes: PIM as the C-Multicast Protocol 🌷

this part describes what happens when PIM is the multicast routing protocol between the CE and the PE (the C-multicast protocol) 🧚

since C-multicast routing information gets spread around by BGP, PIM messages are NEVER sent from one PE to another 🙈 BGP does all the talking here 💅

11.3.1.1. Receiving Source Tree Join C-Multicast Route ✨

okay so when the received route has its Route Type set to Source Tree Join 💖, the PE makes a brand new (C-S,C-G) state in its MVPN-TIB. It grabs the Multicast Source and Multicast Group fields from the MCAST-VPN NLRI of the route, but only if that state doesn't already exist. No double-dipping 💅.

Next, the PE checks its local policy. If the policy says to bind (C-S,C-G) to an S-PMSI, the PE adds that S-PMSI to the outgoing interface list of the (C-S,C-G) state, as long as it's not already there. If the policy doesn't say that, the PE adds an I-PMSI to the list instead, same idea, if it's not already in there 🎀.

Now the withdrawal part. When, for a said VRF, the last Source Tree Join C-multicast route for (C-S,C-G) gets withdrawn, leaving the VRF with no Source Tree Join C-multicast route for (C-S,C-G), the PE MUST remove the I-PMSI/S-PMSI from the outgoing interface list of the (C-S,C-G) state. Depending on the (C-S,C-G) state of the PE-CE interfaces, this might make the PE use PIM procedures to prune itself off the (C-S,C-G) tree 🦋. If C-G is not in the SSM range for the VRF, the removal SHOULD happen after a delay controlled by a timer. That timer MUST be configurable ⏰.

Why the timer? It makes sure the PE doesn't stop forwarding (C-S,C-G) onto a PMSI tunnel until every PE in the same MVPN has had time to receive the withdrawal of the Source Active A-D route for (C-S,C-G) (see Section 13.1). It also gives the PE connected to C-RP time to start forwarding (C-S,C-G) on the C-RPT. Timing is everything, bestie 🕰️.

Heads up: before the PE stops forwarding (C-S,C-G), the local PE and the PE connected to the site that contains C-RP might both be sending (C-S,C-G) packets on the PMSI at the same time. That's transient, unnecessary traffic on the provider backbone, which is a little wasteful 😭. But no duplicates will reach customer hosts subscribed to C-G, as long as the downstream PEs apply the procedures in Section 9.1 of [MVPN] 🙌.

11.3.1.2. Receiving Shared Tree Join C-Multicast Route

If the received route has its Route Type set to Shared Tree Join 🌸, the PE creates a new (C-*,C-G) state in its MVPN-TIB, if one doesn't already exist. The RP address for that state comes from the Multicast Source field, and C-G comes from the Multicast Group field of the MCAST-VPN NLRI of the route. If there's no S-PMSI for (C-*,C-G), the PE adds the I-PMSI to the outgoing interface list of the state, if it's not already there. If there is an S-PMSI for (C-*,C-G), the PE adds the S-PMSI to the list instead, if it's not already there.

Withdrawal time again 🥺. When, for a said VRF, the last Shared Tree Join C-multicast route for (C-*,C-G) is withdrawn, leaving the VRF with no Shared Tree Join C-multicast route for (C-*,C-G), the PE MUST remove the I-PMSI/S-PMSI from the outgoing interface list of the (C-*,C-G) state. Depending on the (C-*,C-G) state of the PE-CE interfaces, this might make the PE use PIM procedures to prune itself off the (C-*,C-G) tree 🌈.

11.3.2. Receiving Routes: mLDP as the C-Multicast Protocol

This part explains what happens when mLDP is the multicast routing protocol between the CE and the PE (the C-multicast protocol) 🧚.

When mLDP is the C-multicast protocol, the only valid type of C-multicast route a PE could receive is a Source Tree Join C-multicast route 💅.

When the PE gets a Source Tree Join C-multicast route, it applies the P2MP mLDP procedures for a transit node, in the scope of this VRF. It uses the value in the Multicast Source field as the C-Root Node Identifier, and the value in the Multicast Group field as the C-LDP MP Opaque Value Element ✨.

If there's no S-PMSI for <C-Root Node Identifier, C-LDP MP Opaque Value Element>, the PE creates and advertises an S-PMSI as described in Section 12. It uses the C-Root Node Identifier as the value for the Multicast Source field of the S-PMSI A-D route, and the C-LDP MP Opaque Value Element as the value for its Multicast Group field 🎀.

For scalability (very main character of it 👑), when mLDP is the C-Multicast protocol for a given MVPN, every AS that has sites of that MVPN connected to its PEs can aggregate all the S-PMSIs of that MVPN into a single P-multicast tree, using upstream-assigned labels. This is optional, since the spec says these S-PMSIs MAY be aggregated 🦋.

11.4. C-Multicast Routes Aggregation

Here's the tea 🍓: C-multicast routes get "de facto" aggregated by BGP. That's because the MCAST-VPN NLRIs advertised by multiple PEs for a C-multicast route for a particular C-S and C-G (or a particular C-* and C-G) of a given MVPN are identical 🫶.

So a BGP route reflector or ASBR that receives multiple such routes with the same NLRI only re-advertises one of them to other BGP speakers. Iconic efficiency 💅.

This also means C-multicast routes for a given (S,G) of a given MVPN, originated by PEs that are clients of a given route reflector, get aggregated by that route reflector. For example, if several PEs that are clients of a route reflector have receivers for a specific SSM channel of an MVPN, they'll all advertise an identical NLRI for the Source Tree Join C-multicast route. Only one C-multicast route gets advertised by the route reflector for that SSM channel of that MVPN, to other PEs and route reflectors that are its clients 🌸.

It also means an ASBR aggregates all the C-multicast routes it receives for a given (S,G) (or a given (*,G)) of a given MVPN into a single C-multicast route 🧁.

To cut down on routing churn from C-multicast route changes, a route reflector that re-advertises a C-multicast route SHOULD set the Next Hop field of the MP_REACH_NLRI attribute of the route to an IP address of the route reflector. Likewise, an ASBR that re-advertises a C-multicast route SHOULD set the Next Hop field of the MP_REACH_NLRI attribute of the route to an IP address of the ASBR 🔥.

Last bit of the aggregation story 🎀: a BGP receiver gets multiple such routes with the same NLRI for the same C-multicast route, so it'll potentially create forwarding state based on a single C-multicast route. Per the procedures described in Section 11.3, that forwarding state will be the same as the state that would've been created from another route with the same NLRI 😌.

12. Using S-PMSI A-D Routes to Bind C-Trees to P-Tunnels 🦋

This section is where the BGP magic happens 🪄. It describes the BGP-based procedures for using S-PMSI A-D routes to bind (C-S,C-G) trees to P-tunnels 💖.

12.1. Originating S-PMSI A-D Routes 🎀

okay so this section is where a PE actually builds its S-PMSI A-D route, and it's giving "fill in the NLRI one field at a time" 💅 Here's what the PE does for a given (C-S,C-G) ✨

The RD in this NLRI is set to the RD of the MVPN's VRF associated with (C-S,C-G).
The Multicast Source field MUST contain the source address associated with the C-multicast stream, and the Multicast Source Length field is set appropriately to reflect this.
The Multicast Group field MUST contain the group address associated with the C-multicast stream, and the Multicast Group Length field is set appropriately to reflect this.
The Originating Router's IP Address field MUST be set to the IP address that the (local) PE places in the Global Administrator field of the VRF Route Import Extended Community of the VPN-IP routes advertised by the PE. ngl this is the key detail 🔑 Note that the <RD, Originating Router's IP address> tuple uniquely identifies a given multicast VRF.

Next up, the rest of the route. The PMSI Tunnel attribute depends on what kind of P-multicast tree the P-tunnel is using 🌈

The PMSI Tunnel attribute MUST contain the identity of the P-multicast tree (the PE could create that identity before the tree is actually instantiated, which is lowkey iconic 🧚).
If, in order to establish the P-multicast tree, the PE needs to know the leaves of the tree within its own AS, then the PE gets that info from the Leaf A-D routes received from other PEs/ASBRs in its own AS. Those PEs/ASBRs originate Leaf A-D routes in response to receiving the S-PMSI A-D route. The PE does this by setting the Leaf Information Required flag in the PMSI Tunnel attribute to 1 🫶
If a PE originates S-PMSI A-D routes with the Leaf Information Required flag in the PMSI Tunnel attribute set to 1, then the PE MUST be (auto-)configured with an import Route Target, which controls acceptance of Leaf A-D routes by the PE. (The procedures for originating Leaf A-D routes by the PEs that receive the S-PMSI A-D route are in Section 12.3.)

This Route Target is IP address specific. 🚨 The Global Administrator field of this Route Target MUST be set to the IP address carried in the Next Hop of all the S-PMSI A-D routes advertised by this PE. If the PE uses different Next Hops, then the PE MUST be (auto-)configured with multiple import RTs, one per each such Next Hop. The Local Administrator field of this Route Target MUST be set to 0.

If the PE supports Route Target Constraint [RT-CONSTRAIN], the PE SHOULD advertise this import Route Target within its own AS using Route Target Constraints. To keep those Route Target Constraint routes from leaving the AS of the advertising PE, they SHOULD carry the NO_EXPORT Community [RFC1997] 🙈

A PE MAY aggregate two or more S-PMSIs originated by the PE onto the same P-multicast tree. If the PE already advertises S-PMSI A-D routes for these S-PMSIs, then aggregation requires the PE to re-advertise these routes. The re-advertised routes MUST be the same as the original ones, except for the PMSI Tunnel attribute. If the PE has not previously advertised S-PMSI A-D routes for these S-PMSIs, then the aggregation requires the PE to advertise (new) S-PMSI A-D routes for these S-PMSIs. The PMSI Tunnel attribute in the newly advertised/re-advertised routes MUST carry the identity of the P-multicast tree that aggregates the S-PMSIs. If at least some of the S-PMSIs aggregated onto the same P-multicast tree belong to different MVPNs, then all these routes MUST carry an MPLS upstream-assigned label [RFC5331] 🌸

If all these aggregated S-PMSIs belong to the same MVPN, and this MVPN uses PIM as its C-multicast routing protocol, then the corresponding S-PMSI A-D routes MAY carry an MPLS upstream-assigned label [RFC5331]. In this case, the labels MUST be distinct on a per-MVPN basis and MAY be distinct on a per-route basis. ok the label rules are a whole vibe 🦋

If all these aggregated S-PMSIs belong to the MVPN(s) that use mLDP as their C-multicast routing protocol, then the corresponding S-PMSI A-D routes MUST carry an MPLS upstream-assigned label [RFC5331]. These labels MUST be distinct on a per-route (per-mLDP FEC) basis, no matter whether the aggregated S-PMSIs belong to the same or different MVPNs 👑

The Next Hop field of the MP_REACH_NLRI attribute of the route MUST be set to the same IP address as the one carried in the Originating Router's IP Address field 💜

The route always carries a set of Route Targets. The default set is figured out like this:

If there is a (unicast) VPN-IP route to C-S originated from the VRF, but no (unicast) VPN-IP route to C-RP originated from the VRF, then the set of Route Targets is formed by a set intersection between the set of Route Targets carried in the Intra-AS I-PMSI A-D route originated from the VRF and the set of Route Targets carried by the (unicast) VPN-IP route to C-S.
If there is no (unicast) VPN-IP route to C-S originated from the VRF, but there is a (unicast) VPN-IP route to C-RP originated from the VRF, then the set of Route Targets is formed by a set intersection between the set of Route Targets carried in the intra-AS I-PMSI A-D route originated from the VRF and the set of Route Targets carried by the (unicast) VPN-IP route to C-RP.
If there is a (unicast) VPN-IP route to C-S originated from the VRF, and a (unicast) VPN-IP route to C-RP originated from the VRF, then the set of Route Targets is formed by a set intersection between the set of Route Targets carried in the Intra-AS I-PMSI A-D route originated from the VRF and the set union of Route Targets carried by the (unicast) VPN-IP route to C-S and the (unicast) VPN-IP route to C-RP.

In each of the above cases, an implementation MUST allow the set of Route Targets carried by the route to be specified by configuration. If there's no configured set, the route MUST carry the default set of Route Targets, as specified above. The config always gets the final say 🍓

12.2. Handling S-PMSI A-D Routes by ASBRs 🌈

Okay so when an ASBR handles an S-PMSI A-D route, it follows the same procedures as Section 9.2.3, just with S-PMSI A-D routes in place of Inter-AS I-PMSI A-D routes. Easy peasy 🎀

12.2.1. Merging S-PMSI into an I-PMSI 🦋

Picture this situation 🎬

An ASBR is receiving (or expecting to receive) inter-AS (C-S,C-G) data from upstream via an S-PMSI.
The ASBR is sending (or expecting to send) the inter-AS (C-S,C-G) data downstream via an I-PMSI.

This can happen when the upstream providers use S-PMSIs but the downstream providers use I-PMSIs. To make it work, an ASBR MAY, under certain conditions, merge one or more upstream S-PMSIs into a downstream I-PMSI 🫶

An S-PMSI (corresponding to a particular S-PMSI A-D route) MAY be merged by a particular ASBR into an I-PMSI (corresponding to a particular Inter-AS I-PMSI A-D route) if and only if all of the following conditions hold 👀

BGP is used to exchange C-multicast routes.
The S-PMSI A-D route and the Inter-AS I-PMSI A-D route originate in the same AS. The Inter-AS I-PMSI A-D route carries the originating AS in the Source AS field of the NLRI of the route and in the AS_PATH attribute of the route. The S-PMSI A-D route carries the originating AS in the AS_PATH attribute of the route.
The S-PMSI A-D route and the Inter-AS I-PMSI A-D route have exactly the same set of RTs.
For each (C-S,C-G) mentioned in the S-PMSI route, if the ASBR has installed a Source Tree Join (C-S,C-G) C-multicast route, then the S-PMSI route was originated by the upstream PE of the C-multicast route. The address of the upstream PE is carried in the RT of the C-multicast route. The address of the PE that originated the S-PMSI route is carried in the Originating Router's IP Address field of the MCAST-VPN NLRI of the route.
The ASBR supports the optional capability to discard (C-S,C-G) traffic received on an I-PMSI.

An ASBR does the merge by stitching the tail end of the P-tunnel (as specified in the PMSI Tunnel attribute of the S-PMSI A-D route it received) onto the head of the P-tunnel (as specified in the PMSI Tunnel attribute of the Inter-AS I-PMSI A-D route it re-advertises). It's like a tunnel handoff, bestie 🧚

IP processing during merge: If an ASBR merges a (C-S,C-G) S-PMSI A-D route into an Inter-AS I-PMSI A-D route, the ASBR MUST discard all (C-S,C-G) traffic it receives on the tunnel advertised in the I-PMSI A-D route. This part is non-negotiable 🚫

An ASBR that merges an S-PMSI A-D route into an Inter-AS I-PMSI A-D route MUST NOT re-advertise the S-PMSI A-D route. Do not re-advertise, periodt 💀

12.3. Receiving S-PMSI A-D Routes by PEs 🎀

Okay so, picture a PE that receives an S-PMSI A-D route 🦋 If one or more of its VRFs have import Route Targets that match one or more of the Route Targets carried by that route, then for each of those VRFs (and its associated MVPN-TIB), the PE does the following ✨

Receiving an S-PMSI A-D route works the same way whether the PE is inside or outside the AS of the PE that originated it, just like Section 9.2.3.4 describes. There are two twists, though 💅 First, the procedures apply to S-PMSI A-D routes instead of Inter-AS I-PMSI A-D routes. Second, the PE only runs those steps if, on top of the usual criteria, one of these is true:

the PE originates a Source Tree Join (C-S,C-G) C-multicast route, and the upstream PE of that route is the PE that originates the S-PMSI A-D route; or
the PE doesn't originate a Source Tree Join (C-S,C-G) C-multicast route, but it does originate a Shared Tree Join (C-*,C-G) C-multicast route. The best Source Active A-D route for (C-S,C-G) that the PE selects (using the BGP route selection procedures) is originated by the same PE that originates the S-PMSI A-D route; or
the PE doesn't originate a Source Tree Join (C-S,C-G), hasn't received any Source Active A-D routes for (C-S,C-G), but does originate a Shared Tree Join (C-*,C-G) route. The upstream PE for that route is the PE that originates the received S-PMSI A-D route.

If the received S-PMSI A-D route has a PMSI Tunnel attribute with the Leaf Information Required flag set to 1, then the PE originates a Leaf A-D route 🌸 The Route Key of that Leaf A-D route is set to the MCAST-VPN NLRI of the S-PMSI A-D route. The rest of the Leaf A-D route gets built using the same procedures as Section 9.2.3.4.1, except that instead of originating Leaf A-D routes in response to Inter-AS I-PMSI A-D routes, the procedures now apply to originating Leaf A-D routes in response to S-PMSI A-D routes. Main character energy 👑

On top of the procedures in Section 9.2.3.4.1, the PE MUST set up its forwarding path to receive (C-S,C-G) traffic from the tunnel advertised by the S-PMSI A-D route. In other words, the PE MUST switch to the S-PMSI 🔥

If a PE that's a leaf node of a particular Selective tunnel figures out that it no longer needs to receive any of the (C-S,C-G)s carried over that tunnel, the PE SHOULD prune itself off that tunnel 🫶 How pruning works depends on the specific tunneling technology.

13. Switching from Shared a C-Tree to a Source C-Tree ✨

This section is where things get spicy 🌶️ The procedures here only apply when the C-multicast routing protocol is PIM [RFC4601]. They also only apply to the multicast ASM mode, and they MUST NOT be applied to multicast group addresses in the SSM range. And the procedures MUST NOT be applied when the C-multicast routing protocol is BIDIR-PIM [RFC5015] 🙈

These procedures only matter for MVPNs that use both shared (rooted at a C-RP) and source (rooted at a C-S) inter-site C-trees 💖

If an MVPN relies solely on source inter-site C-trees and doesn't use shared inter-site C-trees at all, these procedures don't apply to it. Go to Section 14 for what that scenario needs 🧚

Whether or not a given MVPN uses both inter-site shared and source C-trees must be known a priori, for example through provisioning 🍓

Here's the tea 🫖 When an MVPN customer switches from a C-RP-based tree (RPT) to the shortest path tree (SPT), picking a single consistent upstream PE, the way [MVPN] describes, might not be enough to avoid packet duplication. Let's walk through it. Say we have a set of PEs, {PE2, PE4, PE6}, that are on the C-RP tree for (C-*,C-G) and have all chosen a consistent upstream PE, the way [MVPN] describes, for that (C-*,C-G) state. Now say this upstream PE, PE1, is using a Multidirectional Inclusive PMSI (MI-PMSI) for (C-*,C-G). If a site attached to one of these PEs, say PE2, switches to the C-S tree for (C-S,C-G), then PE2 generates a Source Tree Join C-multicast route toward the upstream PE that's on the path to C-S, say PE3. PE3 also uses the MI-PMSI for (C-S,C-G), the same way PE1 uses it for (C-*,C-G). The result? {PE2, PE4, PE6} receive duplicate traffic for (C-S,C-G), both on the C-RP tree (from PE1) and on the C-S tree (from PE3) 😭 If you want to suppress that duplicate traffic, you need to choose a single forwarder PE for (C-S,C-G). Here's how that gets done 💅

13.1. Source within a Site - Source Active Advertisement 📣

When the local PE adds either the S-PMSI or the I-PMSI to the outgoing interface list of the (C-S,C-G) state, as a result of receiving a Source Tree Join C-multicast route for (C-S,C-G) from some other PE (see Section 11.3.1.1), the local PE MUST originate a Source Active A-D route, unless it has already originated one. The route carries a single MCAST-VPN NLRI built like this:

The RD in this NLRI is set to the RD of the VRF of the MVPN on the PE.
The Multicast Source field MUST be set to C-S. The Multicast Source Length field is set appropriately to reflect this.
The Multicast Group field MUST be set to C-G. The Multicast Group Length field is set appropriately to reflect this.

The Next Hop field of the MP_REACH_NLRI attribute MUST be set to the IP address that the PE places in the Global Administrator field of the VRF Route Import Extended Community of the VPN-IP routes that the PE advertises from the MVPN's VRF 🌈

The route SHOULD carry the same set of Route Targets as the Intra-AS I-PMSI A-D route of the MVPN that the PE originates 🎀

Using the normal BGP procedures, the Source Active A-D route gets propagated to all the PEs of the MVPN ✨

Quick aside 🧁 The advertisement of a Source Active A-D route for a given (C-S,C-G) can be combined, if you want, with the advertisement of an S-PMSI A-D route for that same (C-S,C-G). You do this by using the same BGP Update message to carry both the NLRI of the S-PMSI A-D route and the NLRI of the Source Active A-D route.

Even if the originating PE advertises both the Source Active A-D route and the S-PMSI A-D route in the same BGP Update message, an implementation cannot assume that all other PEs will receive both of those routes in the same Update message. Don't be that implementation 🙅‍♀️

When the PE receives a withdrawal of the previously advertised Source Tree Join C-multicast route for (C-S,C-G), and as a result is going to remove the S-PMSI/I-PMSI from the outgoing interface list of the (C-S,C-G) state, the local PE MUST also withdraw the Source Active A-D route for (C-S,C-G), if such a route has been advertised 🥀

Last one, and it's a fun one 💀 If the PE is also acting as a C-RP, but inter-site shared trees are being used, then the PE receiving a PIM Register message does not result in the origination of a Source Active A-D route.

13.2. Receiving Source Active A-D Route 🦋

When a PE receives a new Source Active A-D route from some other PE, it finds a VRF whose import Route Targets match one or more of the Route Targets carried by the route. If it finds a match, the PE updates that VRF with the received route 💜

We say that a given (C-S,C-G) Source Active A-D route stored in a given VRF on a PE matches a given (C-*,C-G) entry present in the MVPN-TIB associated with that VRF if the C-G carried by the route is the same as the C-G of the entry, and the PE originates a Shared Tree Join C-multicast route for the same C-G as the C-G of the entry 👀

When (as a result of receiving PIM messages from one of its CEs) a PE creates a new (C-*,C-G) entry in one of its MVPN-TIBs, with a non-empty outgoing interface list that contains one or more PE-CE interfaces, the PE MUST check if it has any matching Source Active A-D routes. If there's one or more such matching route, and the PE doesn't have (C-S,C-G) state in its MVPN-TIB for the (C-S,C-G) carried in the route, then the PE selects one of them (using the BGP route selection procedures) and sets up its forwarding path to receive (C-S,C-G) traffic from the tunnel that the originator of the selected Source Active A-D route uses for sending (C-S,C-G) 🔥

When a PE updates its VRF with a new Source Active A-D route, the PE MUST check if the newly received route matches any (C-*,C-G) entries. If (a) there is a matching entry, (b) the PE doesn't have (C-S,C-G) state in its MVPN-TIB for the (C-S,C-G) carried in the route, and (c) the received route is selected as the best (using the BGP route selection procedures), then the PE sets up its forwarding path to receive (C-S,C-G) traffic from the tunnel that the originator of the selected Source Active A-D route uses for sending (C-S,C-G) 🌸

One more heads-up 🫶 If the PE is also acting as a C-RP and inter-site shared trees are being used, the BGP Source Active A-D routes do NOT replace the Multicast Source Discovery Protocol (MSDP) or PIM-based Anycast RP peerings among C-RPs. Those peerings are still needed to disseminate source discovery information among C-RPs.

13.2.1. Pruning Sources off the Shared Tree 🌸

okay so, on top of everything in the previous section, a PE has one more thing to do whenever it imports a Source Active A-D route for (C-S,C-G) into a VRF 💅

First, the PE hunts down the (C-*,C-G) entry in the MVPN-TIB whose C-G matches the C-G in the Multicast Group field of that Source Active A-D route 🔍

If the outgoing interface list (oif) of that (C-,C-G) entry on the PE has either I-PMSI or S-PMSI in it, AND the PE does not originate the Source Tree Join C-multicast route for (C-S,C-G) (where C-S is the address in the Multicast Source field and C-G is the address in the Multicast Group field of the received Source Active A-D route), then the PE MUST transition the (C-S,C-G,rpt) downstream state machine on I-PMSI/S-PMSI to the Prune state. 🫶 Conceptually, the C-PIM state machine on the PE acts "as if" it got a Prune (C-S,C-G,rpt) on I-PMSI/S-PMSI, even though it never actually got one. Depending on the (C-S,C-G,rpt) state of the PE-CE interfaces, this might make the PE use PIM procedures to prune the C-S off the (C-,C-G) tree 🌳

Moving to the Prune state SHOULD happen after a delay that's run by a timer ⏰ The value of that timer MUST be configurable. The whole point of the timer is to make sure the C-S doesn't get pruned off the shared tree until every PE has had time to receive the Source Active A-D route for (C-S,C-G). Patience is a virtue, bestie 🙏

Heads up, though: before the C-S is pruned off the shared tree, it's possible for distinct PEs to send (C-S,C-G) packets on the PMSI at the same time. That causes some transient, unnecessary traffic on the provider backbone 🙈 Still, no duplicates reach customer hosts subscribed to C-G, as long as the downstream PEs apply the procedures described in Section 9.1 of [MVPN] ✨

The PE MUST keep the (C-S,C-G,rpt) downstream state machine on I-PMSI/S-PMSI in the Prune state for as long as all of these are true: (a) the oif of the found (C-*,C-G) entry in the MVPN-TIB on the PE contains either I-PMSI or S-PMSI, (b) the PE has at least one Source Active A-D route for (C-S,C-G), and (c) the PE does not originate the Source Tree Join C-multicast route for (C-S,C-G). The second any of these stops being true, the PE MUST transition the (C-S,C-G,rpt) downstream state machine on I-PMSI/S-PMSI to the NoInfo state 🥀

Also, changing that downstream state machine on I-PMSI/S-PMSI doesn't mean exchanging PIM messages over I-PMSI/S-PMSI. Nope, no messages, just state 🤫

And last but not least, outside of the scenario from the third paragraph of this section, relying only on PIM procedures on the PE is enough to keep things behaving correctly when pruning sources off the shared tree. Slay 👑

14. Supporting PIM-SM without Inter-Site Shared C-Trees 🧚

The procedures in this section only apply when the C-multicast routing protocol is PIM [RFC4601]. They also only apply to the multicast ASM mode, and they MUST NOT be applied to multicast group addresses in the SSM range. And they MUST NOT be applied when the C-multicast routing protocol is BIDIR-PIM [RFC5015] 🚫

These procedures are only for MVPNs that do NOT use inter-site shared (i.e., rooted at a C-RP) C-trees 🌸

They're also not for MVPNs that use both shared and shortest path inter-site C-trees. If that's your situation, check out Section 13 instead 📖

Whether a given MVPN uses inter-site shared C-trees must be known a priori (e.g., via provisioning). So you need to know this ahead of time, bestie 📝

14.1. Discovering Active Multicast Sources 🔭

A PE can find out about active multicast sources within a given MVPN in a bunch of ways. One option is for the PE to act as a fully functional customer RP (C-RP) for that MVPN. Another is to use PIM Anycast RP procedures [PIM-ANYCAST-RP] to pass info about active multicast sources from one or more of the MVPN C-RPs over to the PE. And there's also MSDP [MSDP], which can convey that same info from the MVPN C-RPs to the PE 💖

When a PE using any of those methods first learns about a new (multicast) source in that MVPN, it builds a Source Active A-D route and sends it to every other PE that has one or more sites of that MVPN connected to it ✨ The route carries a single MCAST-VPN NLRI, built like this:

The RD in this NLRI is set to the RD of the VRF of the MVPN on the PE.
The Multicast Source field MUST be set to the source IP address of the multicast data packet carried in the PIM Register message (RP/PIM register case) or of the MSDP Source-Active message (MSDP case). The Multicast Source Length field is set appropriately to reflect this.
The Multicast Group field MUST be set to the group IP address of the multicast data packet carried in the PIM Register message (RP/PIM register case) or of the MSDP Source-Active message (MSDP case). The Multicast Group Length field is set appropriately to reflect this.

The Next Hop field of the MP_REACH_NLRI attribute MUST be set to the IP address that the PE puts in the Global Administrator field of the VRF Route Import Extended Community of the VPN-IP routes the PE advertises 🧠

The route SHOULD carry the same set of Route Targets as the Intra-AS I-PMSI A-D route of the MVPN that the PE originated 🎀

Using the normal BGP procedures, the Source Active A-D route gets propagated to all the PEs of the MVPN 📡

Now, when a PE that previously advertised a Source Active A-D route for a given (multicast) source learns that the source is no longer active (it figures this out using the same mechanism it used to learn the source was active), the PE SHOULD withdraw that Source Active route. Clean up after yourself, babe 🧹

14.2. Receiver(s) within a Site 🙋‍♀️

A PE follows the procedures in Section 11.1, EXCEPT the procedures in Section 11.1.1.2 get swapped out for the ones in this section. Plot twist 🎬

When a PE receives a new Source Active A-D route, it looks for a VRF whose import Route Targets match one or more of the Route Targets carried by the route. If it finds a match, the PE updates that VRF with the received route 🔁

We say that a given (C-S,C-G) Source Active A-D route stored in a given VRF matches a given (C-*,C-G) entry in the MVPN-TIB associated with that VRF if the C-G carried by the route is the same as the C-G of the entry 💜

When a PE creates a new (C-*,C-G) entry in one of its MVPN-TIBs (because it got PIM messages from one of its CEs), and that entry has a non-empty oif containing one or more PE-CE interfaces, the PE MUST check whether it has any matching Source Active A-D routes. If it has one or more of them, and the best path to C-S carried in those matching routes is reachable through some other PE, then the PE MUST originate a Source Tree Join C-multicast route for each one. If it has one or more of them, and the best path to C-S carried in those routes is reachable through a CE connected to the PE, then the PE MUST originate a PIM Join (C-S,C-G) towards that CE 🫧

When a PE gets a new Source Active A-D route and updates its VRF with it, the PE MUST check whether the newly received route matches any (C-*,C-G) entries. If there's a matching entry and the best path to C-S carried in the (A-D) route is reachable through some other PE, the PE MUST originate a Source Tree Join C-multicast route for the (C-S,C-G) carried by the route. If there's a matching entry and the best path to C-S carried in the (A-D) route is reachable through a CE connected to the PE, the PE MUST originate a PIM Join (C-S,C-G) towards that CE 🚀

Building and distributing the Source Tree Join C-multicast route follows the procedures in Section 11.1.1.1, with one twist: the Multicast Source Length, Multicast Source, Multicast Group Length, and Multicast Group fields in the MCAST-VPN NLRI of the Source Tree Join C-multicast route get copied from the matching fields in the Source Active A-D route 🪞

A PE MUST withdraw a Source Tree Join C-multicast route for (C-S,C-G) if, because it got PIM messages from one of its CEs, the PE creates a Prune (C-S,C-G,rpt) upstream state in one of its MVPN-TIBs but has no (C-S,C-G) Joined state in that MVPN-TIB, AND it had previously advertised that route. (This holds even if the VRF for that MVPN-TIB still has a (C-S,C-G) Source Active A-D route 🙃)

A PE MUST also withdraw a Source Tree Join C-multicast route for (C-S,C-G) if the Source Active A-D route that triggered the advertisement of that C-multicast route gets withdrawn 💔

When a PE deletes the (C-,C-G) state (e.g., because it got PIM Prune (C-,C-G) from its CEs), the PE MUST withdraw all the Source Tree Join C-multicast routes for C-G that it advertised, EXCEPT the ones where the PE still keeps the matching (C-S,C-G) state 🧽

Even though PIM is the C-multicast protocol here, the procedures in Section 11.1.1.2 don't apply, because only Source Tree Join C-multicast routes get exchanged among PEs. No PIM Joins over the provider backbone, just these routes 🙌

14.3. Receiving C-Multicast Routes by a PE 📬

In this model, the only valid type of C-multicast route a PE can receive is a Source Tree Join C-multicast route. Processing that route follows the procedures in Section 11.3.1.1, and that's it, that's the tea ☕

15. Carrier's Carrier 🎀

There's a way to support the Carrier's Carrier model, and it's done by using mLDP as the CE-PE multicast routing and label distribution protocol, as specified in this document 🦋

For better scalability, it is RECOMMENDED that, for the Carrier's Carrier scenario within an AS, all the S-PMSIs of a given MVPN get aggregated into a single P-multicast tree (by using upstream-assigned labels). Big brain move, honestly 🧠💅

16. Scalability Considerations 🌸

okay so this is the scalability part and it's giving big brain energy 🧠✨. A PE should use Route Target Constraint [RT-CONSTRAIN] to advertise the Route Targets that the PE uses for the VRF Route Import Extended Community. Doing this takes just a single Route Target Constraint advertisement by the PE 💅. The result is that each C-multicast route reaches only the relevant PE, instead of every PE participating in an MVPN.

To keep the intra-AS membership/binding information within the AS of the advertising router, the BGP Update message originated by the advertising router SHOULD carry the NO_EXPORT Community [RFC1997] 🔒.

An Inter-AS I-PMSI A-D route originated by an ASBR aggregates Intra-AS I-PMSI A-D routes originated within the ASBR's own AS. So while Intra-AS I-PMSI A-D routes inside an AS are at the granularity of <PE, MVPN> within that AS, outside of that AS the (aggregated) Inter-AS I-PMSI A-D routes are at the granularity of <AS, MVPN>. An Inter-AS I-PMSI A-D route for a given <AS, MVPN> indicates the presence of one or more sites of the MVPN connected to the PEs of the AS 🦋.

For a given inter-AS tunnel, each of its intra-AS segments could be constructed by its own mechanism. Also, by using upstream-assigned labels within a given AS, multiple intra-AS segments of different inter-AS tunnels of either the same or different MVPNs may share the same P-multicast tree 🌈.

Since (aggregated) Inter-AS I-PMSI A-D routes may have a granularity of <AS, MVPN>, an MVPN that is present in N ASes would have a total of N inter-AS tunnels. So for a given MVPN, the number of inter-AS tunnels is independent of the number of PEs that have this MVPN 🙌.

Within each Autonomous System, BGP route reflectors can be partitioned among the MVPNs present in that Autonomous System. That way each partition carries routes for only a subset of the MVPNs supported by the service provider, and no single route reflector has to maintain routes for all MVPNs 🧚. Route reflectors used for MVPN also don't have to be used for VPN-IP routes, although they may be used for VPN-IP routes as well.

As described in Section 11.4, C-multicast routes for a given (S,G) of a given MVPN originated by PEs that are clients of a given route reflector are aggregated by the route reflector. So even if there are multiple C-multicast routes for a given (S,G) of a given MVPN within a route reflector cluster, outside of the cluster all of these routes are aggregated into a single C-multicast route. There's extra aggregation at ASBRs too: an ASBR aggregates all the received C-multicast routes for a given (S,G) of a given MVPN into a single C-multicast route. Also, both route reflectors and ASBRs maintain C-multicast routes only in the control plane, not in the data plane 💜.

16.1. Dampening C-Multicast Routes

the rate of C-multicast routing changes advertised by a PE isn't necessarily directly proportional to the rate of multicast routing changes within the MVPN sites connected to the PE 🤷‍♀️. After the first (C-S,C-G) Join originated within a site, all the later Joins for the same (C-S,C-G) originated within sites of the same MVPN connected to the PE don't cause the PE to originate new C-multicast routes.

Depending on how the multicast VPN is engineered, dynamic addition and removal of P2MP RSVP-TE leaves will happen through advertisement and withdrawal of Leaf A-D routes. Dampening techniques can be used to limit the corresponding processing 🎀.

To lessen the control plane overhead of processing C-multicast routes, this document proposes OPTIONAL route dampening procedures similar to what is described in [RFC2439]. The following OPTIONAL procedures can be enabled on a PE, ASBR, or BGP Route Reflector advertising or receiving C-multicast routes 💖.

16.1.1. Dampening Withdrawals of C-Multicast Routes

A PE/ASBR/route reflector can OPTIONALLY delay the advertisement of withdrawals of C-multicast routes. An implementation SHOULD provide the ability to control the delay via a configurable timer, possibly with some backoff algorithm to adapt the delay to multicast routing activity ⏳.

Dampening withdrawals of C-multicast routes does not impede the multicast Join latency observed by MVPN customers. It also doesn't impede the multicast leave latency observed by a CE, because multicast forwarding from the VRF stops as soon as C-multicast state is removed in the VRF 🏃‍♀️.

The potential drawbacks of dampening withdrawals of C-multicast routes are:

Until the withdrawals are actually sent, multicast traffic for the C-multicast routes in question will keep being transmitted to the PE, which will just have to discard it. The PE may receive useless (multicast) traffic anyway, regardless of dampening of withdrawals, because of the use of I-PMSIs.
Any state in the upstream PEs that would be removed as a result of processing the withdrawals will remain until the withdrawals are sent.

Whether these potential drawbacks matter in practice is outside the scope of this document 🤷‍♀️.

16.1.2. Dampening Source/Shared Tree Join C-Multicast Routes

A PE/ASBR/route reflector can OPTIONALLY delay the advertisement of Source/Shared Tree Join C-multicast routes. An implementation SHOULD provide the ability to control the delay via a configurable timer, possibly with some backoff algorithm to adapt the delay to multicast routing activity 🕰️.

Dampening Source/Shared Tree Join C-multicast routes will not impede multicast Join latency observed by a given MVPN, except if the PE advertising the Source/Shared Tree Join C-multicast route for a particular C-S/C-RP is the first to do so for all the sites of the MVPN that share the same upstream PE with respect to the C-S/C-RP 👑.

16.2. Dampening Withdrawals of Leaf A-D Routes

Similar to the procedures above for withdrawal of C-multicast routes, dampening can be applied to the withdrawal of Leaf A-D routes 🦋.

17. Security Considerations 🔐

the security part is SERIOUS, bestie 😭. Read every word.

The mechanisms described in this document could reuse the existing BGP security mechanisms [RFC4271] [RFC4272]. The security model and threats specific to Provider Provisioned VPNs, including L3VPNs, are discussed in [RFC4111]. [MVPN] discusses additional threats specific to the use of multicast in L3VPNs. There is currently work in progress to improve the security of TCP authentication. When the document is finalized as an RFC, the method defined in [RFC5925] SHOULD be used where authentication of BGP control packets is needed 🛡️.

A PE router MUST NOT accept, from CEs routes, with MCAST-VPN SAFI 🚫.

If BGP is used as a CE-PE routing protocol, then when a PE receives a route from a CE, and this route carries the VRF Route Import Extended Community, the PE MUST remove this Community from the route before turning it into a VPN-IP route. Routes that a PE advertises to a CE MUST NOT carry the VRF Route Import Extended Community 🙅‍♀️.

It is important to protect the control plane resources within the PE, so that one VPN can't hog excessive resources. This is the subject of the rest of the Security Considerations section 😤.

When C-multicast routing information is exchanged among PEs using BGP, an implementation SHOULD provide the ability to rate limit the BGP messages used for this exchange. This SHOULD be provided on a per-PE, per-MVPN granularity 🚦.

An implementation SHOULD provide capabilities to impose an upper bound on the number of S-PMSI A-D routes, as well as on how frequently they may be originated. This SHOULD be provided on a per-PE, per-MVPN granularity 📏.

In conjunction with the procedures specified in Section 14, an implementation SHOULD provide capabilities to impose an upper bound on the number of Source Active A-D routes, as well as on how frequently they may be originated. This SHOULD be provided on a per-PE, per-MVPN granularity 🧱.

In conjunction with the procedures specified in Section 13, limiting the amount of (C-S,C-G) state would limit the amount of Source Active A-D routes. In this section's context, Source Active A-D routes are created in response to Source Tree Join C-multicast routes, and Source Tree Join C-multicast routes are created as a result of creating (C-S,C-G) state on PEs. However, to provide an extra level of robustness, an implementation MAY provide capabilities to impose an upper bound on the number of Source Active A-D routes, as well as on how frequently they may be originated. This MAY be provided on a per-PE, per-MVPN granularity 🧁.

Section 16.1.1 describes optional procedures for dampening withdrawals of C-multicast routes. It is RECOMMENDED that an implementation support such procedures 💜.

Section 16.1.1 describes optional procedures for dampening withdrawals of Leaf A-D routes. It is RECOMMENDED that an implementation support such procedures ✨.

18. IANA Considerations 📋

This document defines a new BGP Extended Community called "Source AS". This Community is of an extended type and is transitive. The Type value for this Community has been allocated from the two-octet AS-Specific Extended Community registry as 0x0009, and from the four-octet AS-Specific Extended Community registry as 0x0209 🗂️.

This document defines a new BGP Extended Community called "VRF Route Import" (Type value 0x010b). This Community is IP address specific, of an extended type, and is transitive 🌸.

This document defines a new NLRI, called "MCAST-VPN", to be carried in BGP using multiprotocol extensions. It has been assigned SAFI 5. Also, SAFI 129 has been assigned to "Multicast for BGP/MPLS IP Virtual Private Networks (VPNs)" 🎉.

This document defines a new BGP optional transitive attribute, called "PMSI_TUNNEL". IANA has assigned the codepoint 22 in the "BGP Path Attributes" registry to the PMSI_TUNNEL attribute 🍓.

This document defines a new BGP optional transitive attribute, called "PE Distinguisher Labels". IANA has assigned the codepoint 27 in the "BGP Path Attributes" registry to the PE Distinguisher Labels attribute 🦋.

19. Acknowledgements 🫶

We would like to thank Chaitanya Kodeboniya for helpful discussions. We would also like to thank members of the L3VPN IETF Working Group for insightful comments and review 💖.

20. References 📚

20.1. Normative References ✨

okay so these are the reference docs the spec literally can't function without, bestie 📚💅

[IANA-SAFI] IANA, "Subsequent Address Family Identifiers (SAFI)
            Parameters", http://www.iana.org.

[MVPN]      Rosen, E., Ed. and R. Aggarwal, Ed., "Mulitcast in
            MPLS/BGP IP VPNs", RFC 6513, February 2012.

[RFC1997]   Chandra, R., Traina, P., and T. Li, "BGP Communities
            Attribute", RFC 1997, August 1996.

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4271]   Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
            Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
            2006.

[RFC4360]   Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
            Communities Attribute", RFC 4360, February 2006.

[RFC4364]   Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
            Networks (VPNs)", RFC 4364, February 2006.

[RFC4601]   Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
            "Protocol Independent Multicast - Sparse Mode (PIM-SM):
            Protocol Specification (Revised)", RFC 4601, August 2006.

[RFC4659]   De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
            "BGP-MPLS IP Virtual Private Network (VPN) Extension for
            IPv6 VPN", RFC 4659, September 2006.

[RFC4760]   Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
            "Multiprotocol Extensions for BGP-4", RFC 4760, January
            2007.

20.2. Informative References 🦋

these ones are the bonus reading: super helpful, not strictly required to get the vibe 🧚🌸

[mLDP]      Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
            Thomas, "Label Distribution Protocol Extensions for
            Point-to-Multipoint and Multipoint-to-Multipoint Label
            Switched Paths", RFC 6388, November 2011.

[MSDP]      Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source
            Discovery Protocol (MSDP)", RFC 3618, October 2003.

[PIM-ANYCAST-RP]
            Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
            Independent Multicast (PIM)", RFC 4610, August 2006.

[RFC5331]   Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
            Label Assignment and Context-Specific Label Space", RFC
            5331, August 2008.

[RT-CONSTRAIN]
            Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
            R., Patel, K., and J. Guichard, "Constrained Route
            Distribution for Border Gateway Protocol/MultiProtocol
            Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
            Private Networks (VPNs)", RFC 4684, November 2006.

[RFC2439]   Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
            Flap Damping", RFC 2439, November 1998.

[RFC4111]   Fang, L., Ed., "Security Framework for Provider-
            Provisioned Virtual Private Networks (PPVPNs)", RFC 4111,
            July 2005.

[RFC4272]   Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
            4272, January 2006.

[RFC4607]   Holbrook, H. and B. Cain, "Source-Specific Multicast for
            IP", RFC 4607, August 2006.

[RFC4875]   Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
            Yasukawa, Ed., "Extensions to Resource Reservation
            Protocol - Traffic Engineering (RSVP-TE) for Point-to-
            Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
            2007.

[RFC5015]   Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
            "Bidirectional Protocol Independent Multicast (BIDIR-
            PIM)", RFC 5015, October 2007.

[RFC5925]   Touch, J., Mankin, A., and R. Bonica, "The TCP
            Authentication Option", RFC 5925, June 2010.

Authors' Addresses 💖

and here are the brilliant minds behind it all, the people who actually wrote this masterpiece 🫶✨

Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
EMail: raggarwa_1@yahoo.com

Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719
EMail: erosen@cisco.com

Thomas Morin
France Telecom - Orange
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
EMail: thomas.morin@orange.com

Yakov Rekhter
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
EMail: yakov@juniper.net

that's the whole RFC, bestie, we did it 🌈👑

📦 where this page comes from

ietf: rfc6514 2012-02
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms