RFC 7117

Multicast in Virtual Private LAN Service (VPLS) 🎀

Okay bestie, let's do the paperwork first 💅 This is RFC 7117, a Standards Track document, so it's official IETF stuff and not just vibes. It was published in February 2014 by the Internet Engineering Task Force (IETF), and its ISSN is 2070-1721 ✨ The editor is R. Aggarwal, Ed. from Juniper Networks, and the rest of the crew is Y. Kamite from NTT Communications, L. Fang from Microsoft, Y. Rekhter from Juniper Networks, and C. Kodeboniya. The title block doesn't list an affiliation for C. Kodeboniya, so I'm not gonna guess 🙈 It also doesn't list any Obsoletes or Updates entries, so this header doesn't replace or patch any other RFCs. Lowkey clean 🌸

Abstract

Okay so, [RFC4761] and [RFC4762] describe a way to do VPLS multicast that depends on point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) to carry the multicast traffic. Honestly, that approach has some limitations for certain VPLS multicast traffic profiles 😭 For example, it can end up with really non-optimal bandwidth usage when a huge amount of multicast traffic needs to get moved around.

This document is here to fix a subset of those limitations 💖 It describes VPLS multicast procedures that use multicast trees in the service provider (SP) network. One of those trees can be shared between multiple VPLS instances, which is so efficient 🦋 It also lets a single multicast tree in the SP network carry only the traffic for a specified set of one or more IP multicast streams from one or more VPLS instances. That's giving precision 💅

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 went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 🎀

For the current status, any errata, and how to give feedback on this document, go to http://www.rfc-editor.org/info/rfc7117.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date this document was published. Please read these carefully, because they describe your rights and restrictions for this document. Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💜

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So, unless you get an adequate license from whoever controls that copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🫶

---

Table of Contents

   1. Introduction ....................................................4
   2. Terminology .....................................................5
      2.1. Specification of Requirements ..............................6
   3. Overview ........................................................6
      3.1. Inclusive and Selective Multicast Trees ....................7
      3.2. BGP-Based VPLS Membership Auto-discovery ...................8
      3.3. IP Multicast Group Membership Discovery ....................8
      3.4. Advertising P-Multicast Tree to VPLS/C-Multicast Binding ...9
      3.5. Aggregation ...............................................10
      3.6. Inter-AS VPLS Multicast ...................................11
   4. Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding .....12
      4.1. Originating Intra-AS VPLS A-D Routes ......................13
      4.2. Receiving Intra-AS VPLS A-D Routes ........................14
   5. Demultiplexing P-Multicast Tree Traffic ........................15
      5.1. One P-Multicast Tree - One VPLS Mapping ...................15
      5.2. One P-Multicast Tree - Many VPLS Mapping ..................15
   6. Establishing P-Multicast Trees .................................16
      6.1. Common Procedures .........................................16
      6.2. RSVP-TE P2MP LSPs .........................................16
           6.2.1. P2MP TE LSP - VPLS Mapping .........................17
      6.3. Receiver-Initiated P2MP LSP ...............................18
           6.3.1. P2MP LSP - VPLS Mapping ............................18
      6.4. Encapsulation of Aggregate P-Multicast Trees ..............18
   7. Inter-AS Inclusive P-Multicast Tree A-D/Binding ................18
      7.1. VSIs on the ASBRs .........................................19
           7.1.1. Option (a): VSIs on the ASBRs ......................19
           7.1.2. Option (e): VSIs on the ASBRs ......................20
      7.2. Option (b) - Segmented Inter-AS Trees .....................20
           7.2.1. Segmented Inter-AS Trees VPLS Inter-AS
                  A-D/Binding ........................................20
           7.2.2. Propagating BGP VPLS A-D Routes to Other
                  ASes: Overview .....................................21
                  7.2.2.1. Propagating Intra-AS VPLS A-D
                           Routes in EBGP ............................23
                  7.2.2.2. Inter-AS A-D Route Received via EBGP ......23
                  7.2.2.3. Leaf A-D Route Received via EBGP ..........25
                  7.2.2.4. Inter-AS A-D Route Received via IBGP ......25
      7.3. Option (c): Non-segmented Tunnels .........................26
   8. Optimizing Multicast Distribution via Selective Trees ..........27
      8.1. Protocol for Switching to Selective Trees .................29
      8.2. Advertising (C-S, C-G) Binding to a Selective Tree ........30
      8.3. Receiving S-PMSI A-D Routes by PEs ........................32
      8.4. Inter-AS Selective Tree ...................................34
           8.4.1. VSIs on the ASBRs ..................................35
                  8.4.1.1. VPLS Inter-AS Selective Tree A-D Binding ..35

           8.4.2. Inter-AS Segmented Selective Trees .................35
                  8.4.2.1. Handling S-PMSI A-D Routes by ASBRs .......36
                           8.4.2.1.1. Merging Selective Tree
                                      into an Inclusive Tree .........37
           8.4.3. Inter-AS Non-segmented Selective Trees .............38
   9. BGP Extensions .................................................38
      9.1. Inclusive Tree/Selective Tree Identifier ..................38
      9.2. MCAST-VPLS NLRI ...........................................39
           9.2.1. S-PMSI A-D Route ...................................40
           9.2.2. Leaf A-D Route .....................................41
   10. Aggregation Considerations ....................................41
   11. Data Forwarding ...............................................43
      11.1. MPLS Tree Encapsulation ..................................43
           11.1.1. Mapping Multiple VPLS Instances to a P2MP LSP .....43
           11.1.2. Mapping One VPLS Instance to a P2MP LSP ...........44
   12. VPLS Data Packet Treatment ....................................45
   13. Security Considerations .......................................46
   14. IANA Considerations ...........................................47
   15. References ....................................................47
      15.1. Normative References .....................................47
      15.2. Informative References ...................................48
   16. Acknowledgments ...............................................50

---

1. Introduction ✨

Okay so [RFC4761] and [RFC4762] describe a solution for VPLS multicast/broadcast that depends on pseudowires carried over unicast point-to-point (P2P) RSVP Traffic Engineering (RSVP-TE) or multipoint-to-point (MP2P) LDP Label Switched Paths (LSPs) ([RFC3209] [RFC5036]). In this document, we call this solution "ingress replication" 🎀

Here's how ingress replication works 💅 When the ingress Provider Edge (PE) of a given VPLS instance gets a multicast/broadcast packet from one of the Customer Edges (CEs) in that instance, the ingress PE copies the packet for each egress PE in that instance. Then it sends each copy to its egress PE using unicast tunnels. Very copy-paste, very efficient, very not.

The ingress replication solution has certain limitations for certain VPLS multicast/broadcast traffic profiles 😭 For example, it can cause really non-optimal bandwidth usage in the MPLS network when a large amount of multicast/broadcast traffic is moving around (more on this in [RFC5501]).

Ingress replication might be totally fine when the multicast/broadcast traffic bandwidth is low, and/or when only a small number of copies go out on each outgoing interface for a particular VPLS customer multicast stream 🌸 If that's not the case, then it's desirable to use multicast trees in the SP network to send VPLS multicast and/or broadcast packets [RFC5501] 🦋

This document describes procedures for overcoming the limitations of the existing VPLS multicast solutions 💖 It explains how to use MPLS point-to-multipoint (P2MP) LSPs in the SP network to transport VPLS multicast and/or broadcast packets. These LSPs can be signaled by either P2MP RSVP-TE [RFC4875] or Multipoint LDP (mLDP) [RFC6388] 🧚

The procedures in this document apply to both [RFC4761] and [RFC4762] ✨

2. Terminology ✨

okay bestie, let's get the vocab down first 💅 this doc uses the terms from [RFC4761] and [RFC4762], so those are the base layer. we also call the various auto-discovery routes "A-D routes" 🦋

the prefix 'C' means customer control or data packets, and 'P' means provider control or data packets. an IP (multicast source, multicast group) tuple gets shortened to (S, G) 🌸

an "Inclusive tree" is ONE multicast distribution tree in the SP network that carries all the multicast traffic from one VPLS instance on a given PE. ✨

an "Aggregate Inclusive tree" is also one multicast distribution tree in the SP network, but this one carries all the multicast traffic from MORE than one VPLS instance on a given PE. it's giving sharing 🫶

a "Selective tree" is one multicast distribution tree in the SP network that carries multicast traffic ONLY for a specified set of IP multicast streams, and all of those streams belong to the same VPLS instance on a given PE. the lowkey difference from an Inclusive tree is that a Selective tree may reach a subset of the PEs that an Inclusive tree reaches. very picky, very efficient 💖

an "Aggregate Selective tree" is one multicast distribution tree in the SP network that carries multicast traffic ONLY for a specified set of IP multicast streams, and those streams belong to more than one VPLS instance on a given PE. so it's the group-project version of a Selective tree 🎀

2.1. Specification of Requirements 📜

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. these are the official rule words, so read them carefully bestie 🙈

3. Overview 🦋

okay so the big picture: the procedures in this doc let ONE multicast distribution tree in the SP network carry all the multicast traffic from one or more VPLS sites connected to a given PE. this works whether the sites are in the same VPLS instance or different ones 🌈 if the tree carries traffic from ONE VPLS instance on a given PE, we call it an "Inclusive tree." if it carries traffic from MORE than one VPLS instance on a given PE, it's an "Aggregate Inclusive tree." the Inclusive tree stuff gets more detail in the "Inclusive and Selective Multicast Trees" section 🍓

to make bandwidth use even better for IP multicast streams, this doc also gives procedures so ONE multicast distribution tree in the SP network can carry traffic that belongs ONLY to a specified set of IP multicast streams. those streams originate in one or more VPLS sites connected to a given PE, again whether the sites are in the same or different VPLS instances 💅 we call it a "Selective tree" if it carries IP multicast streams that belong to the same VPLS instance on a given PE. we call it an "Aggregate Selective tree" if it carries IP multicast streams that belong to different VPLS instances on a given PE. the way this works: multicast traffic rides an Inclusive tree by default, while traffic from specific streams, like high-bandwidth ones, can go on one of the Selective trees ✨ more on Selective trees is in the "Inclusive and Selective Multicast Trees" section too 🧚

this doc only covers using Selective trees for carrying IP multicast streams. any other use of those trees is outside the scope of this document 🙅‍♀️

unicast packets going to unknown Media Access Control (MAC) addresses (aka not learned yet at the ingress PE) in a given VPLS instance get flooded to remote PEs in that same VPLS instance. this flooding MAY still use ingress replication (as specified in [RFC4761] and [RFC4762]), or it MAY use the procedures in this document to optimize flooding across the SP core 🫧

multicast trees in the SP network are super useful when the multicast traffic has high bandwidth, or when you want fewer copies of a multicast packet going over a given link. BUT (and this is a big but) the benefit comes at a cost: state in the SP network to build the trees, plus overhead to maintain that state 😭

3.1. Inclusive and Selective Multicast Trees 🌷

multicast trees used for VPLS come in two types:

