RFC 7524
Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)
Part 1 of 9 🎀
RFC 7524: Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) 💖
okay so this RFC is a Standards Track doc from the IETF, dated May 2015 📅. It's published as RFC 7524 with ISSN 2070-1721. The header has no Obsoletes or Updates lines, so it doesn't replace or update anything, it's its own thing ✨
The authors are a whole squad 🫶: Y. Rekhter, E. Rosen, R. Aggarwal, T. Morin, I. Grosclaude, N. Leymann, and S. Saad. They're from Juniper Networks, Arktan, Orange, Deutsche Telekom AG, and AT&T. Literal dream team 👑
Abstract 🦋
this doc explains how to build inter-area point-to-multipoint (P2MP) segmented service LSPs. The trick is to chop each LSP into intra-area segments and use BGP as the inter-area routing and Label Distribution Protocol (LDP) 🔥
Inside each IGP area, the segments either ride on intra-area P2MP LSPs (using P2MP LSP hierarchy) or get set up with ingress replication. The intra-area P2MP LSPs can be signaled with P2MP RSVP-TE or P2MP multipoint LDP (mLDP). If ingress replication is used inside an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in that area.
The services using these inter-area service LSPs may be BGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS. It's giving "everything in one place" 💅
Status of This Memo 🌸
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.
Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc7524.
Copyright Notice ©️
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents 📚
1. Introduction ....................................................5
2. Specification of Requirements ...................................5
3. General Assumptions and Terminology .............................6
4. Inter-Area P2MP Segmented Next-Hop Extended Community ...........7
5. Discovering P2MP FEC of Inter-Area P2MP Service LSP .............8
5.1. BGP MVPN ...................................................8
5.1.1. Routes Originated by PE or ASBR .....................9
5.1.2. Routes Re-advertised by PE or ASBR ..................9
5.1.3. Inter-Area Routes ...................................9
5.2. LDP VPLS with BGP Auto-discovery or BGP VPLS ..............10
5.2.1. Routes Originated by PE or ASBR ....................10
5.2.2. Routes Re-advertised by PE or ASBR .................11
5.2.3. Inter-Area Routes ..................................11
5.3. Global Table Multicast over MPLS ..........................12
6. Egress PE/ASBR Signaling Procedures ............................13
6.1. Determining the Upstream ABR/PE/ASBR (Upstream Node) ......13
6.1.1. Upstream Node for MVPN or VPLS .....................13
6.1.2. Upstream Node for Global Table Multicast ...........14
6.2. Originating a Leaf A-D Route ..............................15
6.2.1. Leaf A-D Route for MVPN and VPLS ...................15
6.2.2. Leaf A-D Route for Global Table Multicast ..........15
6.2.3. Constructing the Rest of the Leaf A-D Route ........17
6.3. PIM-SM in ASM Mode for Global Table Multicast .............18
6.3.1. Option 1 ...........................................18
6.3.1.1. Originating Source Active A-D Routes ......18
6.3.1.2. Receiving BGP Source Active A-D
Route by PE ...............................19
6.3.1.3. Handling (S,G,rpt) State ..................19
6.3.2. Option 2 ...........................................19
6.3.2.1. Originating Source Active A-D Routes ......19
6.3.2.2. Receiving BGP Source Active A-D Route .....20
6.3.2.3. Pruning Sources Off the Shared Tree .......20
6.3.2.4. More on Handling (S,G,rpt) State ..........21
7. Egress ABR Procedures ..........................................21
7.1. Handling Leaf A-D Route on Egress ABR .....................21
7.2. P2MP LSP as the Intra-Area LSP in the Egress Area .........23
7.2.1. Received Leaf A-D Route Is for MVPN or VPLS ........23
7.2.2. Received Leaf A-D Route Is for Global Table
Multicast ..........................................24
7.2.2.1. Global Table Multicast and S-PMSI
A-D Routes ................................24
7.2.2.2. Global Table Multicast and
Wildcard S-PMSI A-D Routes ................25
7.2.3. Global Table Multicast and the Expected
Upstream Node ......................................25
7.2.4. P2MP LDP LSP as the Intra-Area P2MP LSP ............26
7.2.5. P2MP RSVP-TE LSP as the Intra-Area P2MP LSP ........26
7.3. Ingress Replication in the Egress Area ....................26
8. Ingress ABR Procedures .........................................27
8.1. P2MP LSP as the Intra-Area LSP in the Backbone Area .......27
8.2. Ingress Replication in the Backbone Area ..................27
9. Ingress PE/ASBR Procedures .....................................28
9.1. P2MP LSP as the Intra-Area LSP in the Ingress Area ........28
9.2. Ingress Replication in the Ingress Area ...................29
10. Common Tunnel Type in the Ingress and Egress Areas ............29
11. Placement of Ingress and Egress PEs ...........................30
12. MVPN with Virtual Hub-and-Spoke ...............................31
13. Data Plane ....................................................31
13.1. Data Plane Procedures on ABRs ............................31
13.2. Data Plane Procedures on Egress PEs ......................32
13.3. Data Plane Procedures on Ingress PEs .....................33
13.4. Data Plane Procedures on Transit Routers .................33
14. Support for Inter-Area Transport LSPs .........................33
14.1. "Transport Tunnel" Tunnel Type ...........................33
14.2. Discovering Leaves of the Inter-Area P2MP Service LSP ....34
14.3. Discovering P2MP FEC of P2MP Transport LSP ...............34
14.4. Egress PE Procedures for P2MP Transport LSP ..............35
14.5. ABRs and Ingress PE Procedures for P2MP Transport LSP ....35
14.6. Discussion ...............................................36
15. IANA Considerations ...........................................38
16. Security Considerations .......................................38
17. References ....................................................39
17.1. Normative References .....................................39
17.2. Informative References ...................................41
Acknowledgements ..................................................41
Authors' Addresses ................................................421. Introduction 🧚
okay so this doc is all about building inter-area point-to-multipoint (P2MP) segmented service LSPs. We split each LSP into intra-area segments and use BGP as the inter-area routing and label distribution protocol 💜
Inside each IGP area, the intra-area segments either ride on intra-area P2MP LSPs (potentially using P2MP LSP hierarchy) or get set up with ingress replication. The intra-area P2MP LSPs can be signaled with P2MP RSVP-TE [RFC4875] or P2MP mLDP [RFC6388]. If ingress replication is used in an IGP area, then (multipoint-to-point) LDP LSPs [RFC5036] or (point-to-point) RSVP-TE LSPs [RFC3209] may be used within that IGP area. The services that use these inter-area service LSPs may be BGP Multicast VPN (BGP MVPN), VPLS multicast, or global table multicast over MPLS 🌈
The main use case for these segmented P2MP service LSPs is when the Provider Edge (PE) routers are in different areas but in the same Autonomous System (AS), and thousands or more PEs need P2MP connectivity. This can happen when MPLS gets pushed further to the metro edge and the metros are in different IGP areas. It can also happen when a service provider's network has multiple IGP areas in a single AS with a huge number of PEs. Seamless MPLS is the industry term for this case [SEAMLESS-MPLS]. So one of the applicabilities of this document is that it describes the multicast procedures for seamless MPLS 🔥
Note that [RFC6514] and [RFC7117] already specify procedures for building segmented inter-AS P2MP service LSPs. This document complements those procedures, because it extends the segmented P2MP LSP model so it also applies to inter-area P2MP service LSPs. In fact, an inter-AS deployment could use inter-AS segmented P2MP LSPs as specified in [RFC6514] and [RFC7117], where each intra-AS segment is built using inter-area segmented P2MP LSPs as specified in this document 🫶
2. 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].
3. General Assumptions and Terminology ✨
okay bestie, first we need to get on the same page about what you should already know 🧠. The reader is assumed to be familiar with MVPN procedures and terminology [RFC6513] [RFC6514] and VPLS procedures and terminology [RFC7117]. so if MVPN and VPLS feel like a blur, go catch up on those first 💅
this document lets Area Border Routers (ABRs), acting as Route Reflectors, follow the procedures in [SEAMLESS-MPLS] when they handle the BGP Next Hop of routes to the PEs 🦋. here's the tea: when an ABR reflects these routes from a non-backbone area into the backbone area, the ABR MUST set the BGP Next Hop to its own loopback address (that's next-hop-self) 🌸. but when it reflects them from the backbone area into a non-backbone area, the ABR SHOULD NOT change the BGP Next Hop address (that's next-hop-unchanged) 🫶
even though this document lets ABRs do the [SEAMLESS-MPLS] thing, the procedures in this document still work when ABRs don't follow [SEAMLESS-MPLS]. no cap, that's a big deal 💖
this document describes one particular way to support the global table multicast service ✨. it calls this approach simply "global table multicast", but that doesn't mean there are no other ways to do it, so don't get it twisted 🙈
one alternative is to use the MVPN procedures in [RFC6514] and in this document. that alternative is talked about in more detail in [GTM], but this document doesn't go any further with it 🌈
in the context of global table multicast, this document assumes that ABRs do not carry routes to destinations outside their own AS 👑. it also assumes that an Autonomous System Border Router (ASBR), when it re-advertises routes into Internal BGP (IBGP) that it got from an external speaker (learned via External BGP (EBGP)), may not change the BGP Next Hop to self 💅
so inside an AS, a P2MP service LSP gets split into three segments: the ingress area segment, the backbone area segment, and the egress area segment 🧚. in each area, a segment is carried over an intra-area P2MP LSP, or it's set up using ingress replication 💜
when intra-area P2MP LSPs are used for the intra-area segments, you can have either a 1:1 or an n:1 mapping between the intra-area segments of the inter-area P2MP service LSP and a given intra-area P2MP LSP 🍓. the n:1 version is done with P2MP LSP hierarchy and upstream-assigned labels [RFC5331]. to keep things simple, this document assumes P2MP LSP hierarchy is used even for 1:1 mapping, and in that case an Implicit NULL is the upstream-assigned label 🎀
when intra-area segments of the inter-area P2MP service LSP are set up with ingress replication, multiple segments can ride in the same P2P RSVP-TE or MP2P LDP LSP ✨. you can get that using downstream-assigned labels alone 🦋
the ingress area segment of a P2MP service LSP is rooted at a PE (or at an ASBR when the P2MP service LSP spans multiple ASes) 🌟. its leaves are the other PEs/ASBRs and the ABRs in the same area as the root PE 💖
the backbone area segment is rooted at one of three things: an ABR connected to the ingress area (the ingress ABR), an ASBR if that ASBR is in the backbone area, or a PE if that PE is in the backbone area 🌈. its leaf ABRs are the ones connected to the egress area(s), or the PEs in the backbone area, or the ASBRs in the backbone area 👑
the egress area segment is rooted at an ABR in the egress area (the egress ABR), and its leaves are the PEs and ASBR in that egress area (that last one covers the case where the P2MP service LSP spans multiple ASes) 🫶. for a given P2MP service LSP, there can be more than one backbone segment, each rooted at its own ingress ABR, and more than one egress area segment, each rooted at its own egress ABR 🍓
this document uses the term "A-D routes" to mean "auto-discovery routes" 💅
an implementation that supports this document MUST implement the procedures described in the following sections to support inter-area P2MP segmented service LSPs. no skipping, bestie 😭
4. Inter-Area P2MP Segmented Next-Hop Extended Community 🌸
this document defines a brand new Transitive IPv4-Address-Specific Extended Community Sub-Type called "Inter-Area P2MP Next-Hop" ✨. it also defines a new BGP Transitive IPv6-Address-Specific Extended Community Sub-Type, also called "Inter-Area P2MP Next-Hop" 🌈
a PE, an ABR, or an ASBR builds the Inter-Area P2MP Segmented Next-Hop Extended Community like this 🛠️:
- The
Global Administratorfield MUST be set to an IP address of the PE, ABR, or ASBR that originates or advertises the route carrying the P2MP Next-Hop Extended Community 💖. for example, this could be the loopback address of the PE, ABR, or ASBR that advertises the route 🦋 - The
Local Administratorfield MUST be set to 0 🎀
if the Global Administrator field is an IPv4 address, you use the IPv4-Address-Specific Extended Community ✨. if it's an IPv6 address, you use the IPv6-Address-Specific Extended Community 🧚
the detailed usage of these Extended Communities is covered in the following sections 👑
5. Discovering P2MP FEC of Inter-Area P2MP Service LSP 🔍
every inter-area P2MP service LSP has a P2MP Forwarding Equivalence Class (FEC) attached to it 💜. the egress PEs need to learn this P2MP FEC so they can start building the egress area segment of the P2MP inter-area service LSP 🫶
the egress PEs learn the P2MP FEC of the inter-area P2MP LSP either by configuration, or based on application-specific procedures (for example, MVPN-specific procedures or VPLS-specific procedures) 🌈
5.1. BGP MVPN 🦋
egress PEs and/or ASBRs discover the P2MP FEC of the service LSPs used by BGP MVPN through the Inclusive Provider Multicast Service Interface (I-PMSI) or Selective PMSI (S-PMSI) A-D routes. these are originated by the ingress PEs or ASBRs following the procedures of [RFC6514], with the modifications described in this document 💅. the Network Layer Reachability Information (NLRI) of these routes encodes the P2MP FEC 🍓
the procedures in this document require that at least one ABR in a given IGP area acts as a Route Reflector for MVPN A-D routes ✨. that Route Reflector is responsible for re-advertising MVPN A-D routes across area boundaries 🌸. when it re-advertises these routes across area boundaries, this Route Reflector MUST follow the procedures in this document 👑. it may also re-advertise MVPN A-D routes within the same area, and in that case it follows the plain BGP Route Reflector procedures [RFC4456] 🧚
5.1.1. Routes Originated by PE or ASBR 💖
the Leaf Information Required flag MUST be set in the PMSI Tunnel attribute carried in MVPN A-D routes originated by the ingress PEs or ASBRs 🌟. the one exception: when (a) as a matter of policy (provisioned on the ingress PEs or ASBRs) there is no aggregation of ingress area segments of the service LSPs, and (b) mLDP is used as the protocol to establish intra-area transport LSPs in the ingress area 🙈
before any Leaf A-D route is advertised by a PE or ABR in the same area (as described in the following sections), an I-PMSI/S-PMSI A-D route gets advertised first 🦋. it's advertised either with an explicit Tunnel Type and Tunnel Identifier in the PMSI Tunnel attribute, if the Tunnel Identifier has already been assigned, or with a special Tunnel Type of No tunnel information present otherwise 💜
5.1.2. Routes Re-advertised by PE or ASBR 🌈
when an ingress ABR re-advertises I-PMSI/S-PMSI A-D routes, the Leaf Information Required flag MUST be set in the PMSI Tunnel attribute present in the routes 🫶. the exception is when (a) as a matter of policy (provisioned on the ingress ABR) there is no aggregation of backbone area segments of the service LSPs, and (b) mLDP is used as the protocol to establish intra-area transport LSPs in the backbone area 🍓
likewise, when an egress ABR re-advertises I-PMSI/S-PMSI A-D routes, the Leaf Information Required flag MUST be set in the PMSI Tunnel attribute present in the routes 🌸. the exception is when (a) as a matter of policy (provisioned on the egress ABR) there is no aggregation of egress area segments of the service LSPs, and (b) mLDP is used as the protocol to establish intra-area transport LSPs in the egress area ✨
note that the procedures in the paragraph above apply when intra-area segments are realized either by intra-area P2MP LSPs or by ingress replication 👑
5.1.3. Inter-Area Routes 🧚
when BGP MVPN I-PMSI or S-PMSI A-D routes are advertised or propagated to signal inter-area P2MP service LSPs, these routes MUST carry the Inter-Area P2MP Segmented Next-Hop Extended Community 💖. this is how the routes say "hey, segment this LSP using the procedures in this document" 🦋
this Extended Community MUST be included in the I-PMSI/S-PMSI A-D route by the PE that originates the route, or by an ASBR that re-advertises the route into its own AS 🌟. the Global Administrator field in this Extended Community MUST be set to the IP address of the advertising PE or ASBR 💅. this Extended Community MUST also be included by ABRs as they re-advertise these routes 🌈. an ABR MUST set the Global Administrator field of the Inter-Area P2MP Segmented Next-Hop Extended Community to its own IP address 🫶
if this Extended Community is present in the I-PMSI/S-PMSI A-D routes, it tells ABRs and PEs/ASBRs that they have to follow the procedures in this document wherever those procedures differ from the ones in [RFC6514] 🍓
if an ASBR receives an I-PMSI or S-PMSI A-D route from an IBGP peer that carries the Inter-Area P2MP Segmented Next-Hop Extended Community, then before the ASBR re-advertises that route to an EBGP peer, it SHOULD remove this Extended Community from the route 🌸
now suppose an ASBR receives an I-PMSI/S-PMSI A-D route from an EBGP peer, and this route carries the Inter-Area P2MP Segmented Next-Hop Extended Community ✨. if the inter-area P2MP service LSP signaled by this route should not be segmented, then before re-advertising the route to its IBGP peers, the ASBR MUST remove this Extended Community from the route 👑
to keep ABRs out of the C-multicast route propagation business, this document says ABRs MUST NOT modify the BGP Next Hop when they re-advertise Inter-AS I-PMSI A-D routes 🙈. and for consistency, this document says ABRs MUST NOT modify the BGP Next Hop when they re-advertise either Intra-AS or Inter-AS I-PMSI/S-PMSI A-D routes 💀
the egress PEs may advertise the C-multicast routes to RRs that are different from the ABRs 🧚. still, ABRs can be configured to be the Route Reflectors for C-multicast routes too, and in that case they will take part in propagating C-multicast routes 💜
5.2. LDP VPLS with BGP Auto-discovery or BGP VPLS 🎀
egress PEs discover the P2MP FEC of the service LSPs used by VPLS through the VPLS A-D routes originated by the ingress PEs [RFC4761] [RFC6074], or through the VPLS S-PMSI A-D routes originated by the ingress PEs [RFC7117] ✨. the NLRI of these routes encodes the P2MP FEC 🫶
5.2.1. Routes Originated by PE or ASBR ✨
okay so the "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute that rides along in the VPLS A-D routes or VPLS S-PMSI A-D routes 🎀 when the ingress PEs or ASBRs are the ones originating them. The only plot twist is when (a) there's a policy (provisioned on the ingress PEs or ASBRs) saying there's no aggregation of ingress area segments of the service LSPs, AND (b) mLDP is the protocol doing the intra-area transport LSPs in the ingress area. 🙈 Then you get a pass.
Also, before any Leaf A-D route gets advertised by a PE or ABR in the same area (more on that in the next sections 💜), a VPLS/S-PMSI A-D route gets advertised first. It either comes with an explicit Tunnel Type and Tunnel Identifier in the PMSI Tunnel attribute, if the Tunnel Identifier has already been assigned, or it comes with a special Tunnel Type of "No tunnel information present" otherwise. Very organized, very iconic 🧚
5.2.2. Routes Re-advertised by PE or ASBR 🦋
When an ingress ABR re-advertises the VPLS/S-PMSI A-D routes, the "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute present in the routes. Exception: (a) there's a policy (provisioned on the ingress ABR) with no aggregation of backbone area segments of the service LSPs AND (b) mLDP is used to establish intra-area transport LSPs in the backbone area.
Same energy for egress ABRs 🫶. When an egress ABR re-advertises the VPLS/S-PMSI A-D routes, the "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute present in the routes, except for the case where (a) there's a policy (provisioned on the egress ABR) with no aggregation of egress area segments of the service LSPs AND (b) mLDP is used to establish intra-area transport LSPs in the egress area. Literally the same vibe, just a different area 💅
5.2.3. Inter-Area Routes 👑
When VPLS A-D routes or S-PMSI A-D routes get advertised or propagated to signal inter-area P2MP service LSPs, these routes MUST carry the Inter-Area P2MP Segmented Next-Hop Extended Community. This is how they say "hey, segment this LSP using the procedures in this document, pls" 🥹. This Extended Community MUST be included in the A-D route by the PE or ASBR that originates the route, and the Global Administrator field MUST be set to the advertising PE or ASBR's IP address. ABRs MUST ALSO include it when they re-advertise these routes (okay that was me getting excited, the original just says MUST also be included, so it's MUST, not a shout-out 😭). An ABR MUST set the Global Administrator field of the Inter-Area P2MP Segmented Next-Hop Extended Community to its own IP address.
Once that Extended Community is in the I-PMSI/S-PMSI A-D routes, ABRs and PEs/ASBRs know they have to follow the procedures in this document whenever those procedures differ from the ones in [RFC7117]. It's giving "read the room" 🌸
Note that the procedures in the paragraph above apply when intra-area segments are realized by either intra-area P2MP LSPs or by ingress replication. Just so we're clear 🍓
The procedures in this document require that at least one ABR in a given area act as a Route Reflector for VPLS A-D routes. That Route Reflector is responsible for re-advertising VPLS A-D routes across area boundaries, and when it does, it MUST follow the procedures in this document. Also, a Route Reflector may re-advertise VPLS A-D routes within the same area too. In that case it just follows plain BGP Route Reflector procedures [RFC4456]. Main character energy 🎀
When re-advertising VPLS A-D routes, a Route Reflector MUST NOT modify the BGP Next Hop of these routes. Don't touch the BGP Next Hop, bestie 🙅♀️
5.3. Global Table Multicast over MPLS 🌈
This section is about how the egress PEs discover the P2MP FEC when the application is global table multicast over an MPLS-capable infrastructure. For the rest of the doc, we'll just call this app "global table multicast" 🧚
When Protocol Independent Multicast - Sparse Mode (PIM-SM) is used for non-bidirectional ASM ("Any Source Multicast") group addresses, this document refers to it as "PIM-SM in ASM mode" ✨
If global table multicast uses PIM-SM in ASM mode, the following assumes that an inter-area P2MP service LSP could be used to carry traffic either on a shared (,G) tree or a source (S,G) tree. There MAY exist a distinct inter-area P2MP service LSP for each such P2MP FEC, or multiple such FECs MAY be carried over a single P2MP service LSP using a wildcard (,*) S-PMSI [RFC6625]. Two options, both valid, very flexible 💖
An egress PE learns the (S/,G) of a multicast stream as a result of receiving IGMP or PIM messages on one of its IP multicast interfaces. That (S/,G) forms the P2MP FEC of the inter-area P2MP service LSP. 🦋
Note that this document does not require the use of (*,G) inter-area P2MP service LSPs when global table multicast uses PIM-SM in ASM mode. In fact, PIM-SM in ASM mode may be supported entirely by using only (S,G) inter-area P2MP service LSPs. Which is honestly so chill 🫶
6. Egress PE/ASBR Signaling Procedures 💅
This section covers the egress PE/ASBR procedures for building segmented inter-area P2MP LSPs. These procedures apply no matter whether the egress PE/ASBR is in a leaf IGP area, the backbone area, or even the same IGP area as the ingress PE/ASBR. Every case, no exceptions 👑
An egress PE/ASBR only applies the procedures in this section to MVPN I-PMSI or S-PMSI A-D routes if those routes carry the Inter-Area P2MP Segmented Next-Hop Extended Community. An egress PE only applies them to VPLS A-D routes or VPLS S-PMSI A-D routes if those routes carry that same Extended Community. No Extended Community, no party 🎉
To support global table multicast, an egress PE MUST be auto-configured to import routes that carry an AS-specific Route Target Extended Community ([RFC4360]) with the Global Administrator field set to the AS of the PE and the Local Administrator field set to 0. Must-have setup, non-negotiable 🔥
Once an egress PE/ASBR discovers the P2MP FEC of an inter-area segmented P2MP service LSP, it MUST propagate this P2MP FEC in BGP in order to construct the segmented inter-area P2MP service LSP. That propagation uses BGP Leaf A-D routes. It's the whole group chat sharing the tea 🍵
6.1. Determining the Upstream ABR/PE/ASBR (Upstream Node) 🧚
An egress PE/ASBR discovers the P2MP FEC of an inter-area P2MP segmented service LSP as described in Section 5. Once it has that FEC, it MUST determine the upstream node to reach it. If the egress PE/ASBR and the ingress PE/ASBR aren't in the same area, and the egress PE/ASBR isn't in the backbone IGP area, then the upstream node would be an egress ABR. If the egress PE/ASBR is in the backbone area and the ingress PE/ASBR isn't in the backbone area, then the upstream node would be an ingress ABR. And if the egress PE/ASBR is in the same area as the ingress PE/ASBR, the upstream node would just be the ingress PE/ASBR. Easy to follow, very neat 🌸
6.1.1. Upstream Node for MVPN or VPLS 🎀
For MVPN or VPLS, the upstream node's IP address is whatever IP address is in the Global Administrator field of the Inter-Area P2MP Segmented Next-Hop Extended Community. As described in Section 5, this Extended Community MUST be carried in the MVPN or VPLS A-D route that the P2MP FEC of the inter-area P2MP segmented service LSP gets determined from. Your breadcrumbs, bestie 🍞
6.1.2. Upstream Node for Global Table Multicast ✨
For global table multicast, the unicast routes to multicast sources/RPs SHOULD carry the "VRF Route Import" Extended Community [RFC6514], with the IP address in the Global Administrator field set to the IP address of the PE or ASBR advertising the unicast route. The Local Administrator field of this Extended Community MUST be set to 0. (Plot twist: this is different from MVPN, where the Local Administrator field carries a non-zero value that identifies a particular VRF on a PE that originates VPN-IP routes 🙈.) If it isn't desirable to advertise the VRF Route Import Extended Community in unicast routes, then unicast routes to multicast sources/RPs MUST be advertised using the multicast Subsequent Address Family Identifier (SAFI), i.e., SAFI 2, and such routes MUST carry the VRF Route Import Extended Community.
Further, for global table multicast, the BGP unicast routes that advertise the routes to the IP addresses of PEs/ASBRs/ABRs SHOULD carry the Inter-Area P2MP Segmented Next-Hop Extended Community. The IP address in the Global Administrator field of this Extended Community MUST be set to the IP address of the PE, ASBR, or ABR advertising the unicast route. The Local Administrator field of this Extended Community MUST be set to 0. If it isn't desirable to advertise the Inter-Area P2MP Segmented Next-Hop Extended Community in BGP unicast routes, then the BGP unicast routes to the IP addresses of PEs/ASBRs/ABRs MUST be advertised using the multicast SAFI, i.e., SAFI 2, and such routes MUST carry the Inter-Area P2MP Segmented Next-Hop Extended Community. The procedures for handling the BGP Next Hop attribute of SAFI 2 routes are the same as those for regular unicast routes, and they MAY follow [SEAMLESS-MPLS]. So many acronyms, but it's giving organized 💜
For global table multicast, to determine the upstream node address, the egress PE first figures out the ingress PE. To do that, the egress PE determines the best route to reach the S/RP. The ingress PE address is whatever IP address is in the Global Administrator field of the VRF Route Import Extended Community carried in that route. Then the egress PE finds the best unicast route to reach the ingress PE. The upstream node address is whatever IP address is in the Global Administrator field of the Inter-Area P2MP Segmented Next-Hop Extended Community carried in that route. It's a whole treasure hunt and I'm here for it 🦋
6.2. Originating a Leaf A-D Route 🫶
If the P2MP FEC was derived from an MVPN or VPLS A-D route, and that route carries a PMSI Tunnel attribute with the "Leaf Information Required" flag set, then the egress PE MUST originate a Leaf A-D route.
If the P2MP FEC was derived from a global table multicast (S/*,G), and the upstream node's address is not the same as the egress PE, then the egress PE MUST originate a Leaf A-D route. Same rule, different app, still iconic 💅
6.2.1. Leaf A-D Route for MVPN and VPLS 🌈
If the P2MP FEC was derived from MVPN or VPLS A-D routes, then the Route Key field of the Leaf A-D route contains the NLRI of the A-D route the P2MP FEC came from. This follows the procedures for constructing Leaf A-D routes described in [RFC6514] [RFC7117]. Copy the homework, get the A+ 🍓
6.2.2. Leaf A-D Route for Global Table Multicast ✨
Okay bestie, this is the part for global table multicast 🌍. If the application is global table multicast, the MCAST-VPN NLRI of the Leaf A-D route gets built like this 💅
The Route Key field of the MCAST-VPN NLRI has this format 🎀:
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Multicast Source Length (1 octet) |
+-----------------------------------+
| Multicast Source (Variable) |
+-----------------------------------+
| Multicast Group Length (1 octet) |
+-----------------------------------+
| Multicast Group (Variable) |
+-----------------------------------+
| Ingress PE's IP Address |
+-----------------------------------+So the RD is set to 0 for (S,G) state and to all ones for (,G) state 🦋. The Multicast Source is set to S for (S,G) state or to RP for (,G) state, and the Multicast Group is set to G. The Multicast Source Length and Multicast Group Length are both set to either 4 or 16, depending on whether the S/RP and G are IPv4 or IPv6 addresses.
The Ingress PE's IP address gets determined the way Section 6.1 explains 🧚. The Originating Router's IP Address field of the MCAST-VPN NLRI is set to the address of the local PE, which is the PE that originates the route.
So the whole MCAST-VPN NLRI of the route looks like this 👑:
+-----------------------------------+
| Route Type = 4 (1 octet) |
+-----------------------------------+
| Length (1 octet) |
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Multicast Source Length (1 octet) |
+-----------------------------------+
| Multicast Source (Variable) |
+-----------------------------------+
| Multicast Group Length (1 octet) |
+-----------------------------------+
| Multicast Group (Variable) |
+-----------------------------------+
| Ingress PE's IP Address |
+-----------------------------------+
| Originating Router's IP Address |
+-----------------------------------+Now, the encoding for these global table Leaf A-D routes is different from the encoding used by the Leaf A-D routes that get sent back for S-PMSI or I-PMSI A-D routes 🙈. A router can tell the two apart by checking the third octet of the MCAST-VPN NLRI. If that octet is 0x01, 0x02, or 0x03, the Leaf A-D route was originated in response to an S-PMSI or I-PMSI A-D route. If that octet is either 0x00 or 0xff, and octets 3 through 10 are all 0x00 or all 0xff, then it's a Leaf A-D route used for global table multicast 💜.
When the PE deletes (S,G)/(*,G) state that it created because it got PIM or IGMP messages on one of its IP multicast interfaces, and it had previously originated a Leaf A-D route for that state, the PE SHOULD withdraw that route 🧹.
An AS with an IPv4 network can provide global table multicast for customers that use IPv6, and an AS with an IPv6 network can do the same for customers that use IPv4 🌈. Because of that, the address family of the Ingress PE's IP Address field and the Originating Router's IP Address field in these Leaf A-D routes MUST NOT be inferred from the AFI field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI attribute 🚫. The address family comes from the length of the address instead: 4 octets for IPv4 addresses, or 16 octets for IPv6 addresses.
For example, say an AS with an IPv4 network is giving IPv6 multicast service to a customer. The Ingress PE's IP Address and the Originating Router's IP Address in the Leaf A-D routes used for IPv6 global table multicast will be 4-octet IPv4 addresses, even though the AFI of those routes has the value 2 💀.
Note that the Ingress PE's IP Address and the Originating Router's IP Address have to be either both IPv4 or both IPv6, so they're always the same length 🫶. The Multicast Source and Multicast Group fields are variable-length and each has its own Length field. From those two Length fields and the Length field of the MCAST-VPN NLRI, you can work out how long the Ingress PE's IP Address and Originating Router's IP Address fields are. If the computed length of those fields is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered to be "incorrect", and MUST be handled as specified in Section 7 of [RFC4760] 😭.
6.2.3. Constructing the Rest of the Leaf A-D Route 🛠️
The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD be set to the same IP address that's carried in the Originating Router's IP Address field of the route 🍓.
When ingress replication is used to set up the egress area segment, the Leaf A-D route MUST carry a downstream-assigned label in the PMSI Tunnel attribute, where the PMSI Tunnel Type is set to ingress replication 🔥. Also, a PE MUST assign a distinct MPLS label for each Leaf A-D route it originates 🎀.
To keep this route from going everywhere, the originating PE builds an IP-based Route Target Extended Community. It puts the IP address of the upstream node in the Global Administrator field and sets the Local Administrator field of that community to 0. Then it adds this Route Target Extended Community to the Leaf A-D route 🎯. The upstream node's address is determined as specified in Section 6.1.
Then the PE advertises this route to the upstream node 🚀.
6.3. PIM-SM in ASM Mode for Global Table Multicast 🌸
This spec gives you two options for supporting global table multicast that gets started using PIM-SM in ASM mode 🧩. The first option doesn't carry IP multicast shared trees over the MPLS network. The second option does carry shared trees over the MPLS network, and it supports switching from shared trees to source trees 🦋.
6.3.1. Option 1 💖
This option doesn't carry IP multicast shared trees over the MPLS network 🙅♀️. So when an (egress) PE creates (*,G) state (because it got PIM or IGMP messages on one of its IP multicast interfaces), the PE doesn't propagate that state using Leaf A-D routes.
6.3.1.1. Originating Source Active A-D Routes 📣
Whenever an RP that's co-located with a PE discovers a new multicast source (by receiving PIM Register or MSDP messages), the RP/PE SHOULD originate a BGP Source Active A-D route ✨. Similarly, whenever a PE that isn't configured as an RP discovers a new multicast source because it received MSDP messages, that PE SHOULD originate a BGP Source Active A-D route too. The BGP Source Active A-D route carries a single MCAST-VPN NLRI, built like this:
- The RD in this NLRI is set to 0.
- The Multicast Source field MUST be set to S. The Multicast Source Length field is set appropriately to reflect this.
- The Multicast Group field MUST be set to G. The Multicast Group Length field is set appropriately to reflect this.
The Route Target of this Source Active A-D route is an AS-specific Route Target Extended Community. Its Global Administrator field is set to the AS of the advertising RP/PE, and its Local Administrator field is set to 0 🎀.
To keep the Source Active A-D route inside the AS of the advertising RP, this route SHOULD carry the NO_EXPORT Community ([RFC1997]) 🔒.
Using the normal BGP procedures, the Source Active A-D route gets propagated to all the other PEs within the AS 🌐.
Whenever the RP/PE finds out that the source isn't active anymore, the RP MUST withdraw the Source Active A-D route, if the RP had previously advertised one 🧹.
6.3.1.2. Receiving BGP Source Active A-D Route by PE 👀
When an egress PE gets PIM or IGMP messages on one of its IP multicast interfaces, and it creates a new (*,G) entry in its Tree Information Base (TIB) with a non-empty outgoing interface list containing one or more IP multicast interfaces, the PE MUST check if it has any Source Active A-D routes for that G 🔍. If there is such a route, S of that route is reachable via an MPLS interface, and the PE doesn't have (S,G) state in its TIB for the (S,G) carried in the route, then the PE originates a Leaf A-D route carrying that (S,G), as specified in Section 6.2.2 💫.
When an egress PE receives a new Source Active A-D route, the PE MUST check if its TIB contains a (*,G) entry with the same G as the one carried in the Source Active A-D route 🧐. If that entry is found, S is reachable via an MPLS interface, and the PE doesn't have (S,G) state in its TIB for the (S,G) carried in the route, then the PE originates a Leaf A-D route carrying that (S,G), as specified in Section 6.2.2 🥰.
6.3.1.3. Handling (S,G,rpt) State 🌙
Creating and deleting (S,G,rpt) state on a PE, when that state comes from PIM messages on one of its IP multicast interfaces, doesn't cause any BGP actions by the PE 😌.
6.3.2. Option 2 🦄
This option does carry IP multicast shared trees over the MPLS network 🌈. So when an egress PE creates (*,G) state (because it got PIM or IGMP messages on one of its IP multicast interfaces), the PE does propagate that state using Leaf A-D routes 🚀.
6.3.2.1. Originating Source Active A-D Routes 📡
Whenever a PE creates an (S,G) state because it received Leaf A-D routes associated with the global table multicast service, the PE MUST originate a BGP Source Active A-D route, provided that S is reachable via one of the IP multicast-capable interfaces and the PE determines that G is in the PIM-SM in ASM mode range 🎯. The route carries a single MCAST-VPN NLRI, built like this:
- The RD in this NLRI is set to 0.
- The Multicast Source field MUST be set to S. The Multicast Source Length field is set appropriately to reflect this.
- The Multicast Group field MUST be set to G. The Multicast Group Length field is set appropriately to reflect this.
The Route Target of this Source Active A-D route is an AS-specific Route Target Extended Community. Its Global Administrator field is set to the AS of the advertising PE, and its Local Administrator field is set to 0 🎀.
To keep the Source Active A-D route inside the AS of the advertising PE, this route SHOULD carry the NO_EXPORT Community [RFC1997] 🔐.
Using the normal BGP procedures, the Source Active A-D route gets propagated to all the other PEs within the AS 🌐.
Whenever the PE deletes the (S,G) state that it previously created because it received a Leaf A-D route for (S,G), the PE that deletes the state MUST also withdraw the Source Active A-D route, if one was advertised when the state was created 💔.
6.3.2.2. Receiving BGP Source Active A-D Route 💌
Receiving BGP Source Active A-D routes works the same way as in Option 1 ✨.
6.3.2.3. Pruning Sources Off the Shared Tree 🌊
okay bestie, so picture this 💅 once a PE gets a brand new Source Active A-D route for (S,G), it runs a quick vibe check on itself. Does it have the (*,G) entry in its TIB? ✅ Does that entry's incoming interface (iif) list include one of the IP interfaces? ✅ Is an MPLS LSP sitting in the outgoing interface (oif) list? ✅ And is the PE NOT originating a Leaf A-D route for (S,G)? ✅ If all four check out, the PE MUST transition the (S,G,rpt) downstream state to the Prune state. 🫶 Conceptually, the PIM state machine on the PE acts "as if" it got a Prune(S,G,Rpt) from some other PE, even though it never actually got one. Depending on what the (S,G,rpt) state looks like on the iifs, this can make the PE use regular PIM procedures to prune S off the Shared (*,G) tree. 🌸
Now, switching into the Prune state SHOULD happen after a delay that a timer controls ⏰ and the timer's value MUST be configurable. ✨ The whole point of that timer is to make sure S doesn't get pruned off the shared tree until every PE has had time to receive the Source Active A-D route for (S,G). No rushing, no drama. 🦋
Once the PE is in the Prune state, it MUST keep the (S,G,rpt) downstream state machine there for as long as all of these are still true: (a) the outgoing interface list (oif) for (*,G) has an MPLS LSP in it, (b) the PE has at least one Source Active A-D route for (S,G), and (c) the PE is not originating the Leaf A-D route for (S,G). 💜 The second any of those stops being true, the PE MUST transition the (S,G,rpt) downstream state machine to the NoInfo state. Bye-bye, prune 👋
Here's the tea 🍵 apart from that first paragraph's scenario, relying only on PIM procedures on the PE is enough to get the right behaviour when pruning sources off the shared tree. Iconic, honestly. 👑
6.3.2.4. More on Handling (S,G,rpt) State
no cap, this one's short and sweet 🍓 creating and deleting (S,G,rpt) state on a PE because of PIM messages that came in on one of its IP multicast interfaces does NOT trigger any BGP actions from the PE. Totally separate lanes 🛣️ PIM stuff stays in PIM land.
7. Egress ABR Procedures 👑
okay so this section is all about the egress ABR procedures for building segmented inter-area P2MP LSPs. Let's gooo 🚀
7.1. Handling Leaf A-D Route on Egress ABR
bestie, when an egress ABR gets a Leaf A-D route AND the Route Target Extended Community on that route has the IP address of this ABR in it, the following procedures kick in 🎀
Okay, the third octet of the MCAST-VPN NLRI on the received Leaf A-D route tells us a lot. If it's 0x01, 0x02, or 0x03, that means the Leaf A-D route was originated in response to an S-PMSI or I-PMSI A-D route (see Section 6.2.2) 🔍 In that case, the egress ABR MUST find an S-PMSI or I-PMSI route whose NLRI matches the Route Key field of the received Leaf A-D route. If it finds one, then the Leaf A-D route MUST be accepted ✅ And if it's accepted, and it's either the first Leaf A-D route update for that Route Key field or the withdrawal of the last Leaf A-D route for it, then these procedures run:
If the RD of the received Leaf A-D route is all zeros or all ones, then it's for the global table multicast service 🌈
If the received Leaf A-D route is the first Leaf A-D route update for the Route Key field in the route, the egress ABR originates its own Leaf A-D route, with an MCAST-VPN NLRI built like this 🧚
The Route Key field of the MCAST-VPN NLRI is the same as the Route Key field of the MCAST-VPN NLRI on the received Leaf A-D route. The Originating Router's IP Address field is set to the address of the local ABR (the ABR that originates the route) 💖
The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD be set to the same IP address as the one in the Originating Router's IP Address field of the route. 🫶
To keep distribution of this route nice and tight 🎯 the originating egress ABR builds an IP-based Route Target Extended Community by putting the IP address of the upstream node in the Global Administrator field, with the Local Administrator field set to 0. Then it sets the Extended Communities attribute of this Leaf A-D route to that Extended Community.
The upstream node's IP address is whatever comes out of the Global Administrator field of the Inter-Area P2MP Segmented Next-Hop Extended Community. Where does that Extended Community come from? 🤔 When the Leaf A-D route is for MVPN or VPLS, it's the one carried in the I-PMSI/S-PMSI A-D route that matches the Leaf A-D route. When the Leaf A-D route is for global table multicast, it's the one carried in the best unicast route to the Ingress PE. The Ingress PE address comes from the received Leaf A-D route. And the best unicast route MUST first be determined from multicast SAFI, i.e., SAFI 2 routes, if they're present. 💅
After that, the ABR advertises this Leaf A-D route to the upstream node in the backbone area 📣
Mechanisms specified in [RFC4684] for constrained BGP route distribution can be used along with this specification to make sure only the needed PE/ABR has to process a given Leaf A-D route. 💜
When ingress replication is used to set up the backbone area segment, the Leaf A-D route originated by the egress ABR MUST carry a downstream-assigned label in the PMSI Tunnel attribute, where the Tunnel Type is set to ingress replication. And the ABR MUST assign a distinct MPLS label for each Leaf A-D route it originates. Every route gets its own label, no sharing 🏷️
For global table multicast support, an egress ABR MUST auto-configure an import AS-based Route Target Extended Community, with the Global Administrator field set to the AS of the ABR and the Local Administrator field set to 0. ✨
Last but not least 🥹 if the received Leaf A-D route is the withdrawal of the last Leaf A-D route for the Route Key in the route, then the egress ABR must withdraw the Leaf A-D route tied to that Route Key that it previously advertised in the backbone area. Clean up, clean up, everybody clean up 🧹
7.2. P2MP LSP as the Intra-Area LSP in the Egress Area
okay so this section is about using intra-area P2MP LSPs in the egress area 🦋 First up, the procedures that both P2MP RSVP-TE and P2MP LDP share, then the bits that are specific to each signaling protocol.
When P2MP LSPs are used as the intra-area LSPs, keep in mind that one existing intra-area P2MP LSP might serve just one particular inter-area P2MP service LSP, or it might serve a bunch of them 🌷
The choice between the two options is purely local to the egress ABR, so it's totally up to it 🙌 Option one gives you one-to-one mapping between inter-area P2MP service LSPs and intra-area P2MP LSPs. Option two gives you many-to-one mapping, which lets you aggregate forwarding state. Efficiency queen behaviour 👑
7.2.1. Received Leaf A-D Route Is for MVPN or VPLS
If the third octet of the MCAST-VPN NLRI on the received Leaf A-D route is 0x01, 0x02, or 0x03, that means it was originated in response to an MVPN or VPLS S-PMSI or I-PMSI A-D route (see Section 6.2.2) 💖 In this case, the ABR MUST re-advertise, in the egress area, the MVPN/VPLS A-D route that matches the Leaf A-D route. This signals the binding of the intra-area P2MP LSP to the inter-area P2MP service LSP. And it must be done if and only if (a) that binding hasn't already been advertised, or (b) the binding has changed. The re-advertised route MUST carry the Inter-area P2MP Segmented Next-Hop Extended Community.
The PMSI Tunnel attribute of the re-advertised route names either an intra-area P2MP RSVP-TE LSP or an intra-area P2MP LDP LSP rooted at the ABR, and it MUST also carry an upstream-assigned MPLS label 🏷️ That upstream-assigned MPLS label MUST be set to Implicit NULL if the mapping between the inter-area P2MP service LSP and the intra-area P2MP LSP is one-to-one. If the mapping is many-to-one, the intra-area segment of the inter-area P2MP service LSP (called the "inner" P2MP LSP) gets built by nesting it inside an intra-area P2MP LSP (called the "outer" intra-area P2MP LSP). That nesting uses P2MP LSP hierarchy based on upstream-assigned MPLS labels [RFC5332]. Russian-doll energy 🪆
If segments of multiple MVPN or VPLS S-PMSI service LSPs ride over a given intra-area P2MP LSP, then each of those segments MUST carry a distinct upstream-assigned label. That's true even when all of these service LSPs are for (C-S/,C-G/)s from the same MVPN/VPLS. So an ABR keeps Label Forwarding Information Base (LFIB) state for each such S-PMSI traversing it, which applies to both the ingress and the egress ABRs. ✨ Lots of bookkeeping, but it's giving organised.
7.2.2. Received Leaf A-D Route Is for Global Table Multicast
When the RD of the received Leaf A-D route is all zeros or all ones, this means the inter-area P2MP service LSP is tied to the global table multicast service 🌍 The procedures for that are below.
7.2.2.1. Global Table Multicast and S-PMSI A-D Routes
okay this part only applies if you want to send a particular (S,G) or (*,G) global table multicast flow only to the egress PEs that actually have receivers for it 🎯 Super targeted, very efficient, very chic.
If the egress ABR hasn't previously received (and re-advertised) an S-PMSI A-D route for that (S,G) or (*,G) originated by an ingress PE/ASBR (see Section 9.1), then the egress ABR MUST originate an S-PMSI A-D route. The PMSI Tunnel attribute of that route MUST contain the identity of the intra-area P2MP LSP and an upstream-assigned MPLS label (although this label may be an Implicit NULL -- see Section 3). The RD, Multicast Source Length, Multicast Source, Multicast Group Length (1 octet), and Multicast Group fields of the NLRI on this route are the same as the ones on the received Leaf A-D route. The Originating Router's IP Address field in the S-PMSI A-D route matches the Ingress PE's IP Address field in the received Leaf A-D route 🧭 The Route Target of this route is an AS-specific Route Target Extended Community, with the Global Administrator field set to the AS of the advertising ABR and the Local Administrator field set to 0. The route MUST carry the Inter-Area P2MP Segmented Next-Hop Extended Community, and that Extended Community gets built following the procedures in Section 4. 💅
The egress ABR MUST advertise this route into the egress area. PEs in the egress area that take part in the global table multicast will import it based on the Route Target carried by the route 📬
And finally, a PE in the egress area that originated the Leaf A-D route SHOULD join the P2MP LSP advertised in the PMSI Tunnel attribute of the S-PMSI A-D route. That's the big finale, bestie 🎆 we're literally almost at the end of the protocol 🫶
7.2.2.2. Global Table Multicast and Wildcard S-PMSI A-D Routes 🎀
Okay so it may be desirable for an ingress PE to cram multiple multicast flows tied to global table multicast into the same inter-area P2MP service LSP 🦋 The trick is a wildcard, aka the (,) S-PMSI A-D route [RFC6625]. An ingress PE MAY advertise a wildcard S-PMSI A-D route as described in Section 9 ✨
If the ingress PE originates a wildcard S-PMSI A-D route, and the egress ABR gets that route from the ingress ABR, then the egress ABR has two options 💅
- (a) It MUST re-advertise this route into the egress area. The PMSI Tunnel attribute carries the identifier of the intra-area P2MP LSP in the egress area, plus an upstream-assigned label that was assigned to the inter-area wildcard S-PMSI. This label may be an Implicit NULL (see Section 3) 🧚
- (b) It MUST be able to disaggregate the traffic carried over the wildcard S-PMSI onto the egress area (S,G) or (*,G) S-PMSIs. Heads up: the disaggregation procedures need IP processing on the egress ABRs 👀
If the egress ABR advertises a wildcard S-PMSI A-D route into the egress area, this route MUST carry an AS-specific Route Target Extended Community. Its Global Administrator field is set to the AS of the advertising ABR, and its Local Administrator field is set to 0 🌸 PEs in the egress area that take part in global table multicast will import this route 🫶
A PE in the egress area SHOULD join the P2MP LSP advertised in the PMSI Tunnel attribute of the wildcard S-PMSI A-D route if both of these are true 💖
- (a) The
Originating Router's IP Addressfield in the S-PMSI A-D route has the same value as the Ingress PE's IP Address in at least one of the Leaf A-D routes for global table multicast that the PE originated. - (b) The upstream ABR for the Ingress PE's IP address in that Leaf A-D route is the egress ABR that advertises the wildcard S-PMSI A-D route.
7.2.3. Global Table Multicast and the Expected Upstream Node 🔥
If the mapping between the inter-area P2MP service LSP for global table multicast and the intra-area P2MP LSP is many-to-one, then an egress PE must be able to figure out whether a given multicast packet for a particular (S,G) came from the "expected" upstream node 🕵️♀️ The expected node is the one the egress PE sends its Leaf A-D route toward. Packets that arrive from some other upstream node for that (S,G) MUST be dropped 💀 To let the egress PE work out who sent the packet, the intra-area P2MP LSP MUST be signaled with no Penultimate Hop Popping (PHP) whenever that many-to-one mapping applies 👑
Also, the egress ABR MUST first push the upstream-assigned label advertised in the S-PMSI A-D route onto the label stack, but only if that label is not the Implicit NULL 🧁
7.2.4. P2MP LDP LSP as the Intra-Area P2MP LSP 🌈
The above procedures are sufficient if P2MP LDP LSPs are used as the intra-area P2MP LSP in the egress area ✨
7.2.5. P2MP RSVP-TE LSP as the Intra-Area P2MP LSP 🦋
If a P2MP RSVP-TE LSP is used as the intra-area LSP in the egress area, the egress ABR has two choices 🎀
- (a) It can graft the leaf (whose IP address is in the received Leaf A-D route) onto an existing P2MP LSP rooted at the egress ABR, then use that LSP to carry traffic for the inter-area segmented P2MP service LSP.
- (b) It can originate a brand new P2MP LSP to carry (S,G).
When the RD of the received Leaf A-D route is all zeros or all ones, the procedures are the ones in Section 7.2.2 💅
Also, fyi, the SESSION object that the egress ABR would use for the intra-area P2MP LSP does not need to encode the P2MP FEC from the received Leaf A-D route 🙈
7.3. Ingress Replication in the Egress Area 🍓
When ingress replication is used to set up the egress area segment, the Leaf A-D route the egress PE advertises MUST carry a downstream-assigned label in the PMSI Tunnel attribute, where the Tunnel Type is set to ingress replication. We'll call this label the egress PE downstream-assigned label 🫶
The egress ABR MUST forward packets it receives from the backbone area intra-area segment, for a particular inter-area P2MP LSP, to every egress PE from which the egress ABR has imported a Leaf A-D route for that inter-area P2MP LSP. Each packet sent to a particular egress PE gets encapsulated by the egress ABR with an MPLS label stack whose bottom label is the egress PE downstream-assigned label. The top label is the P2P RSVP-TE or MP2P LDP label used to reach the egress PE 🧚
Note that these procedures make sure an egress PE only ever receives packets from the upstream node it expects 💖
8. Ingress ABR Procedures 👑
When an ingress ABR receives a Leaf A-D route, and the Route Target Extended Community carried by that route contains this ABR's IP address, the ingress ABR follows the same procedures as in Section 7. The only swaps are egress ABR becomes ingress ABR, backbone area becomes ingress area, and backbone area segment becomes ingress area segment 🔁
To support global table multicast, the ingress ABR MUST be auto-configured with an import AS-based Route Target Extended Community. Its Global Administrator field is set to the AS of the ABR, and its Local Administrator field is set to 0 🌸
8.1. P2MP LSP as the Intra-Area LSP in the Backbone Area 🌊
The procedures for binding the backbone area segment of an inter-area P2MP LSP to the intra-area P2MP LSP in the backbone area are the same as in Sections 7 and 7.2. The swaps here are egress PE becomes egress ABR, egress ABR becomes ingress ABR, and egress area becomes backbone area. This applies to inter-area P2MP LSPs tied to MVPN, VPLS, or global table multicast alike 🦋
It's worth noting that, for global table multicast, if the backbone area uses wildcard S-PMSI, then the egress area SHOULD also use wildcard S-PMSI for global table multicast. Otherwise, the egress ABRs MUST be able to disaggregate the traffic carried over the wildcard S-PMSI onto the egress area (S,G) or (*,G) S-PMSIs. Once again, that disaggregation needs IP processing on the egress ABRs 👀
8.2. Ingress Replication in the Backbone Area 🧁
When ingress replication is used to set up the backbone area segment, the Leaf A-D route the egress ABR advertises MUST carry a downstream-assigned label in the PMSI Tunnel attribute, where the Tunnel Type is set to ingress replication. We'll call this the egress ABR downstream-assigned label. The egress ABR MUST assign a distinct MPLS label for each Leaf A-D route it originates ✨
The ingress ABR MUST forward packets it receives from the ingress area intra-area segment, for a particular inter-area P2MP LSP, to every egress ABR from which the ingress ABR has imported a Leaf A-D route for that inter-area P2MP LSP. Each packet sent to a particular egress ABR gets encapsulated by the ingress ABR with an MPLS label stack whose bottom label is the egress ABR downstream-assigned label 🎀
The top label is the P2P RSVP-TE or MP2P LDP label used to reach the egress ABR 💜
9. Ingress PE/ASBR Procedures 💅
This section describes the ingress PE/ASBR procedures for building segmented inter-area P2MP LSPs 🦋
When an ingress PE/ASBR receives a Leaf A-D route, and the Route Target Extended Community carried by that route contains this PE/ASBR's IP address, the following procedures get executed 🔥
If the third octet of the MCAST-VPN NLRI of the received Leaf A-D route is 0x01, 0x02, or 0x03, that tells us the Leaf A-D route was originated in response to an S-PMSI or I-PMSI A-D route (see Section 6.2.2) 🕵️♀️ In this case, the ingress PE/ASBR MUST find an S-PMSI or I-PMSI route whose NLRI has the same value as the Route Key field of the received Leaf A-D route. If a matching route is found, the Leaf A-D route MUST be accepted. If not, it MUST be discarded. If the Leaf A-D route is accepted, it MUST be processed as per MVPN or VPLS procedures 🙌
If the RD of the received A-D route is set to all zeros or all ones, then the received Leaf A-D route is for the global table multicast service 🌈 If this is the first Leaf A-D route for the Route Key carried in the route, the PIM implementation MUST set its upstream (S/RP,G) state machine to Joined state for the (S/RP,G) received via a Leaf A-D route update. Likewise, if this is the withdrawal of the last Leaf A-D route whose Route Key matches a particular (S/RP,G) state, the PIM implementation MUST set its upstream (S/RP,G) state machine to Prune state for that (S/RP,G) 🧚
9.1. P2MP LSP as the Intra-Area LSP in the Ingress Area 🌸
If the third octet of the MCAST-VPN NLRI of the received Leaf A-D route is 0x01, 0x02, or 0x03 (which means the Leaf A-D route was originated in response to an S-PMSI or I-PMSI A-D route), and a P2MP LSP is used as the intra-area LSP in the ingress area, then the procedures for binding the ingress area segment of the inter-area P2MP LSP to the intra-area P2MP LSP in the ingress area are the same as in Sections 7 and 7.2 🫶
When the RD of the received Leaf A-D route is all zeros or all ones, as is the case when the inter-area service P2MP LSP is tied to global table multicast, the ingress PE MAY originate an S-PMSI A-D route. Its RD, multicast source, and multicast group fields are the same as the ones in the received Leaf A-D route 🦋
Also, for global table multicast in particular, an ingress PE MAY originate a wildcard S-PMSI A-D route using the procedures in [RFC6625], with the RD set to 0. The ingress PE can originate this route based on configuration, or based on importing a Leaf A-D route whose RD is set to 0. If an ingress PE does originate such a route, it MAY decide not to originate (S,G) or (*,G) S-PMSI A-D routes 💖
The wildcard S-PMSI A-D route MUST carry the Inter-Area P2MP Segmented Next-Hop Extended Community. This Extended Community is built following the procedures in Section 4 ✨
It's worth noting that, for global table multicast, if the ingress area uses wildcard S-PMSI, then the backbone area SHOULD also use wildcard S-PMSI for global table multicast. Otherwise, the ingress ABRs MUST be able to disaggregate the traffic carried over the wildcard S-PMSI onto the backbone area (S,G) or (*,G) S-PMSIs. Yep, that disaggregation needs IP processing on the ingress ABRs 👀
9.2. Ingress Replication in the Ingress Area 🍓
When ingress replication is used to set up the ingress area segment, the Leaf A-D route the ingress ABR advertises MUST carry a downstream-assigned label in the PMSI Tunnel attribute, where the Tunnel Type is set to ingress replication. We'll call this the ingress ABR downstream-assigned label. The ingress ABR MUST assign a distinct MPLS label for each Leaf A-D route it originates 🎀
The ingress PE/ASBR MUST forward packets it receives from the CE, for a particular inter-area P2MP LSP, to every ingress ABR from which the ingress PE/ASBR has imported a Leaf A-D route for that inter-area P2MP LSP. Each packet sent to a particular ingress ABR gets encapsulated by the ingress PE/ASBR with an MPLS label stack whose bottom label is the ingress ABR downstream-assigned label 🧁
The top label is the P2P RSVP-TE or MP2P LDP label used to reach the ingress ABR 🌈
10. Common Tunnel Type in the Ingress and Egress Areas ✨
okay so for a given inter-area service P2MP LSP, the PE/ASBR that's the root of that LSP decides the type of the intra-area P-tunnel carrying the ingress area segment 💅 but the backbone area segment can use a different tunnel type than the ingress and egress segments, which is totally allowed 🫶 so if you actually want the same tunnel type on both the ingress side and the egress side, the ingress ABR and egress ABR procedures below make that happen 🎀
When an ingress ABR re-advertises a BGP MVPN I-PMSI, S-PMSI A-D route, or VPLS A-D route into the backbone area, it takes the PMSI Tunnel attribute from that route and puts it into the ATTR_SET BGP attribute [RFC6368]. Then it adds that ATTR_SET to the re-advertised route and swaps the original PMSI Tunnel attribute for a brand new one 🦋 the Tunnel Type of the new attribute can be different from the Tunnel Type of the original one, so don't be surprised if they don't match 😭
When an egress ABR re-advertises a BGP MVPN I-PMSI or S-PMSI A-D route, or a VPLS A-D route, into the egress area, the ABR checks whether the route has the ATTR_SET BGP attribute [RFC6368]. If it does, the ABR sets the Tunnel Type of the PMSI Tunnel attribute in the re-advertised route to the Tunnel Type stored in the ATTR_SET, and then removes the ATTR_SET from the route 💖
11. Placement of Ingress and Egress PEs 🌈
as we covered in the earlier sections, the procedures in this document let you put ingress and egress PEs in the backbone area 🙌 they also let you put egress PEs in the ingress area, or ingress PEs in the egress area 🧚
for example, say you've got a global table multicast service running in the ingress and egress areas, and the data is going over PIM-based IP/GRE P-tunnels 💅 now you want that same data to cross the backbone over MPLS P-tunnels instead 👑 that works if the ABR connecting the ingress area to the backbone follows the ingress PE procedures this document specifies for the global table multicast service, and the ABR connecting the egress area to the backbone follows the egress PE procedures for that same service ✨
same deal for MVPN 🦋 if MVPN is running in the ingress and egress areas with the MVPN data inside PIM-based IP/GRE P-tunnels, this technique lets that MVPN data ride over the backbone in MPLS P-tunnels too 🫶 the PIM-based IP/GRE P-tunnels in the ingress and egress areas get treated as global table multicasts, and the ABRs supply the ingress and egress PE functionality 💜
12. MVPN with Virtual Hub-and-Spoke 🌸
the procedures in this document can be used together with the Virtual Hub-and-Spoke procedures [RFC7024] 🎀
this document doesn't put any restrictions on where Virtual Hubs and Virtual Spokes get placed 💅
on top of I-PMSI/S-PMSI A-D routes, the procedures here also apply to Associated-V-spoke-only I-PMSI A-D routes 🦋
now, in the scenario where a V-hub, after importing an S-PMSI A-D route into its VRF, originates an S-PMSI A-D route aimed at its V-spokes (as specified in Section 7.8.2 of [RFC7024]), the V-hub SHOULD be able to control, through configuration, whether the Inter-Area P2MP Segmented Next-Hop Extended Community (if the received S-PMSI A-D route has it) also gets carried in the originated S-PMSI A-D route 🤔 by default, if the received S-PMSI A-D route carries the Inter-Area P2MP Segmented Next-Hop Extended Community, the originated S-PMSI A-D route SHOULD also carry this Extended Community too 🫶
13. Data Plane 🧚
this section covers the data plane procedures on the ABRs, ingress PEs, egress PEs, and transit routers 💖
13.1. Data Plane Procedures on ABRs
when the procedures in this document are followed to signal inter-area P2MP segmented LSPs, ABRs are required to perform only MPLS switching 🔥 when an ABR gets an MPLS packet from an "incoming" intra-area segment of the inter-area P2MP segmented LSP, it forwards that packet with MPLS switching onto another "outgoing" intra-area segment of the same LSP 🦋
if the outgoing intra-area segment is instantiated using a P2MP LSP, and there's a one-to-one mapping between that outgoing segment and the P2MP LSP, then the ABR MUST pop the incoming segment's label stack and push the label stack of the outgoing P2MP LSP 💅 if there's a many-to-one mapping between outgoing intra-area segments and the P2MP LSP, then the ABR MUST pop the incoming segment's label stack, and first push the upstream-assigned label for the outgoing intra-area segment (if one has been assigned), and then push the label stack of the outgoing P2MP LSP 🌈
if the outgoing intra-area segment is instantiated using ingress replication, then the ABR must pop the incoming segment's label stack and replicate the packet once to each leaf ABR or PE of the outgoing intra-area segment 🧚 the label stack of the packet sent to each such leaf MUST first include a downstream-assigned label that the leaf assigned to the segment, followed by the label stack of the P2P or MP2P LSP to that leaf 💜
13.2. Data Plane Procedures on Egress PEs
an egress PE must first figure out which inter-area P2MP segmented LSP the packet belongs to, based on the incoming label stack 🔍 once that's identified, the egress PE must forward the packet using the application bound to that LSP ✨
heads up: the application-specific forwarding for MVPN might require the egress PE to check whether the packets came from the expected sender PE 👀 when the application is MVPN, the FEC of an inter-area P2MP segmented LSP is at the granularity of the sender PE 💅 MVPN intra-AS I-PMSI A-D routes and S-PMSI A-D routes both carry the Originating Router's IP Address 🫶 so an egress PE can link the data arriving on P-tunnels advertised by these routes to the Originating Router's IP Address carried in those routes, which is the same as the ingress PE 🦋 since each such FEC has a unique label stack associated with it, the egress PE can work out the sender PE from the label stack 💖
the same idea works for VPLS service 🌸 for MAC learning, the egress PE must be able to determine the "VE-ID" (VPLS Edge Device Identifier) that the packets were received from 🧠 the FEC of the VPLS A-D routes carries the VE-ID, so an egress PE can associate the data arriving on P-tunnels advertised by these routes with the VE-ID carried by them 🎀 and since each such FEC has a unique label stack, the egress PE can do MAC learning for packets received from a given VE-ID 💜
when the application is global table multicast, it's enough for the label stack to identify the sender upstream node 🧚 when P2MP LSPs are used, this requires that PHP MUST be turned off 🔥 when ingress replication is used, the egress PE knows the incoming downstream-assigned label it bound to a particular (S/,G), and it must accept packets with only that label for that (S/,G) 💅
13.3. Data Plane Procedures on Ingress PEs
an Ingress PE must perform the application-specific forwarding procedures to figure out the outgoing intra-area segment of an incoming packet 🔍
if the outgoing intra-area segment is instantiated using a P2MP LSP, and there's a one-to-one mapping between that segment and the P2MP LSP, then the ingress PE MUST encapsulate the packet in the label stack of the outgoing P2MP LSP 🦋 if there's a many-to-one mapping between outgoing intra-area segments and the P2MP LSP, then the PE MUST first push the upstream-assigned label for the outgoing intra-area segment (if one has been assigned), and then push the label stack of the outgoing P2MP LSP 🌈
if the outgoing intra-area segment is instantiated using ingress replication, then the PE must replicate the packet once to each leaf ABR or PE of the outgoing intra-area segment 🧚 the label stack of the packet sent to each such leaf MUST first include a downstream-assigned label that the leaf assigned to the segment, followed by the label stack of the P2P or MP2P LSP to that leaf 💖
13.4. Data Plane Procedures on Transit Routers
when the procedures in this document are followed to signal inter-area P2MP segmented LSPs, transit routers in each area perform only MPLS switching 🔥
14. Support for Inter-Area Transport LSPs 👑
this section describes OPTIONAL procedures that let multiple (inter-area) P2MP LSPs get rolled up into a single inter-area P2MP "transport LSP" 🎀 the segmentation procedures from this document then get applied to these inter-area P2MP transport LSPs, instead of being applied to each individual LSP that's been aggregated into the transport 🦋 from here on, the individual LSPs aggregated into one transport LSP are called "service LSPs" 💅
14.1. "Transport Tunnel" Tunnel Type
for the PMSI Tunnel attribute, we define a new Tunnel Type called "Transport Tunnel" 🌸 its Tunnel Identifier is a tuple <Source PE Address, Local Number> 🧠 this Tunnel Type gets the value 8 ✨ the Source PE Address is the address of the PE that originates the (service) A-D route carrying this attribute, and the Local Number is a number that's unique to that Source PE 💖 the length of the Local Number part matches the length of the Source PE Address 🫶
so if the Source PE Address is an IPv4 address, the Local Number part is 4 octets 🌈 if the Source PE Address is an IPv6 address, the Local Number part is 16 octets 💜
14.2. Discovering Leaves of the Inter-Area P2MP Service LSP
when you aggregate multiple P2MP LSPs using P2MP LSP hierarchy, figuring out the leaf nodes of the LSPs being aggregated is essential 🧠 that's how you trade off the overhead of the P2MP LSPs against suboptimal bandwidth use caused by partial congruency of the LSPs being aggregated 🌸
so if a PE that's the root of a given service P2MP LSP wants to aggregate this LSP with other (service) P2MP LSPs rooted at the same PE into an inter-area P2MP transport LSP, the PE should first determine all the leaf nodes of that service LSP, along with those of the other service LSPs being aggregated 👀
to do that, the PE sets the PMSI Tunnel attribute of the service A-D route (an I-PMSI or S-PMSI A-D route for MVPN, or a VPLS A-D route for VPLS service) associated with that LSP like this: the Tunnel Type is set to "No tunnel information present", and the "Leaf Information Required" flag is set to 1 🎀 the route MUST NOT carry the Inter-Area P2MP Segmented Next-Hop Extended Community 🙅♀️ unlike the MVPN and VPLS A-D route procedures we've covered so far, the Route Reflectors that take part in distributing this route don't need to be ABRs 🦋
14.3. Discovering P2MP FEC of P2MP Transport LSP 🦋
okay so once the ingress PE figures out all the leaves of a given P2MP service LSP, it picks (using whatever local criteria it likes 💅) one inter-area transport P2MP LSP to carry that inter-area service P2MP LSP. ✨
Once the PE picks the transport P2MP LSP, it (re-)originates the service A-D route. The PMSI Tunnel attribute on this route now carries the Tunnel Identifier of the selected transport LSP, with the Tunnel Type set to "Transport Tunnel". If the transport LSP carries multiple P2MP service LSPs, the MPLS Label field holds an upstream-assigned label that the PE assigned, bound to the P2MP FEC of the inter-area P2MP service LSP. Otherwise, this field is set to Implicit NULL. 🌸
As described earlier, this service A-D route MUST NOT carry the Inter-Area P2MP Segmented Next-Hop Extended Community, and the Route Reflectors that take part in distributing this route need not be ABRs. 🙈
14.4. Egress PE Procedures for P2MP Transport LSP 🎀
When an egress PE receives and accepts an MVPN or VPLS service A-D route, the egress PE checks two things. First, if the "Leaf Information Required" flag in the PMSI Tunnel attribute of the received A-D route is set to 1, and the route does not carry the Inter-Area P2MP Segmented Next-Hop Extended Community, then the egress PE follows the "regular" MVPN or VPLS procedures for that A-D route (as specified in [RFC6514] and [RFC7117]) and originates a Leaf A-D route. 💖
Second, if the Tunnel Type in the PMSI Tunnel attribute of the received service A-D route is set to "Transport Tunnel", the egress PE originates yet another Leaf A-D route. Two routes, bestie, that's a whole moment 👑
The format of the Route Key field of the MCAST-VPN NLRI for this additional Leaf A-D route is the same as the one defined in Section 6.2.2. The Route Key field is built like this:
RD (8 octets) - set to 0
Multicast Source Length, Multicast Source - constructed from the
Source PE Address part of the Tunnel Identifier carried in the
PMSI Tunnel attribute of the received service S-PMSI A-D
route.
Multicast Group Length, Multicast Group - constructed from the
Local Number part of the Tunnel Identifier carried in the PMSI
Tunnel attribute of the received service S-PMSI A-D route.
Ingress PE IP Address - set to the Source PE Address part of the
Tunnel Identifier carried in the PMSI Tunnel attribute of the
received service S-PMSI A-D route.When the egress PE is figuring out the upstream ABR, it follows the procedures in Section 6.1 for global table multicast. ✨ The egress PE then builds the rest of the Leaf A-D route using the procedures in Section 6.2.3. 🧚
From that point on, we follow the procedures for Leaf A-D routes for global table multicast, as outlined below. 🌈
14.5. ABRs and Ingress PE Procedures for P2MP Transport LSP 🍓
In this section, we spell out the ingress and egress ABRs, plus the ingress PE procedures for P2MP transport LSPs. Let's gooo 🚀
When an egress ABR receives the Leaf A-D route, and a P2MP LSP is being used to instantiate the egress area segment of the inter-area transport LSP, the egress ABR advertises an S-PMSI A-D route into the egress area. This route is built following the procedures in Section 7.2.2.1. The egress PE(s) import this route. 💅
The egress ABR also propagates the received Leaf A-D route into the backbone area, with appropriate modifications. This happens whether or not the egress area segment is instantiated using a P2MP LSP or ingress replication. ✨
If a P2MP LSP is used to instantiate the backbone area segment of the inter-area transport LSP, then an ingress ABR advertises an S-PMSI A-D route into the backbone area. This route is built following the procedures in Section 7.1.2.1. The egress ABR(s) import this route. 🦋
The ingress ABR also propagates the received Leaf A-D route into the ingress area, toward the ingress/root PE, with appropriate modifications. This happens whether or not the backbone area segment is instantiated using a P2MP LSP or ingress replication. 🫶
Finally, if a P2MP LSP is used to instantiate the ingress area segment, the ingress PE advertises an S-PMSI A-D route into the ingress area. The RD, multicast source, and multicast group fields of this route are the same as those in the received Leaf A-D route. The PMSI Tunnel attribute of this route contains the identity of the intra-area P2MP LSP used to instantiate the ingress area segment, plus an upstream-assigned MPLS label. The ingress ABR(s) and any other PE(s) in the ingress area will import this route. The ingress PE uses the (intra-area) P2MP LSP advertised in this route to carry traffic associated with the original service A-D route that the PE advertised. 🎀
14.6. Discussion 🧠
Okay, this is the part where the tradeoffs get spicy 🌶️ Using inter-area transport P2MP LSPs, as described in this section, adds a level of indirection between (inter-area) P2MP service LSPs and the intra-area transport LSPs that carry them. Instead of segmenting (inter-area) service P2MP LSPs and then aggregating (intra-area) segments of those service LSPs into intra-area transport LSPs, this approach first aggregates multiple (inter-area) service P2MP LSPs into a single inter-area transport P2MP LSP. It then segments those inter-area transport P2MP LSPs, and aggregates the (intra-area) segments of those inter-area transport LSPs into intra-area transport LSPs. Layers on layers, bestie 🧁
On one hand, this approach could reduce the state (and the overhead of maintaining that state) on ABRs. That's because, instead of tracking individual P2MP service LSPs, ABRs only need to track the inter-area P2MP transport LSPs. Note, though, that this reduction only happens if a single inter-area P2MP transport LSP aggregates more than one (inter-area) service LSP. Without that aggregation, inter-area transport LSPs give you no benefit and just add extra overhead 😭 And while aggregation does shrink the ABR state, it comes at a price, which we'll get into below. 💀
As we mentioned before, aggregating multiple P2MP service LSPs into a single inter-area P2MP transport LSP requires the PE rooted at those LSPs to determine all the leaf nodes of the service LSPs being aggregated. So the root PE has to track all the leaf PEs of those LSPs. By contrast, when segmentation procedures apply directly to the P2MP service LSPs, the root PE only has to track the leaf PEs in its own IGP area, plus the ingress ABR(s). An ingress ABR only has to track the egress ABRs. And an egress ABR only has to track the leaf PEs in its own area. 🌸 So while the total leaf-tracking overhead from the P2MP service LSPs is about the same in both approaches, the distribution is different. With inter-area P2MP transport LSPs, that overhead is concentrated on the ingress PE. With segmentation applied directly to the P2MP service LSPs, the overhead is spread across the ingress PE and the ABRs. ⭐
Also, when you use inter-area P2MP transport LSPs, ABRs have to carry the leaf-tracking overhead for those inter-area P2MP transport LSPs. With segmentation applied directly to the P2MP service LSPs, there's no such overhead, because there are no inter-area P2MP transport LSPs to track. 🙈
Using inter-area P2MP transport LSPs may also lead to more bandwidth inefficiency than applying segmentation procedures directly to the P2MP service LSPs. This is because, with inter-area P2MP transport LSPs, the ABRs aggregate segments of inter-area P2MP transport LSPs, rather than segments of (inter-area) P2MP service LSPs. Here's an example to show what that looks like 👀
Assume PE1 in Area 1 is an ingress PE, with two multicast streams, (C-S1, C-G1) and (C-S2, C-G2), originated by an MVPN site connected to PE1. Assume PE2 in Area 2 has an MVPN site with receivers for (C-S1, C-G1), and PE3 and PE4 in Area 3 have an MVPN site with receivers for both (C-S1, C-G1) and (C-S2, C-G2). Finally, assume PE5 in Area 4 has an MVPN site with receivers for (C-S2, C-G2). 💖
When segmentation applies directly to the P2MP service LSPs, Area 2 has just one intra-area transport LSP, carrying the egress area segment of the P2MP service LSP for (C-S1, C-G1). Area 3 has just one intra-area transport LSP, carrying the egress area segments of both the P2MP service LSP for (C-S1, C-G1) and the P2MP service LSP for (C-S2, C-G2). Area 4 has just one intra-area transport LSP, carrying the egress area segment of the P2MP service LSP for (C-S2, C-G2). Note that there is no bandwidth inefficiency in this case at all ✨
When using inter-area P2MP transport LSPs, to get the same state overhead on the routers within each of the egress areas (except for egress ABRs), PE1 would need to aggregate the P2MP service LSP for (C-S1, C-G1) and the P2MP service LSP for (C-S2, C-G2) into the same inter-area P2MP transport LSP. That aggregation would reduce state on the ABRs, but it would also cause bandwidth inefficiency. (C-S1, C-G1) would be delivered not just to PE2, PE3, and PE4, but also to PE5, which has no receivers for that stream. Likewise, (C-S2, C-G2) would be delivered not just to PE3, PE4, and PE5, but also to PE2, which has no receivers for that stream. Wasteful, bestie 😭🫠
15. IANA Considerations 📋
This document defines a new BGP Extended Community called "Inter-Area P2MP Segmented Next-Hop" (see Section 4). It may be either a Transitive IPv4-Address-Specific Extended Community or a Transitive IPv6-Address-Specific Extended Community. IANA has assigned the value 0x12 in the "Transitive IPv4-Address-Specific Extended Community Sub-Types" registry, and IANA has assigned the value 0x0012 in the "Transitive IPv6-Address-Specific Extended Community Types" registry. This document is the reference for both code points. 🎀
IANA has assigned the value 0x08 in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry [RFC7385] as "Transport Tunnel" (see Section 14). 🦋
This document makes use of a Route Distinguisher whose value is all ones. The two-octet type field of this Route Distinguisher therefore has the value 65535. IANA has assigned this value in the "Route Distinguisher Type Field" registry as "For Use Only in Certain Leaf A-D Routes", with this document as the reference. 🌈
16. Security Considerations 🚨
Procedures described in this document are subject to security threats similar to those experienced by any MPLS deployment. It is recommended that baseline security measures are considered as described in "Security Framework for MPLS and GMPLS Networks" [RFC5920], in the mLDP specification [RFC6388], and in the P2MP RSVP-TE specification [RFC3209]. The security considerations of [RFC6513] are also applicable. Please treat security like your skincare routine, bestie: non-negotiable 🧴🔒💅
17. References ✨
17.1. Normative References 📚
okay so these are the must-read docs bestie, the stuff the spec totally leans on 💅
[RFC1997]Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,<http://www.rfc-editor.org/info/rfc1997>.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,<http://www.rfc-editor.org/info/rfc2119>.[RFC3209]Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,<http://www.rfc-editor.org/info/rfc3209>.[RFC4360]Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006,<http://www.rfc-editor.org/info/rfc4360>.[RFC4456]Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,<http://www.rfc-editor.org/info/rfc4456>.[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, DOI 10.17487/RFC4684, November 2006,<http://www.rfc-editor.org/info/rfc4684>.[RFC4760]Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007,<http://www.rfc-editor.org/info/rfc4760>.[RFC4761]Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,<http://www.rfc-editor.org/info/rfc4761>.[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, DOI 10.17487/RFC4875, May 2007,<http://www.rfc-editor.org/info/rfc4875>.[RFC5036]Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007,<http://www.rfc-editor.org/info/rfc5036>.[RFC5331]Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008,<http://www.rfc-editor.org/info/rfc5331>.[RFC5332]Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, DOI 10.17487/RFC5332, August 2008,<http://www.rfc-editor.org/info/rfc5332>.[RFC6074]Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011,<http://www.rfc-editor.org/info/rfc6074>.[RFC6368]Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. Yamagata, "Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 6368, DOI 10.17487/RFC6368, September 2011,<http://www.rfc-editor.org/info/rfc6368>.[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, DOI 10.17487/RFC6388, November 2011,<http://www.rfc-editor.org/info/rfc6388>.[RFC6513]Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012,<http://www.rfc-editor.org/info/rfc6513>.[RFC6514]Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,<http://www.rfc-editor.org/info/rfc6514>.[RFC6625]Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012,<http://www.rfc-editor.org/info/rfc6625>.[RFC7117]Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014,<http://www.rfc-editor.org/info/rfc7117>.[RFC7385]Andersson, L. and G. Swallow, "IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points", RFC 7385, DOI 10.17487/RFC7385, October 2014,<http://www.rfc-editor.org/info/rfc7385>.
17.2. Informative References 🦋
these ones are the extra reading, nice to have but the spec doesn't need them to function ✨
[GTM]Zhang, J, Giuliano, L, Rosen, E., Ed., Subramanian, K., Pacella, D., and J. Schiller, "Global Table Multicast with BGP-MVPN Procedures", Work in Progress, draft-ietf-bess-mvpn-global-table-mcast-00, November 2014.[RFC5920]Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,<http://www.rfc-editor.org/info/rfc5920>.[RFC7024]Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013,<http://www.rfc-editor.org/info/rfc7024>.[SEAMLESS-MPLS]Leymann, N., Ed., Decraene, B., Filsfils, C., Konstantynowicz, M., Ed., and D. Steinberg, "Seamless MPLS Architecture", Work in Progress, draft-ietf-mpls-seamless-mpls-07, June 2014.
Acknowledgements 🫶
huge thanks to Loa Andersson and Qin Wu for reviewing this and leaving comments, you're both legends 💖
Authors' Addresses 🌸
here's where to find the people who wrote this thing, complete with all their details 💜
Yakov Rekhter
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
United States
Eric C Rosen
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
United States
EMail: erosen@juniper.net
Rahul Aggarwal
EMail: raggarwa_1@yahoo.com
Thomas Morin
Orange
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
EMail: thomas.morin@orange.com
Irene Grosclaude
Orange
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
EMail: irene.grosclaude@orange.com
Nicolai Leymann
Deutsche Telekom AG
Winterfeldtstrasse 21
Berlin 10781
Germany
EMail: n.leymann@telekom.de
Samir Saad
AT&T
EMail: samirsaad1@outlook.com📦 where this page comes from
- ietf: rfc7524 2015-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms