RFC 7524
Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)
Internet Engineering Task Force (IETF) Y. Rekhter Request for Comments: 7524 E. Rosen Category: Standards Track Juniper Networks ISSN: 2070-1721 R. Aggarwal Arktan T. Morin I. Grosclaude Orange N. Leymann Deutsche Telekom AG S. Saad AT&T May 2015 Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)Abstract
This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service label switched paths (LSPs) by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and Label Distribution Protocol (LDP). Within each IGP area, the intra-area segments are either carried over intra- area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP multipoint LDP (mLDP). If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS. 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). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained 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 ................................................42
1. Introduction
This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area, the intra-area segments are either carried over intra-area P2MP LSPs, potentially using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using 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 the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN (BGP MVPN), VPLS multicast, or global table multicast over MPLS. The primary use case of such 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 of PEs require P2MP connectivity. For instance, this may be the case when MPLS is pushed further to the metro edge and the metros are in different IGP areas. This may also be the case when a service provider's network comprises multiple IGP areas in a single AS, with a large number of PEs. Seamless MPLS is the industry term to address this case [SEAMLESS-MPLS]. Thus, one of the applicabilities of this document is that it describes the multicast procedures for seamless MPLS. It is to be noted that [RFC6514] and [RFC7117] already specify procedures for building segmented inter-AS P2MP service LSPs. This document complements those procedures, as it extends the segmented P2MP LSP model such that it is applicable to inter-area P2MP service LSPs as well. 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 constructed 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
The reader is assumed to be familiar with MVPN procedures and terminology [RFC6513] [RFC6514] and VPLS procedures and terminology [RFC7117]. This document allows Area Border Routers (ABRs), acting as Route Reflectors, to follow the procedures specified in [SEAMLESS-MPLS] when handling the BGP Next Hop of the routes to the PEs. Specifically, when reflecting such routes from the non-backbone areas into the backbone area, the ABRs MUST set the BGP Next Hop to their own loopback addresses (next-hop-self), while when reflecting such routes from the backbone area into the non-backbone areas, the ABRs SHOULD NOT change the BGP Next Hop addresses (next-hop-unchanged). While this document allows ABRs to follow the procedures specified in [SEAMLESS-MPLS], procedures specified in this document are applicable even when ABRs do not follow the procedures specified in [SEAMLESS-MPLS]. This document specifies a particular way of supporting the global table multicast service. Although the document refers to this approach simply as "global table multicast", it does not mean to imply that there are no other ways to support global table multicast. An alternative way to support global table multicast is to use the procedures for MVPN that are specified in [RFC6514] and in this document. That alternative is discussed in more detail in [GTM]. However, that alternative is not further considered in the current document. This document assumes that, in the context of global table multicast, ABRs do not carry routes to the destinations external to their own AS. Furthermore, in the context of global table multicast, this document assumes that an Autonomous System Border Router (ASBR), when re-advertising into Internal BGP (IBGP) routes received from an external speaker (received via External BGP (EBGP)), may not change the BGP Next Hop to self. Within an AS, a P2MP service LSP is partitioned into three segments: ingress area segment, backbone area segment, and egress area segment. Within each area, a segment is carried over an intra-area P2MP LSP or instantiated using ingress replication. When intra-area P2MP LSPs are used to instantiate the intra-area segments, there could be either 1:1 or n:1 mapping between intra-area segments of the inter-area P2MP service LSP and a given intra-area P2MP LSP. The latter is realized using P2MP LSP hierarchy with
upstream-assigned labels [RFC5331]. For simplicity of presentation, we assume that P2MP LSP hierarchy is used even with 1:1 mapping; in which case, an Implicit NULL is used as the upstream-assigned label. When intra-area segments of the inter-area P2MP service LSP are instantiated using ingress replication, multiple such segments may be carried in the same P2P RSVP-TE or MP2P LDP LSP. This can be achieved using downstream-assigned labels alone. The ingress area segment of a P2MP service LSP is rooted at a PE (or at an ASBR in the case where the P2MP service LSP spans multiple ASes). The leaves of this segment are other PEs/ASBRs and ABRs in the same area as the root PE. The backbone area segment is rooted at either an ABR that is connected to the ingress area (ingress ABR), an ASBR if the ASBR is present in the backbone area, or a PE if the PE is present in the backbone area. The backbone area segment has its leaf ABRs that are connected to the egress area(s) or PEs in the backbone area, or ASBRs in the backbone area. The egress area segment is rooted at an ABR in the egress area (egress ABR), and has its leaf PEs and ASBR in that egress area (the latter covers the case where the P2MP service LSP spans multiple ASes). For a given P2MP service LSP, note that there may 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" for "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.4. Inter-Area P2MP Segmented Next-Hop Extended Community
This document defines a new Transitive IPv4-Address-Specific Extended Community Sub-Type: "Inter-Area P2MP Next-Hop". This document also defines a new BGP Transitive IPv6-Address-Specific Extended Community Sub-Type: "Inter-Area P2MP Next-Hop".
A PE, an ABR, or an ASBR constructs the Inter-Area P2MP Segmented
Next-Hop Extended Community as follows:
- The Global Administrator field 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 address
may be the loopback address or the PE, ABR, or ASBR that
advertises the route.
- The Local Administrator field MUST be set to 0.
If the Global Administrator field is an IPv4 address, the
IPv4-Address-Specific Extended Community is used; if the Global
Administrator field is an IPv6 address, the IPv6-Address-Specific
Extended Community is used.
The detailed usage of these Extended Communities is described in
the following sections.
5. Discovering P2MP FEC of Inter-Area P2MP Service LSP
Each inter-area P2MP service LSP has associated with it P2MP
Forwarding Equivalence Class (FEC). The egress PEs need to learn
this P2MP FEC in order to initiate the creation of the egress area
segment of the P2MP inter-area service LSP.
The P2MP FEC of the inter-area P2MP LSP is learned by the egress PEs
either by configuration or based on the application-specific
procedures (e.g., 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 using the Inclusive Provider Multicast Service
Interface (I-PMSI) or Selective PMSI (S-PMSI) A-D routes that are
originated by the ingress PEs or ASBRs following the procedures of
[RFC6514], along with modifications as described in this document.
The Network Layer Reachability Information (NLRI) of such routes
encodes the P2MP FEC.
The procedures in this document require that at least one ABR in a
given IGP area act as a Route Reflector for MVPN A-D routes. Such a
Router Reflector is responsible for re-advertising MVPN A-D routes
across area boundaries. When re-advertising these routes across area
boundaries, this Route Reflector MUST follow the procedures in this
document. Note that such a Route Reflector may also re-advertise MVPN A-D routes within the same area; in which 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 the MVPN A-D routes, when originated by the ingress PEs or ASBRs, except for the case where (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 is 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 the I-PMSI/S-PMSI A-D routes are re-advertised by an ingress ABR, the "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute present in the routes, except for the case where (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 the I-PMSI/S-PMSI A-D routes are re-advertised by an egress ABR, the "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute present in the routes, except for the case where (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 above paragraph apply when intra-area segments are realized by either 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, to indicate that these LSPs should be segmented using the procedures specified in this document, these routes MUST carry the Inter-Area P2MP Segmented Next-Hop Extended Community. This Extended Community MUST be included in the I-PMSI/S-PMSI A-D route by the PE that originates such a route, or an ASBR that re-advertises such a route into its own
AS. The Global Administrator field in this Extended Community MUST be set to the advertising PE or ASBR's IP address. This Extended Community MUST also be included by ABRs as they re-advertise such routes. An ABR MUST set the Global Administrator field of the Inter- Area P2MP Segmented Next-Hop Extended Community to its own IP address. Presence of this Extended Community in the I-PMSI/S-PMSI A-D routes indicates to ABRs and PEs/ASBRs that they have to follow the procedures in this document when these procedures differ from those in [RFC6514]. If an ASBR receives from an IBGP peer an I-PMSI or S-PMSI A-D route that carries the Inter-Area P2MP Segmented Next-Hop Extended Community, then before re-advertising this route to an EBGP peer, the ASBR SHOULD remove this Extended Community from the route. 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 this route to its IBGP peers, the ASBR MUST remove this Extended Community from the route. To avoid requiring ABRs to participate in the propagation of C-multicast routes, this document requires that ABRs MUST NOT modify the BGP Next Hop when re-advertising Inter-AS I-PMSI A-D routes. For consistency, this document requires that ABRs MUST NOT modify the BGP Next Hop when re-advertising 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 than the ABRs. However, ABRs can still be configured to be the Route Reflectors for C-multicast routes; in which case, they will participate in the propagation of 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, using the VPLS A-D routes that are originated by the ingress PEs [RFC4761] [RFC6074] or VPLS S-PMSI A-D routes that are originated by the ingress PEs [RFC7117]. The NLRI of such routes encodes the P2MP FEC.5.2.1. Routes Originated by PE or ASBR
The "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute carried in the VPLS A-D routes or VPLS S-PMSI A-D routes, when originated by the ingress PEs or ASBRs, except for the case where (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, a VPLS/S-PMSI A-D route is 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.2.2. Routes Re-advertised by PE or ASBR
When the VPLS/S-PMSI A-D routes are re-advertised by an ingress ABR, the "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute present in the routes, except for the case where (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 the VPLS/S-PMSI A-D routes are re-advertised by an egress ABR, the "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute present in the routes, except for the case where (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.5.2.3. Inter-Area Routes
When VPLS A-D routes or S-PMSI A-D routes are advertised or propagated to signal inter-area P2MP service LSPs, to indicate that these LSPs should be segmented using the procedures specified in this document, these routes MUST carry the Inter-Area P2MP Segmented Next-Hop Extended Community. This Extended Community MUST be included in the A-D route by the PE or ASBR that originates such a route, and the Global Administrator field MUST be set to the advertising PE or ASBR's IP address. This Extended Community MUST also be included by ABRs as they re-advertise such routes. An ABR MUST set the Global Administrator field of the Inter-Area P2MP Segmented Next-Hop Extended Community to its own IP address. Presence of this Extended Community in the I-PMSI/S-PMSI A-D routes indicates to ABRs and PEs/ASBRs that they have to follow the procedures in this document when these procedures differ from those in [RFC7117]. Note that the procedures in the above paragraph apply when intra-area segments are realized by either intra-area P2MP LSPs or by ingress replication.
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. Such a Router Reflector is responsible for re-advertising VPLS A-D routes across areas boundaries. When re-advertising these routes across areas boundaries, this Route Reflector MUST follow the procedures in this document. Note that such a Route Reflector may also re-advertise VPLS A-D routes within the same area; in which case, it follows plain BGP Route Reflector procedures [RFC4456]. When re-advertising VPLS A-D routes, a Route Reflector MUST NOT modify the BGP Next Hop of these routes.5.3. Global Table Multicast over MPLS
This section describes how the egress PEs discover the P2MP FEC when the application is global table multicast over an MPLS-capable infrastructure. In the rest of the document, we will refer to this application as "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 this as "PIM-SM in ASM mode". In the case where 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) or a source (S,G) tree. 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. This (S/*,G) forms the P2MP FEC of the inter-area P2MP service LSP. For each such P2MP FEC, there MAY exist a distinct inter-area P2MP service LSP, or multiple such FECs MAY be carried over a single P2MP service LSP using a wildcard (*,*) S-PMSI [RFC6625]. 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.
(next page on part 2)