• Inclusive trees. this option uses a single multicast distribution tree, called an "Inclusive P-multicast tree," in the SP network to carry ALL the multicast traffic from a specified set of VPLS sites connected to a given PE. there is no assumption about whether this traffic is IP encapsulated or not 🤷‍♀️ one P-multicast tree can be set up to carry traffic from sites in a single VPLS instance, OR it can carry traffic from sites in different VPLS instances. in this doc, carrying traffic from more than one VPLS instance on the same P-multicast tree is called "aggregation" 💜 the tree includes every PE that is a member of ANY of the VPLS instances using the tree. this means a PE may receive multicast traffic for a multicast stream even if it has no receivers interested in that stream. (not fair to that PE, but that's the deal 😬)

an Inclusive P-multicast tree, as defined in this doc, is a P2MP tree. so a P2MP tree only carries traffic from VPLS sites connected to the PE that is the root of the tree 🌸

• Selective trees. a Selective P-multicast tree is used by a PE to send IP multicast traffic for one or more specific IP multicast streams. those streams come in over PE-CE interfaces that belong to the same or different VPLS instances, and they go to a subset of the PEs in those VPLS instances. each PE in that subset should be on the path to a receiver of one or more multicast streams mapped onto the tree 🎯 in this doc, using the same P-multicast tree for multicast streams from different VPLS instances is also called "aggregation." the whole point of Selective P-multicast trees is to let a PE make separate SP multicast trees for specific streams, like high-bandwidth ones 🚀 that way, traffic for those streams only reaches the PE routers that have receivers for them. no more flooding every other PE in the VPLS instance 🙌

an SP can use Inclusive P-multicast trees, Selective P-multicast trees, or both, for a given VPLS on a PE, based on local configuration ⚙️ Inclusive P-multicast trees can be used for both IP and non-IP data multicast traffic. Selective P-multicast trees, as we said before, MUST be used ONLY for IP multicast data traffic. wait no, correction for the vibes: in the original text they're written as "must be used only for IP multicast data traffic," so that's the rule I'm keeping, lowercase, and the rule still stands. using Selective P-multicast trees for non-IP multicast traffic is outside the scope of this document 🙅‍♀️

P-multicast trees in the SP network can be realized through a variety of technologies. for both Inclusive and Selective P-multicast trees, these include P2MP LSPs created by RSVP-TE or mLDP 🧩 this doc also describes the data plane encapsulations for supporting these technologies. other technologies for realizing P-multicast trees are outside the scope of this document 💫

3.2. BGP-Based VPLS Membership Auto-discovery 🔍

Inclusive P-multicast trees may be established for one or more VPLS instances. in this case, aggregation can be performed (using either mLDP or P2MP RSVP-TE as the tunneling technology), or simple tunneling can be performed (using P2MP RSVP-TE tunneling) 🎀 if either of these approaches is used, the PE acting as the root of a P2MP LSP must be able to discover the other PEs that have membership in each of the VPLS instances. once the root PE discovers these other PEs, it includes them as leaves in the P-multicast tree (aka the P2MP LSP) 🌳 this doc uses the BGP-based procedures described in [RFC4761] and [RFC6074] to discover the VPLS membership of all PEs. for more on aggregation, check the "Aggregation Considerations" section 📚 when NO aggregation is performed and the tunneling technology is mLDP, the root of the P2MP LSP does NOT need to discover the other PEs that are the leaves of that LSP tree 🙃

the leaves of the Inclusive P-multicast tree must also be able to auto-discover the identifier of the tree. (this applies when the tree is set up by either mLDP or P2MP RSVP-TE.) the procedures for this are in the "Advertising P-Multicast Tree to VPLS/C-Multicast Binding" section 🫶

3.3. IP Multicast Group Membership Discovery 👀

setting up a Selective P-multicast tree for one or more IP multicast (C-S, C-G)s requires the ingress PE to learn which PEs have receivers in one or more of those (C-S, C-G)s. this is needed in the following cases:

• When aggregation is used (with either mLDP or P2MP RSVP-TE as the tunneling technology), OR
• When the tunneling technology is P2MP RSVP-TE
• If ingress replication is used and the ingress PE wants to send traffic for (C-S, C-G)s only to those PEs that are on the path to receivers for those (C-S, C-G)s 🎯

for more on aggregation, see the "Aggregation Considerations" section 📖

for discovering IP multicast group membership, this doc describes procedures that let an ingress PE turn on explicit tracking of IP multicast membership. so an ingress PE can request IP multicast membership from egress PEs for one or more C-multicast streams. these procedures are in the "Optimizing Multicast Distribution via Selective Trees" section 💖

these procedures apply when IGMP ([RFC2236] [RFC3376]) or MLD ([RFC2710] [RFC3810]) is used as the multicast signaling protocol between the VPLS CEs. they also apply when PIM ([RFC4601]), in either the Any-Source Multicast (ASM) or the Source-Specific Multicast (SSM) service model, is used as the multicast routing protocol between the VPLS CEs, AND PIM join suppression is disabled on all the CEs 🌈

BUT these procedures do NOT apply when PIM is used as the multicast routing protocol between the VPLS CEs and PIM join suppression is NOT disabled on all the CEs. that's because when PIM join suppression isn't disabled on all the CEs, PEs connected to those CEs can not rely on PIM to determine the IP multicast membership of the receivers behind those CEs 😭 procedures for this case are outside the scope of this document 🙅‍♀️

the leaves of the Selective P-multicast trees must also be able to discover the identifier of these trees. the procedures for this are in the "Advertising P-Multicast Tree to VPLS/C-Multicast Binding" section 🧚

3.4. Advertising P-Multicast Tree to VPLS/C-Multicast Binding

okay so this section is all about how the root of an Aggregate P-multicast tree tells its leaves which tree it's using and how to sort out the traffic when it arrives 📮✨ it does this with BGP VPLS Auto-Discovery (A-D) routes ([RFC4761] [RFC6074]) and the PMSI Tunnel attribute defined [RFC6514], and honestly it's giving very organized 💅

once an ingress PE decides to bind a bunch of VPLS instances or customer multicast groups to an Inclusive P-multicast tree or a Selective P-multicast tree, it has to tell the other PEs about it 🫶 that announcement is called "Inclusive P-multicast tree binding distribution" or "Selective P-multicast tree binding distribution," and it runs over BGP. the choice to bind things together is totally the ingress's call, and it's controlled by provisioning/configuration on that PE, so no one else gets a vote 🙈

for an Aggregated Inclusive P-multicast tree, the ingress PE MUST announce the binding of all the VPLS instances bound to that tree, and the other PEs that have those instances need to receive the announcement 🎀 the inner label the ingress assigns to each VPLS MUST be included if more than one VPLS is bound to the same P-multicast tree. the Inclusive P-multicast tree Identifier MUST be included too, no skipping 😭

for a Selective P-multicast tree, the announcement covers all the specific <C-S, C-G> entries bound to that tree, along with the Selective P-multicast tree Identifier 🦋 the inner label assigned for each <C-S, C-G> MUST be included if <C-S, C-G> entries from different VPLS instances are bound to the same P-multicast tree. the labels MUST be distinct on a per-VPLS basis and MAY be distinct per <C-S, C-G> entry, so there's some wiggle room there 👑 and the Selective P-multicast tree Identifier MUST be included.

---

3.5. Aggregation

so remember how this doc keeps talking about carrying the traffic of more than one VPLS on the same P-multicast tree? that's called aggregation 🧚

aggregation is the SP's secret weapon because it puts a bound on how much multicast forwarding and control plane state the P-routers have to hold 💜 let's call the number of VPLS instances squished onto one P-multicast tree the "Aggregation Factor." when Inclusive source P-multicast trees are used, the number of trees a PE is the root of is proportional to the number of VPLS instances on that PE divided by the Aggregation Factor ✨

so the state a P-router keeps is proportional to this (the math is lowkey beautiful 🌸):

        AveVPLS            NPE
        -------    X    --------
          Aggr          AvePTree

where:

• AveVPLS is the average number of VPLS instances on a PE
• Aggr is the Aggregation Factor
• NPE is the number of PEs
• AvePTree is the average number of P-multicast that transit a given P-router

and the payoff? the state does not grow linearly with the number of VPLS instances 🎉 iconic behaviour, honestly.

aggregation does come with a catch 👀 the egresses of the P-multicast tree need a way to demultiplex the multicast traffic they get over the tree, so upstream-assigned labels [RFC5331] MUST be assigned and distributed by the root of the aggregate P-multicast tree 🔥

also, aggregation procedures need two MPLS labels in the label stack. but this doesn't add any new MTU implications, because even VPLS multicast supported by ingress replication already needs two MPLS labels in the label stack 🫶 no drama there.

---

3.6. Inter-AS VPLS Multicast

this document defines four models of inter-AS (Autonomous System) VPLS service. they're called options (a), (b), (c), and (e) 🌈 options (a), (b), and (c) here are super similar to methods (a), (b), and (c) from the "Multi-AS VPLS" section of [RFC4761], which itself stretches the ideas of [RFC4364] over to inter-AS VPLS. so it's giving familiar vibes ✨

for option (a) and option (b), this document describes a model where inter-AS VPLS can be offered without needing a single P-multicast tree to span multiple ASes. there are two variants of that model, and they're covered in the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section 💖

option (c) works differently 🙈 for it, the doc describes a model where inter-AS VPLS is offered by requiring a single P-multicast tree to span multiple ASes. that's because, with option (c), the Autonomous System Border Routers (ASBRs) don't exchange BGP-VPLS Network Layer Reachability Information (NLRI) or A-D routes.

then there's option (e), which you can think of as a variant of option (a) 💅

for more on these inter-AS options, check the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section 🦋

---

4. Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding ✨

this section is the rulebook for intra-AS auto-discovery of VPLS membership, plus how the info needed to set up P-multicast Tunnels gets distributed 🎀

VPLS auto-discovery/binding has two parts: intra-AS and inter-AS. the first handles everything inside one AS, and the second handles things across multiple ASes. the inter-AS side is covered in the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section 🫶

VPLS auto-discovery using BGP, as described in [RFC4761] and [RFC6074], lets a PE learn which other PEs are in a given VPLS instance. a PE that belongs to a VPLS instance announces a BGP NLRI that identifies its Virtual Switch Instance (VSI) 👑 that NLRI is built from a <Route Distinguisher (RD), VPLS Edge Device Identifier (VE-ID)> tuple. the NLRI defined in [RFC4761] has the <RD, VE-ID> tuple plus label blocks for pseudowire (PW) signaling. in that case the VE-ID is a two-octet number, encoded in the VE-ID of the NLRI from [RFC4761]. the NLRI defined in [RFC6074] only has <RD, PE_addr>, and there the VE-ID is a four-octet number encoded in the PE_addr of that NLRI 🧚

the procedures for building Inclusive Intra-AS and Inter-AS trees, as this document specifies, only need the BGP A-D NLRI to carry the <RD, VE-ID>. so these procedures work for both BGP-VPLS and LDP-VPLS with BGP A-D 💖

now, the tea ☕ BGP A-D is an inherent feature of BGP-VPLS, but it is not an inherent feature of LDP-VPLS. some LDP-VPLS deployments and/or implementations need configuration so a PE in a particular VPLS can find the other PEs and swap PW labels using Forwarding Equivalence Class (FEC) 128 (PWid FEC) [RFC4447] 🙈 using BGP A-D for LDP-VPLS [RFC6074] to set up PWs automatically does require FEC 129 (Generalized PWid FEC) [RFC4447]. still, FEC 129 is not required to use this document's procedures for LDP-VPLS. an LDP-VPLS implementation that supports this document MUST support the BGP A-D procedures to set up P-multicast trees as described here, and it MAY support FEC 129 to automate the signaling of PWs. the vibes are "must-have vs. nice-to-have," bestie 🎀

---

4.1. Originating Intra-AS VPLS A-D Routes

so to join the VPLS auto-discovery/binding, a PE router with a given VSI of a given VPLS instance originates a BGP VPLS Intra-AS A-D route and advertises it in Multiprotocol (MP) IBGP 🦋 the route is built as described in [RFC4761] and [RFC6074], no new recipe needed ✨

the route carries a single Layer 2 Virtual Private Network (L2VPN) NLRI, with the RD set to the RD of the VSI and the VE-ID set to the VE-ID of the VSI. it also carries one or more Route Targets (RTs), as specified in [RFC4761] and [RFC6074] 💜

if an Inclusive P-multicast tree is used to instantiate the provider tunnel for VPLS multicast on the PE, the advertising PE MUST advertise the type and the identity of the P-multicast tree in the PMSI Tunnel attribute 🔥 that attribute is described in the "Inclusive Tree/Selective Tree Identifier" section, so go check it out 🫶

a PE that uses an Inclusive P-multicast tree to instantiate the provider tunnel MAY aggregate two or more VPLS instances present on the PE onto the same tree 🌸 now here's the tricky bit: if the PE decides to aggregate after it has already advertised the intra-AS VPLS A-D routes for those instances, then the aggregation requires the PE to re-advertise those routes. the re-advertised routes MUST be the same as the originals, except for the PMSI Tunnel attribute (the re-advertised route replaces the previously advertised one) 😭 if the PE hasn't previously advertised Intra-AS A-D routes for those VPLS instances, then aggregation requires the PE to advertise (new) Intra-AS A-D routes for them instead.

the PMSI Tunnel attribute in the newly advertised or re-advertised routes MUST carry the identity of the P-multicast tree that aggregates the VPLS instances, as well as an MPLS upstream-assigned label [RFC5331] 🧚 and each re-advertised or newly advertised route MUST have a label that is distinct within the scope of the PE that advertises the route. labels need their own personal space, periodt 💅

last thing: discovering PE capabilities in terms of which tunnel types they support is outside the scope of this document 🙈 within a given AS, PEs participating in a VPLS are expected to advertise tunnel bindings whose tunnel types are supported by all the other PEs participating in that VPLS and part of the same AS. basically, everyone should speak the same tunnel language 🌈✨

4.2. Receiving Intra-AS VPLS A-D Routes 🎀

okay so bestie, picture a PE getting a BGP Update that carries an Intra-AS A-D route. 💅 The PE only does the fancy stuff if all of these are true:

• (a) the route was originated by some other PE within the same AS as the local PE,
• (b) at least one of the RTs of the route matches one of the import RTs configured for a particular VSI on the local PE,
• (c) the BGP route selection determines that this is the best route with respect to the NLRI carried by the route, and
• (d) the route carries the PMSI Tunnel attribute.

If that's all true, the PE does the following ✨

• If the Tunnel Type in the PMSI Tunnel attribute is set to LDP P2MP LSP, the PE SHOULD join the P-multicast tree whose identity is carried in the PMSI Tunnel attribute. 🦋
• If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE P2MP LSP, the receiving PE has to establish the appropriate state to properly handle the traffic received over that LSP. The PE that originated the route MUST establish an RSVP-TE P2MP LSP with the local PE as a leaf. This LSP MAY have been established before the local PE receives the route. 🌸
• If the PMSI Tunnel attribute does not carry a label, then all packets that are received on the P-multicast tree, as identified by the PMSI Tunnel attribute, are forwarded using the VSIs that have at least one of their import RTs that matches one of the RTs of the received A-D route. 💜
• If the PMSI Tunnel attribute has the Tunnel Type set to LDP P2MP LSP or RSVP-TE P2MP LSP, and the attribute also carries an MPLS label, then the egress PE MUST treat this as an upstream-assigned label, and all packets that are received on the P-multicast tree, as identified by the PMSI Tunnel attribute, with that upstream label are forwarded using the VSIs that have at least one of their import RTs that matches one of the RTs of the received Intra-AS A-D route. 👑

Furthermore, if the local PE uses RSVP-TE P2MP LSP for sending (multicast) traffic, originated by VPLS sites connected to the PE, to the sites attached to other PEs, then the local PE MUST use the Originating Router's IP Address information carried in the Intra-AS A-D route to add the PE that originated the route as a leaf node to the LSP. This MUST be done irrespective of whether or not the received Intra-AS A-D route carries the PMSI Tunnel attribute. 🫶

---

5. Demultiplexing P-Multicast Tree Traffic ✨

Demultiplexing received VPLS traffic requires the receiving PE to determine the VPLS instance to which the packet belongs. The egress PE can then perform a VPLS lookup to further forward the packet. It also requires the egress PE to determine the identity of the ingress PE for MAC learning, as described in the "VPLS Data Packet Treatment" section. 🧚

5.1. One P-Multicast Tree - One VPLS Mapping 🍓

When a P-multicast tree is mapped to only one VPLS, determining the tree on which the packet is received is sufficient to determine the VPLS instance on which the packet is received. The tree is determined based on the tree encapsulation. If MPLS encapsulation is used, e.g., RSVP-TE P2MP LSPs, the outer MPLS label is used to determine the tree. Penultimate Hop Popping (PHP) MUST be disabled on the MPLS LSP (RSVP-TE P2MP LSP or mLDP P2MP LSP). 🙈

5.2. One P-Multicast Tree - Many VPLS Mapping 🌈

Traffic belonging to multiple VPLS instances can be carried over the same tree, so there's a real need to identify the VPLS that each packet belongs to. This is done by using an inner label that determines the VPLS for which the packet is intended. The ingress PE uses this label as the inner label while encapsulating a customer multicast data packet. Each of the egress PEs must be able to associate this inner label with the same VPLS and use it to demultiplex the traffic received over the Aggregate Inclusive tree or the Aggregate Selective tree. 💖

If traffic from multiple VPLS instances is carried on a single tree, upstream-assigned labels [RFC5331] MUST be used. Hence, the inner label is assigned by the ingress PE. When the egress PE receives a packet over an Aggregate tree, the outer encapsulation (in the case of MPLS P2MP LSPs, the outer MPLS label) specifies the label space to perform the inner-label lookup. The same label space MUST be used by the egress PE for all P-multicast trees that have the same root [RFC5331]. 🔥

If the tree uses MPLS encapsulation, as in RSVP-TE P2MP LSPs, the outer MPLS label and, optionally, the incoming interface provide the label space of the label beneath it. This assumes that PHP is disabled. The egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for that tree once it is known to the egress PE that the tree is bound to one or more VPLS instances. Once the label representing the tree is popped off the MPLS label stack, the next label is the demultiplexing information that allows the proper VPLS instance to be determined. 🦋

The ingress PE informs the egress PEs about the inner label as part of the tree binding procedures described in the "BGP Extensions" section. 🫶

6. Establishing P-Multicast Trees 👑

This document supports only P2MP P-multicast trees wherein it is possible for egress PEs to identify the ingress PE to perform MAC learning. Specific procedures are identified only for RSVP-TE P2MP LSPs and mLDP P2MP LSPs. An implementation that supports this document MUST support RSVP-TE P2MP LSPs and mLDP P2MP LSPs. 🎀

6.1. Common Procedures 💅

The following procedures apply to both RSVP-TE P2MP and mLDP P2MP LSPs.

Demultiplexing the C-multicast data packets at the egress PE requires that the PE must be able to determine the P2MP LSP on which the packets are received. This enables the egress PE to determine the VPLS instances to which the packet belongs. To achieve this, the LSP MUST be signaled with PHP off and a non-special purpose MPLS label off as described in the "Demultiplexing P-Multicast Tree Traffic" section. In other words, an egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for a P2MP LSP that is carrying traffic for one or more VPLS instances. This is because the egress PE needs to rely on the MPLS label, that it advertises to its upstream neighbor, to determine the P2MP LSP on which a C-multicast data packet is received. 🌸

The egress PE also needs to identify the ingress PE to perform MAC learning. When P2MP LSPs are used as P2MP trees, determining the P2MP LSP on which the packets are received is sufficient to determine the ingress PE. This is because the ingress PE is the root of the P2MP LSP. 🧚

The egress PE relies on receiving the PMSI Tunnel attribute in BGP to determine the VPLS instance to P2MP LSP mapping. ✨

6.2. RSVP-TE P2MP LSPs 🍓

This section describes procedures that are specific to the usage of RSVP-TE P2MP LSPs for instantiating a P-multicast tree. Procedures in [RFC4875] are used to signal the P2MP LSP. The LSP is signaled as the root of the P2MP LSP discovers the leaves. The egress PEs are discovered using the procedures described in the "Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding" section. Aggregation, as described in this document, is supported. 🌈

6.2.1. P2MP TE LSP - VPLS Mapping 💖

P2MP TE LSP to VPLS mapping is learned at the egress PEs using BGP-based advertisements of the P2MP TE LSP - VPLS mapping. They require that the root of the tree include in the BGP advertisements the P2MP TE LSP identifier as the P-multicast tree identifier. This P-multicast tree identifier contains the following information elements:

• The type of the tunnel is set to RSVP-TE P2MP LSP
• RSVP-TE P2MP LSP's SESSION Object

See the "Inclusive Tree/Selective Tree Identifier" section for more details on how this tree identifier is carried in BGP advertisements. 🔥

Once the egress PE receives the P2MP TE LSP to VPLS mapping:

• If the egress PE already has RSVP-TE state for the P2MP TE LSP, it MUST begin to assign an MPLS label from the non-special purpose label range, for the P2MP TE LSP and signal this to the previous hop of the P2MP TE LSP. Further, it MUST create forwarding state to forward packets received on the P2MP LSP. 🦋
• If the egress PE does not have RSVP-TE state for the P2MP TE LSP, it MUST retain this mapping. Subsequently, when the egress PE receives the RSVP-TE P2MP signaling message, it creates the RSVP-TE P2MP LSP state. It MUST then assign an MPLS label from the non-reserved label range, for the P2MP TE LSP, and signal this to the previous hop of the P2MP TE LSP. 🫶

Note that if the signaling to set up an RSVP-TE P2MP LSP is completed before a given egress PE learns, via a PMSI Tunnel attribute, of the VPLS or set of VPLS instances to which the LSP is bound, the PE MUST discard any traffic received on that LSP until the binding is received. In order for the egress PE to be able to discard such traffic, it needs to know that the LSP is associated with one or more VPLS instances and that the VPLS A-D route that binds the LSP to a VPLS has not yet been received. This is provided by extending [RFC4875] with [RFC6511]. 🙈

6.3. Receiver-Initiated P2MP LSP 👑

Receiver-initiated P2MP LSPs can also be used. The mLDP procedures ([RFC6388]) MUST be used to signal such LSPs. The LSP is signaled once the leaves receive the LDP FEC for the tree from the root, as described in the "Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding" section. When aggregation is used, an ingress PE is required to discover the egress PEs (see the "Aggregation Considerations" section for the rationale), and this is achieved using the procedures in the "Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding" section. 🎀

6.3.1. P2MP LSP - VPLS Mapping 🌸

P2MP LSP to VPLS mapping is learned at the egress PEs using BGP-based advertisements of the P2MP LSP - VPLS mapping. They require that the root of the tree include in the BGP advertisements the P2MP LSP identifier as the P-multicast tree identifier. This P-multicast tree identifier contains the following information elements:

• The type of the tunnel is set to LDP P2MP LSP
• LDP P2MP FEC that includes an identifier generated by the root.

See the "Inclusive Tree/Selective Tree Identifier" section for more details on how this tree identifier is carried in BGP advertisements. 🧚

Each egress PE SHOULD "join" the P2MP MPLS tree by sending LDP label mapping messages for the LDP P2MP FEC, that was learned in the BGP advertisement, using procedures described in [RFC6388]. 🍓

6.4. Encapsulation of Aggregate P-multicast Trees 💜

An Aggregate Inclusive P-multicast tree or an Aggregate Selective P-multicast tree MUST use MPLS encapsulation, as described in [RFC5332]. 🌈

7. Inter-AS Inclusive P-Multicast Tree A-D/Binding ✨

okay so, as we said earlier, this doc lays out four models of inter-AS VPLS service: option (a), (b), (c), and (e) 🎀 this section is where the procedures for supporting them live 💅

for options (a), (b), and (e), this section describes a model where inter-AS VPLS can be offered without needing one single P-multicast tree to span multiple ASes 🦋 that means each AS can potentially use its own P-tunneling tech, which is so flexible it's giving 😭 there are two variants of this model. the first one requires MAC lookup on the ASBRs and applies to option (a) and (e). the second one does not require MAC lookup on the ASBRs, and instead it builds segmented Inter-AS Inclusive or Selective trees. this one only applies to option (b) 🌸

for option (c), this section describes a model where Inter-AS VPLS service is offered by requiring a single Inclusive P-multicast tree to span multiple ASes. this is called a "non-segmented P-multicast tree" 🧚 why? because with option (c), the ASBRs don't exchange BGP-VPLS NLRIs or VPLS A-D routes, so the whole thing just goes end to end. Inter-AS Selective trees for option (c) may be segmented or non-segmented, your choice ✨

an implementation MUST support options (a), (b), and (c), and MAY support option (e). when there are multiple ways to implement one of these options, this section specifies which one is mandatory 👑

---

7.1. VSIs on the ASBRs

when VSIs are configured on ASBRs, the ASBRs MUST perform a MAC lookup, in addition to any MPLS lookups, to determine the forwarding decision on a VPLS packet 🔥 the P-multicast trees are confined to an AS. an ASBR that receives a VPLS packet from another ASBR is required to do a MAC lookup to figure out how to forward it. so an ASBR is required to keep a VSI for the VPLS instance, and it MUST be configured with its own VE-ID for that instance 🫶 and the BGP VPLS A-D routes generated by PEs in an AS MUST NOT be propagated outside the AS. no leaking, periodt 🙅‍♀️

7.1.1. Option (a): VSIs on the ASBRs

in option (a), an ASBR acts as a PE for the VPLSs that span its own AS and an AS it's connected to 💖 the local ASBR sees the ASBR in the neighboring AS as a CE connected by a link with separate VLAN sub-interfaces for each such VPLS. flip it around and the ASBR in the neighboring AS is a PE for that VPLS from its side, and it sees the local ASBR as a CE. two perspectives, one link, very main character 🌈

the local ASBR uses a combination of the incoming link and a particular VLAN sub-interface on that link to figure out the VSI for the packets it gets from the ASBR in the neighboring AS 🍓

in option (a), the ASBRs do not exchange VPLS A-D routes 🙈

an implementation MUST support option (a) 💅

7.1.2. Option (e): VSIs on the ASBRs

the VSIs on the ASBRs scheme can be used so that the interconnect between the ASBRs is a PW and MPLS encapsulation is used between the ASBRs 🦋 an ASBR in one AS works out the VSI for packets from an adjoining ASBR in another AS based on the incoming MPLS PW label. this is referred to as "option (e)" ✨ the only VPLS A-D routes that get propagated outside the AS are the ones originated by ASBRs. this MPLS PW connects the VSIs on the ASBRs and MUST be signaled using the procedures defined in [RFC4761] or [RFC4762] 💜

the P-multicast trees for a VPLS are confined to each AS, and the VPLS auto-discovery/binding MUST follow the intra-AS procedures described in the "Demultiplexing P-Multicast Tree Traffic" section 🎀

an implementation MAY support option (e) 🌸

---

7.2. Option (b) - Segmented Inter-AS Trees

in this model, an inter-AS P-multicast tree, rooted at a particular PE for a particular VPLS instance, is made up of a bunch of "segments", one per AS, which get stitched together at ASBRs 🧩 these are known as "segmented inter-AS trees". each segment can use a different multicast transport technology, so mix and match, iykyk 🌈 in this model, an ASBR is not required to keep a VSI for the VPLS instance, and it is not required to do a MAC lookup to forward the VPLS packet. this means an ASBR doesn't need a VE-ID for the VPLS either 🙌

an implementation MUST support option (b) using this model 👑

the construction of segmented inter-AS trees requires the BGP-VPLS A-D NLRI described in [RFC4761] and [RFC6074] 💖 a BGP VPLS A-D route for an <RD, VE-ID> tuple that's advertised outside the AS, to which the originating PE belongs, is referred to as an "Inter-AS VPLS A-D route". (even though this route is originated by a PE as an intra-AS route, it's called an "inter-AS route outside the AS") 🫠

on top of that, segmented inter-AS trees need support for the PMSI Tunnel attribute described in the "Inclusive Tree/Selective Tree Identifier" section. they also need extra BGP procedures to signal leaf A-D routes between ASBRs, which we'll get into in the next sections 🦋

7.2.1. Segmented Inter-AS Trees VPLS Inter-AS A-D/Binding

this section specifies the procedures for inter-AS VPLS A-D/binding for segmented Inter-AS trees ✨

an ASBR must be configured to support a particular VPLS as follows:

• an ASBR MUST be configured with a set of (import) RTs that specify the set of VPLS instances the ASBR supports. these RTs control which BGP VPLS auto-discovery routes the ASBR accepts 🎀 instead of being configured, the ASBR MAY obtain this set of (import) RTs by using Route Target Constrain [RFC4684]. no manual typing needed, bestie 💅
• the ASBR MUST be configured with the tunnel types for the intra-AS segments of the VPLS instances it supports, plus (depending on the tunnel type) the info needed to create the PMSI Tunnel attribute for those tunnel types 🍓 instead of being configured, the ASBR MAY derive the tunnel types from the Intra-AS A-D routes it receives from the PEs in its own AS 🧚

if an ASBR is configured to support a particular VPLS instance, the ASBR MUST participate in the intra-AS VPLS auto-discovery/binding procedures for that VPLS instance within the ASBR's own AS, as defined in this document 🌈

and on top of all that, the ASBR performs the procedures in the "Propagating BGP VPLS A-D Routes to Other ASes: Overview" section 💅

7.2.2. Propagating BGP VPLS A-D Routes to Other ASes: Overview

a BGP VPLS A-D route for a given VPLS, originated by a PE within a given AS, gets propagated via BGP to other ASes 📣 the precise rules for distributing and processing the Inter-AS A-D routes are in the later sections 🙌

okay picture this 🤩 suppose an ASBR "A" receives and installs a BGP VPLS A-D route for VPLS "X" and VE-ID "V" that originated at a particular PE "PE1" in the same AS as A. the BGP next hop of that received route becomes A's "upstream neighbor" on a multicast distribution tree for (X, V) rooted at PE1. and when A re-advertises this route to ASBRs in A's neighboring ASes, from their point of view, A becomes their "upstream neighbor" on the multicast distribution tree for (X, V) rooted at PE1 🦋

once the BGP VPLS A-D routes have been distributed to all the necessary ASes, they define a "reverse path" from any AS that supports VPLS X and VE ID V back to PE1 🔥 for instance, if AS2 supports VPLS X, then there will be a reverse path for VPLS X and VE ID V from AS2 to AS1. this path is a sequence of ASBRs, the first of which is in AS2 and the last of which is in AS1. each ASBR in the sequence is the BGP next hop of the previous ASBR in the sequence 🧵

this reverse path info can be used to build a unidirectional multicast distribution tree for VPLS X and VE-ID V, containing all the ASes that support X, with PE1 at the root 🌸 we call that an "inter-AS tree" 👑 multicast data that starts in VPLS sites for VPLS X connected to PE1 travels downstream along the tree rooted at PE1 ✨

the path along an inter-AS tree is a sequence of ASBRs, and we still need to figure out how the multicast data gets from a given ASBR to the set of ASBRs immediately downstream of it along 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" 🫶

for a given inter-AS tree and a given AS, there MUST be only one ASBR within that AS that accepts traffic flowing on that tree. further, for a given inter-AS tree and a given AS, there MUST be only one ASBR in that AS that sends the traffic flowing on that tree to a particular adjacent AS. the precise rules for making that happen are in the subsequent sections 🔥

an ASBR starts creating an intra-AS segment when it receives an Inter-AS A-D route from an External BGP (EBGP) neighbor 🚀 creation of the segment is completed once that route gets distributed via IBGP within the ASBR's own AS 💖

for a given inter-AS tunnel, each of its intra-AS segments could be constructed by its own independent mechanism 🌈 and by using upstream-assigned labels within a given AS, multiple intra-AS segments of different inter-AS tunnels, of either the same or different VPLS instances, may share the same P-multicast tree 🦋

now the tricky bit 🙈 if the P-multicast tree instantiating a particular segment of an inter-AS tunnel is created by a multicast control protocol that uses receiver-initiated joins (e.g, mLDP), and this P-multicast tree does not aggregate multiple segments, then all the info needed to create that segment will be in the Inter-AS A-D routes the ASBR received from the neighboring ASBR. but if the P-multicast tree instantiating the segment is created by a protocol that does not use receiver-initiated joins (e.g., RSVP-TE, ingress unicast replication), or if this P-multicast tree aggregates multiple segments (no matter which multicast control protocol creates the tree), then the ASBR needs to learn the leaves of the segment 🧠 those leaves are learned from A-D routes received from other PEs in the AS, for the same VPLS the segment belongs to 🫠

the following sections specify procedures for propagating Inter-AS A-D routes across ASes to construct inter-AS segmented trees 🎀

7.2.2.1. Propagating Intra-AS VPLS A-D Routes in EBGP

for a given VPLS configured on an ASBR, when the ASBR receives Intra-AS A-D routes originated by PEs in its own AS, the ASBR MUST propagate each of these routes in EBGP 📣 this MUST be done for each of the VPLS instances configured on the ASBR 💅 each of these routes is built like this:

• the route carries a single BGP VPLS A-D NLRI, with the RD and VE-ID being the same as the NLRI in the received Intra-AS A-D route 🍓
• the Next Hop field of the MP_REACH_NLRI attribute is set to a routable IP address of the ASBR 🌸
• the route carries the PMSI Tunnel attribute, with the Tunnel Type set to Ingress Replication, and the attribute carries no MPLS labels 🧚
• the route MUST carry the export RT used by the VPLS 🫶

7.2.2.2. Inter-AS A-D Route Received via EBGP 🦋

okay so picture this: an ASBR gets a BGP Update from one of its EBGP neighbors, and it's carrying an Inter-AS A-D route. 👀 The ASBR only re-advertises that route inside its own AS if two things are true. First, at least one of the RTs in the message has to match one of the import RTs configured on the ASBR. Second, the ASBR has to decide the route is the best route to the destination in the NLRI. If both are true, it passes the route along to the other PEs and ASBRs in its AS. 💅 The best route selection has to make sure every ASBR in the AS picks the same best route for the same destination, and that's specified in [RFC4761] and clarified in [MULTI-HOMING]. 🌸 The point is that if several ASBRs in one AS get the same Inter-AS A-D route from their EBGP neighbors, only one of them sends it into IBGP. That one becomes the root of the intra-AS segment of the inter-AS tree, and it's the only ASBR allowed to accept traffic into the AS from that tree. Main character energy, one ASBR, no drama. 👑

When the ASBR re-advertises an Inter-AS 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, bestie. 🫶

Now the PMSI Tunnel attribute on the re-advertised route depends on what kind of P-multicast tunnel the ASBR uses to build 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 NOT carry the PMSI Tunnel attribute. 💀
• If the ASBR uses a P-multicast tree for that intra-AS segment, the PMSI Tunnel attribute MUST contain the identity of the tree used to build the segment. The ASBR can make up that identity before the segment is actually instantiated, which is a neat little trick. ✨ If the ASBR needs to know the leaves of the tree to build the segment, it gets that info from the A-D routes it received from other PEs and ASBRs in its own AS. 🧚
• An ASBR that uses a P-multicast tree for the intra-AS segment MAY aggregate two or more VPLS instances on the ASBR onto the same tree. 🍓 If the ASBR already advertises Inter-AS A-D routes for those VPLS instances, aggregating them means the ASBR has to re-advertise those routes. The re-advertised routes MUST be the same as the originals, except for the PMSI Tunnel attribute. If the ASBR hasn't advertised Inter-AS A-D routes for those VPLS instances before, then aggregating means it has to advertise (new) Inter-AS A-D routes for them instead. Either way, the PMSI Tunnel attribute in the newly advertised or re-advertised routes MUST carry the identity of the P-multicast tree that aggregates the VPLS instances, plus an MPLS upstream-assigned label [RFC5331]. Each newly advertised or re-advertised route MUST have a label that is distinct within the scope of the ASBR. Labels are not allowed to be twins here, periodt. 🙅‍♀️

On top of all that, the ASBR MUST send a BGP Update message to the EBGP neighbor it got the Inter-AS A-D route from, and that message carries a leaf A-D route. The exact encoding is in the "BGP Extensions" section. 🦋 This leaf route has the following info:

• The route carries a single NLRI, and its Route Key field is set to the <RD, VE-ID> tuple of the BGP VPLS A-D NLRI from the Inter-AS A-D route that came in from the EBGP neighbor. The NLRI also carries the IP address of the ASBR, and that address MUST be a routable IP address. 🌈
• The leaf A-D 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 advertising router. The PMSI Tunnel attribute MUST also carry a downstream-assigned MPLS label, which the advertising router uses to demultiplex the VPLS traffic it gets over a unicast tunnel. 🔥
• The Next Hop field of the route's MP_REACH_NLRI attribute SHOULD be set to the same IP address as the one in the Originating Router's IP Address field of the route. 💖
• To keep the distribution scope of this route constrained, the route MUST carry the NO_ADVERTISE BGP Community ([RFC1997]). 🤫
• The ASBR builds an IP-address-specific RT by putting the IP address from the Next Hop field of the received Inter-AS VPLS A-D route into the Global Administrator field of the community, with the Local Administrator field of that community set to 0. Then it sets the Extended Communities attribute of the leaf A-D route to that community. Here's the fun part: this RT is the same as the ASBR Import RT of the EBGP neighbor the ASBR got the Inter-AS VPLS A-D route from. 🎀

---

7.2.2.3. Leaf A-D Route Received via EBGP 🌸

when an ASBR gets a leaf A-D route over EBGP, it only accepts it if (a) at least one of the RTs in the message matches one of the import RTs configured on the ASBR and (b) the ASBR decides the route is the best route to the destination in the NLRI. 🙈 No vibes-only acceptance here.

If the ASBR does accept the leaf A-D route, it goes looking for an existing A-D route whose BGP-VPLS A-D NLRI has the same value as the <RD, VE-ID> field of the leaf A-D route it just accepted. 🔍 If it finds one, the MPLS label in the leaf route's PMSI Tunnel attribute gets used to stitch a one hop ASBR-ASBR LSP onto the tail of the intra-AS tunnel segment linked to that A-D route. It's like tying two friendship bracelets together. 🦋💜

---

7.2.2.4. Inter-AS A-D Route Received via IBGP 💅

In this section, we use the term "PE/ASBR router" to mean either a PE or an ASBR router. Easy. ✨

Quick heads up: a given Inter-AS A-D route is advertised within a given AS by only one ASBR, as described above. 🧚

When a PE/ASBR router gets a BGP Update message from one of its IBGP neighbors, and that message carries an Inter-AS A-D route, the PE/ASBR does the following operations, as long as (a) at least one of the RTs in the message matches one of the import RTs configured on the PE/ASBR and (b) the PE/ASBR decides the route is the best route to the destination in the NLRI. 👑 The best route determination is as described in [RFC4761] and clarified in [MULTI-HOMING].

• If the router is an ASBR, the ASBR propagates the route to its EBGP neighbors. When it does, 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 A-D route carries the PMSI Tunnel attribute with the Tunnel Type set to LDP P2MP LSP, the PE/ASBR SHOULD join the P-multicast tree whose identity is in the PMSI Tunnel attribute. 🌈
• If the received Inter-AS 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 set up before the local PE/ASBR got the route, or it MAY be set up after the local PE gets the route. Timing is flexible, babe. ⭐

If the received Inter-AS A-D route carries the PMSI Tunnel attribute with the Tunnel Type set to LDP P2MP LSP or RSVP-TE P2MP LSP, but the attribute doesn't carry a label, then the P-multicast tree named in the PMSI Tunnel attribute is an intra-AS LSP segment. That segment is part of the inter-AS tunnel for the <VPLS, VE-ID> advertised by the Inter-AS A-D route, and it's rooted at the PE that originated the A-D route. 🌸 If the PMSI Tunnel attribute carries an (upstream-assigned) label, then the tree and 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 VPLS, packets received over the intra-AS segment MUST be forwarded to those local receivers using the local VSI. Not optional, no cap. 💖

---

7.3. Option (c): Non-segmented Tunnels ✨

In this model, there's a multi-hop EBGP peering between the PEs (or BGP Route Reflector) in one AS and the PEs (or BGP Route Reflector) in another AS. 🦋 The PEs swap BGP-VPLS NLRI or BGP-VPLS A-D NLRI, along with the PMSI Tunnel attribute, just like in the intra-AS case described in the "Demultiplexing P-Multicast Tree Traffic" section. 💅

The PEs in different ASes use a non-segmented inter-AS P2MP tunnel for VPLS multicast. A non-segmented inter-AS tunnel is one single tunnel that spans AS boundaries. 🌈 The tunnel technology can't change from one point in the tunnel to the next, so every AS the tunnel passes through has to support that technology. Basically, AS boundaries don't matter at all to a non-segmented inter-AS P2MP tunnel. 🫶

This model needs no VPLS A-D routes in the control plane, and no VPLS MAC address learning in the data plane on the ASBRs. 🙌 The ASBRs only have to take part in setting up the non-segmented P2MP tunnel in the control plane, and they do MPLS label forwarding in the data plane. Low-key chill for the ASBRs. 🍓

When the tunneling technology is P2MP LSP signaled with mLDP, and one does not use [RFC6512], the setup of non-segmented inter-AS P2MP tunnels requires the P-routers in one AS to have IP reachability to the loopback addresses of the PE routers in another AS. That is, the reachability to the loopback addresses of PE routers in one AS MUST be present in the IGP in another AS. 🚨 Don't skip this, it's giving "must-read."

The data forwarding in this model is the same as in the intra-AS case described in the "Demultiplexing P-Multicast Tree Traffic" section. 🎀

An implementation MUST support this model. 👑

8. Optimizing Multicast Distribution via Selective Trees ✨

okay so bestie, picture this 🌸 whenever a multicast stream is riding an Inclusive P-multicast tree, the data is probably getting sent to PEs that don't actually need it, because the sites behind those PEs might have zero receivers for that stream 😭. If a stream has a lot of traffic, it can be worth moving it onto a Selective P-multicast tree. That tree has only the PEs whose sites have receivers at its leaves (or, at the very least, it has way fewer PEs with empty sites hanging off it than an Inclusive tree would) 💅

A PE connected to the source of a multicast stream might be doing explicit tracking, which means it knows which PEs have receivers for the stream 👀 The "Receiving S-PMSI A-D Routes by PEs" section describes the procedures that make explicit tracking possible. If the PE is doing that, Selective P-multicast trees can get triggered by other criteria too 🦋 For example, there could be a "pseudo-wasted bandwidth" criterion: you'd switch to a Selective tree if the bandwidth multiplied by the number of "uninterested" PEs (PEs that receive the stream but have no receivers) goes over a set threshold. The logic is pretty iconic. (a) Lots of sparsely subscribed low-bandwidth groups can waste a huge amount of bandwidth in total, and (b) moving a high-bandwidth group to a Selective tree makes no sense if every single PE has receivers for it 🙈

Switching a (C-S, C-G) stream to a Selective P-multicast tree may require the root of the tree to figure out which egress PEs need the (C-S, C-G) traffic 🧚 This is true in the following cases:

• If the tunnel is a P2MP tree, like an RSVP-TE P2MP Tunnel, the PE needs to know the leaves of the tree before it can set up the Selective tree 🎀
• If a PE decides to send traffic for multicast streams from different VPLS instances over one P-multicast Selective tree, that tree is called an "Aggregate tree with a selective mapping". Setting up that kind of Aggregate tree means the ingress PE has to know every other PE that has receivers for the multicast groups mapped onto the tree (check the "Aggregation Considerations" section for the reasoning) 💜
• If ingress replication is in use and the ingress PE wants to send (C-S, C-G) traffic only to those PEs that sit on the path to receivers of that (C-S, C-G) 🌈

To discover IP multicast group membership in the cases above, this document describes procedures that let an ingress PE turn on explicit tracking 🫶 So an ingress PE can ask the egress PEs for the IP multicast membership of one or more C-multicast streams. You can find those procedures in the "Receiving S-PMSI A-D Routes by PEs" section.

The root of the Selective P-multicast tree MAY decide to start explicit tracking of the IP multicast stream only after it has decided to move the stream to a Selective tree, or it MAY have been doing explicit tracking all along 🍓 This document also covers explicit tracking for a wildcard source and/or group in the "Receiving S-PMSI A-D Routes by PEs" section. That's what enables a Selective P-multicast tree only mode, where IP multicast streams are always carried on a Selective P-multicast tree ⭐ In the Selective P-multicast tree descriptions, the notation C-S means either a specific source address or a wildcard. Similarly, C-G means either a specific group address or a wildcard.

The PE at the root of the tree MUST signal to the leaves of the tree that the (C-S, C-G) stream is now bound to the Selective tree 💖 Fun fact, the PE can create the identity of the P-multicast tree before the tunnel is actually instantiated 🦋

If the Selective tree is instantiated by an RSVP-TE P2MP LSP, the PE at the root of the tree MUST establish the P2MP RSVP-TE LSP to the leaves 🔥 That LSP MAY have been set up before the leaves receive the Selective tree binding, or it MAY be set up after the leaves receive the binding. A leaf MUST NOT switch to the Selective tree until it has received the binding AND the RSVP-TE P2MP LSP is set up to that leaf 👑

8.1. Protocol for Switching to Selective Trees

Selective trees give a PE the ability to create separate P-multicast trees for certain (C-S, C-G) streams 🎀 The source PE (the one that originates the Selective tree) and the egress PEs MUST use the Selective tree for the (C-S, C-G) streams mapped to it. Sometimes that means the source and egress PEs have to switch over from an Inclusive tree to the Selective tree, if they were already using an Inclusive tree for those streams 💅

Once a source PE decides to set up a Selective tree, it MUST announce the mapping of the (C-S, C-G) streams (which may be in different VPLS instances) that are mapped to the tree to the other PEs using BGP 📣 After the egress PEs get that announcement, they set up their forwarding path to receive traffic on the Selective tree, but only if they have one or more receivers interested in the (C-S, C-G) streams mapped to the tree 🧚 Setting up the forwarding path means setting up the demultiplexing forwarding entries based on the top MPLS label (if there is no inner label) or the inner label (if one is present), as described in the "Establishing P-Multicast Trees" section.

When the P2MP LSP is established using mLDP, the egress PEs MAY perform this switch to the Selective tree as soon as they get the announcement from the ingress PE, or they MAY wait for a preconfigured timer to do it after receiving the announcement 🌸

When the P2MP LSP protocol is P2MP RSVP-TE, an egress PE MUST perform this switch to the Selective tree only after the announcement from the ingress PE is received AND the RSVP-TE P2MP LSP has been set up to the egress PE 🫶 The switch MAY be done after waiting for a preconfigured timer once those two steps are done.

A source PE MUST use the following approach to decide when to start transmitting data on the Selective tree, if it is currently using an Inclusive tree 🦋 After it announces the (C-S, C-G) stream mapping to a Selective tree, the source PE MUST wait for a "switchover" delay before sending the (C-S, C-G) stream on the Selective tree. It is RECOMMENDED to make this delay configurable ⏳ Once the "switchover" delay has passed, the source PE MUST send the (C-S, C-G) stream on the Selective tree. In no case is any (C-S, C-G) packet sent on both Selective and Inclusive trees 🚫

When a (C-S, C-G) stream moves from an Inclusive tree to a Selective tree, the whole point of the switchover timer is to minimize packet loss WITHOUT introducing packet duplication. The catch is that jitter may show up because the transit delays on the Inclusive and Selective trees can be different 😭

For the best effect, the switchover timer should be set to a value that is "just long enough" (a) for all the PEs to learn about the new binding of (C-S, C-G) to a Selective tree, and (b) for the PEs to build the P-tunnel associated with the Selective tree, if it doesn't already exist 💜

8.2. Advertising (C-S, C-G) Binding to a Selective Tree ✨

okay so the ingress PE has to tell every PE on the path to receivers which (C-S, C-G) is bound to which Selective tree 🌸. It does this with BGP, sending an update for the MCAST-VPLS address family 💅 that carries what we call an "S-PMSI A-D route". The NLRI format is described in the "Inclusive Tree/Selective Tree Identifier" section. The NLRI MUST be built like this:

• The Route Distinguisher (RD) MUST be set to the RD configured locally for the VPLS. This is required to uniquely identify the <C-S, C-G>, because addresses can overlap between different VPLS instances 🔥. It MUST be the same RD value used in the VPLS auto-discovery process ✨.
• 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. If the source address is a wildcard, the source address is set to 0 🦋.
• 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. If the group address is a wildcard, the group address is set to 0 🌈.
• The Originating Router's IP Address field MUST be set to the IP address that the (local) PE places in the BGP Next Hop of the BGP-VPLS A-D routes. Note that the <RD, Originating Router's IP Address> tuple uniquely identifies a given VPLS instance on a PE 🧚.

The PE builds the rest of the Selective A-D route as follows.

Depending on the type of P-multicast tree used for the P-tunnel, the PMSI Tunnel attribute of the S-PMSI A-D route is constructed like so:

• The PMSI Tunnel attribute MUST contain the identity of the P-multicast tree. (The PE could create the identity of the tree before the tree is actually instantiated 🍓.)
• 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 this information from the leaf A-D routes received from other PEs/ASBRs within 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. This enables explicit tracking for the multicast stream(s) advertised by the S-PMSI A-D route 🔍.
• 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 RT, 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 described in the "Receiving S-PMSI A-D Routes by PEs" section 👑.)

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

If the PE supports Route Target Constrain [RFC4684], the PE SHOULD advertise this import RT within its own AS using Route Target Constrain. To constrain distribution of the Route Target Constrain routes to the AS of the advertising PE, these routes 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 VPLS instances, then all these routes MUST carry an MPLS upstream-assigned label [RFC5331]. If all these aggregated S-PMSIs belong to the same VPLS, then the routes MAY carry an MPLS upstream-assigned label [RFC5331]. The labels MUST be distinct on a per-VPLS-instance basis, and they MAY be distinct on a per-route basis 🎀.

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

By default, the set of RTs carried by the route MUST be the same as the RTs carried in the BGP-VPLS A-D route originated from the VSI. The default could be modified via configuration ⭐.

---

8.3. Receiving S-PMSI A-D Routes by PEs 🦋

Consider a PE that receives an S-PMSI A-D route. If one or more of the VSIs on the PE have import RTs that contain one or more of the RTs carried by the received S-PMSI A-D route, then for each such VSI, the PE performs the following 👀.

Procedures for receiving an S-PMSI A-D route by a PE (both within and outside of the AS of the PE that originates the route) are the same as specified in the "Inter-AS A-D Route Received via IBGP" section. The differences are these: (a) instead of Inter-AS A-D routes, the procedures apply to S-PMSI A-D routes; (b) the rules for determining whether the received S-PMSI A-D route is the best route to the destination carried in the NLRI of the route are the same as BGP path selection rules and may be modified by policy; and (c) a PE performs the procedures specified in that section only if, in addition to the criteria specified in that section, the following is true 💖:

• If, as a result of multicast state snooping on the PE-CE interfaces, the PE has snooped state for at least one multicast join that matches the multicast source and group advertised in the S-PMSI A-D route. Further, the oifs (outgoing interfaces) for this state contain one or more interfaces to the locally attached CEs. When the multicast signaling protocol among the CEs is IGMP, then snooping and associated procedures are defined in [RFC4541]. The snooped state is determined using these procedures. When the multicast signaling protocol among the CEs is PIM, the procedures in [RFC4541] are not sufficient to determine the snooped state. The additional details required to determine the snooped state when CE-CE protocol is PIM are for further study. When such procedures are defined, it is expected that the procedures in this section will apply to the snooped state created as a result of PIM as PE-CE protocol 🧐.

The snooped state is said to "match" the S-PMSI A-D route if any of the following is true 🔎:

• The S-PMSI A-D route carries (C-S, C-G) and the snooped state is for (C-S, C-G) or for (C-*, C-G), OR
• The S-PMSI A-D route carries (C-, C-G) and (a) the snooped state is for (C-, C-G) OR (b) the snooped state is for at least one multicast join with the multicast group address equal to C-G and there doesn't exist another S-PMSI A-D route that carries (C-S, C-G) where C-S is the source address of the snooped state, OR
• The S-PMSI A-D route carries (C-S, C-*) and (a) the snooped state is for at least one multicast join with the multicast source address equal to C-S, and (b) there doesn't exist another S-PMSI A-D route that carries (C-S, C-G) where C-G is the group address of the snooped state, OR
• The S-PMSI A-D route carries (C-, C-) and there is no other S-PMSI A-D route that matches the snooped state as per the above conditions 🌈.

Note: if the above conditions are true, and 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. It is constructed as follows 🛠️:

• The route carries a single MCAST-VPLS NLRI with the Route Key field set to the MCAST-VPLS NLRI of the received S-PMSI A-D route.
• The Originating Router's IP Address is set to the IP address of the PE (this MUST be a routable IP address).
• The PE constructs an IP-address-specific RT by placing the IP address carried in the Next Hop field of the received S-PMSI A-D route in the Global Administrator field of the Community, with the Local Administrator field of this Community set to 0. It then sets the Extended Communities attribute of the leaf A-D route to that Community.
• 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], except for the inter-AS scenario with option (c) 🔒.

Once the leaf A-D route is constructed, the PE advertises this route into IBGP 📣.

In addition to the procedures specified in the "Inter-AS A-D Route Received via IBGP" section, the PE MUST set up its forwarding path to receive traffic, for each multicast stream in the matching snooped state, from the tunnel advertised by the S-PMSI A-D route (the PE MUST switch to the Selective tree) 🚀.

When a new snooped state is created by a PE, then the PE MUST first determine whether there is an S-PMSI A-D route that matches the snooped state as per the conditions described above. If such an S-PMSI A-D route is found, then the PE MUST follow the procedures described in this section for that particular S-PMSI A-D route. If, later on, the snooped state ages out and is deleted from the PE, the PE SHOULD withdraw the leaf A-D route that it originated in response to the S-PMSI A-D route 🥹.

---

8.4. Inter-AS Selective Tree 🌍

Inter-AS Selective trees support all three options of inter-AS VPLS service, option (a), (b), and (c), that are supported by Inter-AS Inclusive trees. They are constructed in a manner that is very similar to Inter-AS Inclusive trees 💅.

For option (a) and option (b), support Inter-AS Selective trees are constructed without requiring a single P-multicast tree to span multiple ASes. This allows individual ASes to potentially use different P-tunneling technologies. There are two variants of this. One requires MAC and IP multicast lookup on the ASBRs, and another does not require MAC/IP multicast lookup on the ASBRs and instead builds segmented Inter-AS Selective trees 🧩.

Segmented Inter-AS Selective trees can also be used with option (c), unlike Segmented Inter-AS Inclusive trees. This is because the S-PMSI A-D routes can be exchanged via ASBRs (even though BGP VPLS A-D routes are not exchanged via ASBRs) 🫶.

In the case of option (c), an Inter-AS Selective tree can also be a non-segmented P-multicast tree that spans multiple ASes 🌈.

8.4.1. VSIs on the ASBRs ✨

Okay bestie, so when VSIs live on the ASBRs 🏰, the ASBR requirements from the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section still apply 💅. The source ASBR (the one getting traffic from another AS) gets to decide for itself whether it wants Selective trees 🌸. But if it does use them, it MUST perform a MAC lookup to figure out which Selective tree the VPLS packet goes on 🔍.

8.4.1.1. VPLS Inter-AS Selective Tree A-D Binding 🎀

Propagating S-PMSI A-D routes works the same way as the intra-AS case in the "MCAST-VPLS NLRI" section 🫶. The BGP Selective tree A-D routes that PEs generate inside an AS MUST NOT be propagated outside that AS 🚫. Stay in your lane, routes 💅.

8.4.2. Inter-AS Segmented Selective Trees 🧩

Inter-AS Segmented Selective trees MUST be implemented when option (b) is used to provide the inter-AS VPLS service 🙌. They MAY be used when option (c) is implemented to provide the inter-AS VPLS service 🦋.

These tunnels are built similarly to an inter-AS Segmented Inclusive Tunnel. Basically, the tunnel is a chain of tunnel segments glued together 🔗. There are two kinds of segments:

• an intra-AS tunnel segment, which spans ASBRs within the same AS
• an inter-AS tunnel segment, which spans adjacent ASBRs in adjacent ASes

The ASes a tunnel passes through are not required to use the same tunneling mechanism. Each AS can pick whatever mechanism it likes to build its own intra-AS tunnel segment 🌈. Mix and match, it's giving flexibility ✨.

The PE that decides to set up a Selective tree advertises the Selective tree-to-multicast stream binding using an S-PMSI A-D route 📣. It follows the procedures in the "Advertising (C-S, C-G) Binding to a Selective Tree" section, and it sends this to the routers in its own AS 💌.

An S-PMSI A-D route that gets advertised outside the AS where the originating PE lives is called an Inter-AS S-PMSI tree A-D route 🌍. Even though a PE originates it as an intra-AS S-PMSI A-D route, once it leaves the AS it counts as an Inter-AS route outside the AS 🧳.

8.4.2.1. Handling S-PMSI A-D Routes by ASBRs 🛂

ASBRs handle S-PMSI A-D routes (both inside and outside the AS of the PE that originated the route) the same way they're described in the "Propagating BGP VPLS A-D Routes to Other ASes" section 🔁. The one difference is that these procedures apply to S-PMSI A-D routes and their NLRI, instead of Inter-AS A-D routes and their NLRI 🫶.

On top of all that, an ASBR only advertises a leaf A-D route in response to an S-PMSI A-D route if one of these is true 👀:

• The S-PMSI A-D route came in via EBGP from another ASBR, and the ASBR merges that S-PMSI A-D route into an Inter-AS BGP VPLS A-D route, as described in the next section.
• The ASBR gets a leaf A-D route from a downstream PE or ASBR in response to an S-PMSI A-D route it got from an upstream PE or ASBR, and it passed that route on, inter-AS, to downstream ASBRs and PEs.
• The ASBR has snooped state from local CEs that matches the NLRI in the S-PMSI A-D route, following these rules:
  • i) The NLRI encodes (C-S, C-G), which is the same as the snooped (C-S, C-G).
  • ii) The NLRI encodes (*, C-G), there is snooped state for at least one (C-S, C-G), and there is no other matching S-PMSI A-D route for (C-S, C-G), or there is snooped state for (*, C-G).
  • iii) The NLRI encodes (*, *), there is snooped state for at least one (C-S, C-G) or (*, C-G), and there is no other matching S-PMSI A-D route for that (C-S, C-G) or (*, C-G), respectively.

The C-multicast data traffic is sent on the Selective tree by the originating PE 📦. When it reaches an ASBR that sits on the inter-AS segmented tree, it gets delivered to local receivers, if there are any 🎯. Then it's forwarded on any inter-AS or intra-AS segments that exist on the Inter-AS Selective segmented tree 🚀. If the Inter-AS Selective segmented tree gets merged onto an Inclusive tree (more on that in the next section), the data traffic gets forwarded onto the Inclusive tree instead 🪄.

8.4.2.1.1. Merging Selective Tree into an Inclusive Tree 💫

Picture this situation 🎬:

• An ASBR is receiving (or expecting to receive) inter-AS (C-S, C-G) data from upstream via a Selective tree.
• The ASBR is sending (or expecting to send) that inter-AS (C-S, C-G) data downstream via an Inclusive tree.

This can happen when the upstream providers have a policy of using Selective trees, but the downstream providers have a policy of using Inclusive trees 🤷‍♀️. To make this work, an ASBR MAY, under certain conditions, merge one or more upstream Selective trees into a downstream Inclusive tree 🧠. Heads up though: this only works for option (b), not option (c), because with option (c) the ASBRs don't keep any Inclusive tree state 🙅‍♀️.

A particular ASBR MAY merge a Selective tree (tied to a particular S-PMSI A-D route) into an Inclusive tree (tied to a particular Inter-AS BGP VPLS A-D route) if and only if all of these conditions hold ✅:

• The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route originate in the same AS. The Inter-AS BGP VPLS A-D route carries the originating AS in its AS_PATH attribute, and so does the S-PMSI A-D route.
• The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route have exactly the same set of RTs.

To merge, the ASBR stitches the tail end of the P-tunnel (from the PMSI Tunnel attribute of the S-PMSI A-D route it received) onto the head of the P-tunnel (from the PMSI Tunnel attribute of the Inter-AS BGP VPLS A-D route it re-advertises) 🪡.

An ASBR that merges an S-PMSI A-D route into an Inter-AS BGP VPLS A-D route MUST NOT re-advertise that S-PMSI A-D route 🙅‍♀️. One merge, one route, no encore 💀.

8.4.3. Inter-AS Non-segmented Selective Trees 🌷

Inter-AS Non-segmented Selective trees MAY be used in the case of option (c) 🌼.

With this method, there's a multi-hop EBGP peering between the PEs (or a Route Reflector) in one AS and the PEs (or Route Reflector) in another AS 🤝. The PEs swap BGP Selective tree A-D routes along with the PMSI Tunnel attribute, same as the intra-AS case in the "Option (c): Non-segmented Tunnels" section 📬.

The PEs in different ASes use a non-segmented Selective inter-AS P2MP tunnel for VPLS multicast 🚇.

Here's the best part: this method needs no VPLS information (in either the control or the data plane) on the ASBRs 🥳. The ASBRs only have to join the non-segmented P2MP tunnel setup in the control plane, and do MPLS label forwarding in the data plane 🧚.

Data forwarding in this model is the same as in the intra-AS case described in the "Establishing P-Multicast Trees" section 💜.

9. BGP Extensions 🎀

This section describes how the BGP extensions this document needs are encoded 📝.

9.1. Inclusive Tree/Selective Tree Identifier 🏷️

Inclusive P-multicast tree and Selective P-multicast tree advertisements carry the P-multicast tree identifier 🪪. To carry this identifier, this document reuses the BGP attribute called PMSI_TUNNEL, which is defined in [RFC6514] 💖.

When the PMSI Tunnel attribute is carried in VPLS A-D or VPLS S-PMSI A-D routes, this document only supports these Tunnel Types 🎯:

• 0 - No tunnel information present
• 1 - RSVP-TE P2MP LSP
• 2 - LDP P2MP LSP
• 6 - Ingress Replication

9.2. MCAST-VPLS NLRI 🦋

This document defines a brand new BGP NLRI called the "MCAST-VPLS NLRI" 🌸.

Here's the format of the MCAST-VPLS NLRI 👇:

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

The Route Type field defines the encoding of the Route Type specific field of the MCAST-VPLS NLRI 🔑. The Length field tells you the length, in octets, of the Route Type specific field of the MCAST-VPLS NLRI 📏.

This document defines these route types for A-D routes 🧁:

• 3 - Selective Tree A-D route;
• 4 - Leaf A-D route.

The MCAST-VPLS NLRI gets carried in BGP using BGP Multiprotocol Extensions [RFC4760], with an Address Family Identifier (AFI) of 25 (L2VPN AFI) and a Subsequent Address Family Identifier (SAFI) of MCAST-VPLS 🛸. The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute holds the MCAST-VPLS NLRI, encoded as specified above 📦.

For two BGP speakers to exchange labeled MCAST-VPLS NLRI, they must use BGP Capabilities Advertisement so they both know they can process it properly 🤝. This is done as specified in [RFC4760], using capability code 1 (multiprotocol BGP) with an AFI of 25 and a SAFI of MCAST-VPLS 🔥.

The following describes the format of the Route Type specific field of MCAST-VPLS NLRI for the various route types defined in this document 👀.

9.2.1. S-PMSI A-D Route 🎀

okay so the Route Type specific field of an MCAST-VPLS NLRI for an S-PMSI A-D route is made of five pieces, and bestie, the layout is giving structure 💅

            +-----------------------------------+
            |      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 the way [RFC4364] describes it. Literally just follow that and you're good 🫶

The Multicast Source field holds the C-S address, which is the address of the multicast source. If that field has an IPv4 address, the Multicast Source Length field is 32. If it has an IPv6 address, the Multicast Source Length field is 128. You're also allowed to set the Multicast Source Length field to 0, and that means wildcard 🌈

The Multicast Group field holds the C-G address, which is the address of the multicast group. Same deal here: an IPv4 address means the Multicast Group Length field is 32, and an IPv6 address means it's 128. And yep, the Multicast Group Length field can be 0 too, which is another wildcard 🦋

Now the Originating Router's IP Address field. Whether it carries an IPv4 or an IPv6 address is decided by the Length field of the MCAST-VPLS NLRI, so the Length field is basically telling you the whole story 👑 If the Multicast Source and Multicast Group fields are both IPv4, then the Length field is 22 bytes when the Originating Router's IP Address is IPv4, and 34 bytes when it's IPv6. If the Multicast Source and Multicast Group fields are both IPv6, then the Length field is 46 bytes when the Originating Router's IP Address is IPv4, and 58 bytes when it's IPv6. Here's the cheat sheet 🍓

   Multicast   Multicast                Originating Router's   Length
   Source      Group                       IP Address

     IPv4      IPv4                        IPv4                  22
     IPv4      IPv4                        IPv6                  34
     IPv6      IPv6                        IPv4                  46
     IPv6      IPv6                        IPv6                  58

Where S-PMSI A-D routes actually get used is in the "Optimizing Multicast Distribution via Selective Trees" section, so go check that one if you want the full story 🧚

9.2.2. Leaf A-D Route ✨

Now the leaf A-D route. Its Route Type specific field of the MCAST-VPLS NLRI looks like this, and it's a lot simpler, no cap 💜

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

So here's the trick. Whether the Originating Router's IP Address field is IPv4 or IPv6 comes from two things together: the Length field of the MCAST-VPLS NLRI and the length of the Route Key field. Put those two lengths together and you can work out how long the Originating Router's IP Address is 🔥 If that computed length is 4, the address is IPv4. If it's 16, the address is IPv6. Math, but make it cute 🌸

Leaf A-D routes get used in two places: the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section and the "Optimizing Multicast Distribution via Selective Trees" section ✨

10. Aggregation Considerations 🌷

Okay, the big thing to know right away: this document does NOT lock you into one particular set of rules for deciding whether the Inclusive or Selective trees of two VPLS instances get instantiated by the same Aggregate Inclusive/Selective tree. That's up to you! It could come from implementation-specific heuristics, from configuration, or maybe even from offline tools 🎀

This section is where we talk through the possible approaches to aggregation, so let's get into it 💅

Generally speaking, the heuristic for picking which VPLS instances or <C-S, C-G> entries to aggregate is implementation dependent. Offline tools could be used for this too, and honestly it's conceivable. This section walks through some of the trade-offs you'll be weighing 🦋

Now, the "congruency" of aggregation. It's defined by how much the leaves of the client trees that get aggregated on an SP tree overlap. For Aggregate Inclusive trees, congruency depends on how much the VPLS instances aggregated on that Aggregate Inclusive tree overlap in membership. Complete overlap means aggregation is perfectly congruent. The less overlap there is between the VPLS instances, the less congruent the aggregation gets 📉

Here's the catch: to figure out the congruency of the client trees a PE could aggregate, that PE has to know the leaves of those client trees. And that's true no matter whether the aggregated SP tree is set up with mLDP or RSVP-TE. No escape, babe 💀

If aggregation isn't perfectly congruent, a PE might receive traffic for VPLS instances it doesn't belong to. As the amount of multicast traffic in those unwanted VPLS instances goes up, aggregation gets less optimal in terms of the traffic that's actually delivered. So you're always trading off between cutting multicast state in the core and delivering unwanted traffic 🙈

An implementation should give you knobs to control aggregation based on how congruent the tree being aggregated is. That lets an SP decide how much aggregation to do based on VPLS membership and traffic profiles in its network. If different PEs are setting up Aggregate Inclusive trees, those knobs also let an SP engineer the maximum amount of unwanted VPLS instances a particular PE might receive traffic for. Very organized of them, ngl ✨

The state/bandwidth optimality trade-off can be improved even further by having a versatile many-to-many association between client trees and provider trees. So one VPLS instance can be mapped to multiple Aggregate trees. The mechanisms for doing that are still for further study. It may also be possible to use both ingress replication and an Aggregate tree for a particular VPLS, and the mechanisms for that are also for further study 🌈

11. Data Forwarding 🦋

11.1. MPLS Tree Encapsulation 🧚

11.1.1. Mapping Multiple VPLS Instances to a P2MP LSP 💖

This diagram shows how a VPLS multicast packet moves as it enters and leaves the SP network when MPLS trees are used for multiple VPLS instances. RSVP-TE P2MP LSPs are examples of those trees 🌸

   Packets received        Packets in transit      Packets forwarded
   at ingress PE           in the service          by egress PEs
                           provider network

                           +---------------+
                           |MPLS Tree Label|
                           +---------------+
                           | VPLS Label    |
   ++=============++       ++=============++       ++=============++
   ||C-Ether Hdr  ||       || C-Ether Hdr ||       || C-Ether Hdr ||
   ++=============++ >>>>> ++=============++ >>>>> ++=============++
   || C-IP Header ||       || C-IP Header ||       || C-IP Header ||
   ++=============++ >>>>> ++=============++ >>>>> ++=============++
   || C-Payload   ||       || C-Payload   ||       || C-Payload   ||
   ++=============++       ++=============++       ++=============++

So when an ingress PE gets a packet, it uses the procedures from [RFC4761] and [RFC4762] to work out which VPLS instance the packet belongs to. If the packet is an IP multicast packet and the ingress PE uses an Aggregate Selective tree for the (C-S, C-G) carried in the packet, then the ingress PE pushes the VPLS Label for its VPLS instance and the MPLS Tree Label for that Aggregate Selective tree, and then sends the packet over the P2MP LSP for that Aggregate Selective tree 🎀

Otherwise, if the ingress PE isn't using an Aggregate Selective tree for that (C-S, C-G), or the packet is non-IP multicast or broadcast, the ingress PE pushes the VPLS label for its VPLS instance and the MPLS Tree Label for the Aggregate Inclusive tree. Then it sends the packet over the P2MP LSP for that Aggregate Inclusive tree 💅

Over on the egress side, the egress PE does a lookup on the outer MPLS tree label. That tells it which MPLS forwarding table to use for looking up the inner MPLS label, which is the VPLS label. That table is specific to the tree label space, as identified by the MPLS Tree Label. Now, the inner VPLS label is only unique within the context of the root of the tree, because the root assigns it without coordinating with any other nodes. So it isn't unique across multiple roots. To unambiguously identify a particular VPLS, you need the VPLS label plus the context where that label is unique, and the outer MPLS label (the MPLS Tree Label) provides that context [RFC5331]. Main character energy for that outer label 👑

Once the outer MPLS label is popped, the lookup on the resulting MPLS label tells the egress PE which VSI to do the C-multicast data packet lookup in. Then it pops the inner MPLS label and sends the packet to that VSI for multicast data forwarding 🦋✨

11.1.2. Mapping One VPLS Instance to a P2MP LSP 🎀

okay so this one is about what happens when ONE MPLS tree is handling ONE VPLS instance 🌸 RSVP-TE P2MP LSPs are the classic examples of these trees. Here's the glow-up a VPLS multicast packet goes through as it enters and leaves the SP network:

   Packets received        Packets in transit      Packets forwarded
   at ingress PE           in the service          by egress PEs
                           provider network

                           +---------------+
                           |MPLS Tree Label|
   ++=============++       ++=============++       ++=============++
   ||C-Ether Hdr  ||       || C-Ether Hdr ||       || C-Ether Hdr ||
   ++=============++ >>>>> ++=============++ >>>>> ++=============++
   || C-IP Header ||       || C-IP Header ||       || C-IP Header ||
   ++=============++ >>>>> ++=============++ >>>>> ++=============++
   || C-Payload   ||       || C-Payload   ||       || C-Payload   ||
   ++=============++       ++=============++       ++=============++

so when an ingress PE receives a packet, it uses the procedures from [RFC4761] and [RFC4762] to figure out which VPLS instance the packet belongs to 🔥 next up, if the packet is an IP multicast packet AND the ingress PE is using a Selective tree for the (C-S, C-G) carried in it, then the ingress PE pushes the MPLS Tree Label for that Selective tree and sends the packet over the P2MP LSP attached to it. it's giving precise. 💅

BUT if the ingress PE is NOT using a Selective tree for that (C-S, C-G), or the packet is non-IP multicast or broadcast, then it pushes the MPLS Tree Label for the Inclusive tree and sends the packet over the P2MP LSP for the Inclusive tree. main character energy for the Inclusive tree 👑

on the egress side, the PE does a lookup on the MPLS tree label and figures out which VSI the receiver PE needs to use for the C-multicast data packet lookup. then it pops the MPLS label and sends the packet to that VSI for multicast data forwarding ✨

---

12. VPLS Data Packet Treatment 💖

okay bestie, let's talk about how VPLS packets get treated depending on what's inside them 🦋

if a VPLS packet comes into an ingress PE from a VPLS site and its destination MAC address is a multicast address, a P-multicast tree SHOULD be used to carry it, if possible. if the packet is an IP multicast packet AND a Selective tree exists for that multicast stream, the Selective tree MUST be used. otherwise, if a (C-*, C-*) Selective tree exists for the VPLS, it SHOULD be used. and if that's not there either, but an Inclusive tree exists for the VPLS, it SHOULD be used. the order is literally everything 🫶

now if the destination MAC address is a broadcast address, the packet gets flooded 🌈 if a (C-*, C-*) Selective tree exists for the VPLS, the PE SHOULD flood over it. else, if an Inclusive tree exists for the VPLS, the PE SHOULD flood over it. and if neither exists, the PE MUST flood the packet using the procedures in [RFC4761] or [RFC4762]. no notes 😭

next, if the destination MAC address is a unicast address that hasn't been learned yet, the packet MUST be sent to ALL PEs in the VPLS 🍓 Inclusive P-multicast trees, or a Selective P-multicast tree bound to (C-*, C-*), SHOULD be used to send these unknown unicast MAC packets to all PEs. when that's happening, the receiving PEs MUST support MAC address learning for packets they receive on a multicast tree. so that they can actually learn, the receiver PE MUST be able to figure out the sender PE when a VPLS packet shows up on a P-multicast tree. this also means the MPLS P-multicast tree technology MUST allow the egress PE to determine the sender PE from the received MPLS packet 🔥

when a receiver PE gets a VPLS packet on a P-multicast tree with a source MAC address it hasn't learned yet, it works out the PW to the sender PE. then it creates forwarding state in the VPLS instance, with a destination MAC address equal to the source MAC address being learned, and the PW pointing to the sender PE. learning unlocked 🧚

It should be noted that when a sender PE is sending packets for an unknown unicast MAC address over a P-multicast tree and learns the PW it should use for that unicast MAC address, it might immediately switch to sending those packets over that particular PW. since those packets were originally going over a P-multicast tree, this could lead to packet reordering. this constraint should be taken into consideration if unknown unicast frames are forwarded using a P-multicast tree, instead of multiple PWs based on [RFC4761] or [RFC4762]. 💀

finally, an implementation SHOULD support transporting unknown unicast traffic over Inclusive P-multicast trees. and an implementation MUST support MAC address learning for packets received on a P-multicast tree. non-negotiable, periodt 💜

---

13. Security Considerations 🔒

okay this section is a big deal, so let's be serious for a sec 🙈 the security considerations discussed in [RFC4761] and [RFC4762] apply to this document too. this section describes some additional ones.

as [RFC4761] mentions, there are two sides to getting data privacy and protecting against denial-of-service attacks in a VPLS: securing the control plane and protecting the forwarding path. if the control plane gets compromised, a PE could send multicast data belonging to one VPLS into another VPLS, black-hole VPLS multicast data, or even send it to an eavesdropper. none of those are acceptable from a data privacy point of view 😭 a compromised control plane could also black-hole VPLS multicast data and open the door to unauthorized VPLS multicast usage. for example, someone could exploit traffic replication within a multicast tree to amplify a denial-of-service attack by sending huge amounts of traffic.

this document uses BGP for the control plane. so techniques like the ones in [RFC5925] help authenticate BGP messages, which makes it harder to spoof updates (those can be used to divert VPLS traffic into the wrong VPLS) or withdrawals (which are denial-of-service attacks). in the multi-AS methods (b) and (c) described in the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section, this also means protecting the inter-AS BGP sessions, between the ASBRs, the PEs, or the Route Reflectors 🛡️

note that [RFC5925] will NOT help keep the MPLS labels private that are associated with P2MP LSPs or the upstream MPLS labels used for aggregation. if you know the labels, you can eavesdrop on VPLS traffic. however, that requires access to the data path inside an SP network, which is assumed to be made up of trusted nodes and links 🌸

one of the requirements for protecting the data plane is that MPLS labels MUST be accepted only from valid interfaces. this applies both to MPLS labels associated with P2MP LSPs and to the upstream-assigned MPLS labels. for a PE, valid interfaces are the links from other routers in the PE's own AS. for an ASBR, valid interfaces are the links from other routers in the ASBR's own AS, plus links from other ASBRs in ASes that have instances of a given VPLS. it's especially important in multi-AS VPLS instances that one accepts VPLS packets only from valid interfaces. 🚨

---

14. IANA Considerations 🧚

this document defines a new NLRI called "MCAST-VPLS", which is carried in BGP using multiprotocol extensions. IANA has assigned it a SAFI value of 8. ✨

this document also defines a BGP-optional transitive attribute called "PMSI_TUNNEL". it's the SAME attribute as the one defined in [RFC6514], and IANA has already assigned its code point as 22 [BGP-IANA]. so no further action is required from IANA regarding this attribute 💅

---

15. References 📚

15.1. Normative References 💜

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
• [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
• [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
• [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
• [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
• [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
• [RFC6511] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths", RFC 6511, February 2012.
• [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, "Using Multipoint LDP When the Backbone Has No Route to the Root", RFC 6512, February 2012.

15.2. Informative References 📚✨

okay so the informative references are basically the "go read this if you wanna go deeper" list bestie 🫶 no cap there are a LOT of them and every single one is a whole vibe 💅

• [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012. 💜
• [RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012. 🦋
• [RFC6388] 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. 🌸
• [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011. 🎀
• [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. 🔐
• [RFC5501] Kamite, Y., Ed., Wada, Y., Serbest, Y., Morin, T., and L. Fang, "Requirements for Multicast Support in Virtual Private LAN Services", RFC 5501, March 2009. 🧚
• [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008. ✨
• [RFC4684] 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. 🍓
• [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. 💖
• [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. 🌈
• [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. 👑
• [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. 💅
• [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. 🫶
• [RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 🌸
• [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. 🦋
• [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. 🎀
• [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. 🧚
• [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. ✨
• [MULTI-HOMING] Kothari, B., Kompella, K., Henderickx, W., Balus, F., Uttaro, J., Palislamovic, S., and W. Lin, "BGP based Multi-homing in Virtual Private LAN Service", Work in Progress, July 2013. 🍓
• [BGP-IANA] IANA, "Border Gateway Protocol (BGP) Parameters", <http://www.iana.org/assignments/bgp-parameters>. 💜

16. Acknowledgments 🫶🌈

Many thanks to Thomas Morin for his support of this work. 💖

We would also like to thank the authors of [RFC6514] and [RFC6513], bestie, because the details of the inter-AS segmented tree procedures in this document, as well as some of the text describing those procedures, benefited from those RFCs. 🦋 The same goes for the notion of Inclusive and Selective trees, and for the procedures for switching from Inclusive to Selective trees. 💅

We would also like to thank Nabil Bitar, Stewart Bryant, Wim Henderickx, and Eric Rosen for their review and comments. 👑✨

Authors' Addresses 📮

Rahul Aggarwal 998 Lucky Avenue Menlo Park, CA 94025 USA Phone: +1-415-806-5527 EMail: raggarwa_1@yahoo.com

Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan EMail: y.kamite@ntt.com

Luyuan Fang Microsoft EMail: lufang@microsoft.com

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

Chaitanya Kodeboniya EMail: chaitk@yahoo.com