Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7524

Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)

Pages: 42
Proposed Standard
Updated by:  8534
Part 1 of 3 – Pages 1 to 12
None   None   Next

Top   ToC   RFC7524 - Page 1
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.
Top   ToC   RFC7524 - Page 2
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.
Top   ToC   RFC7524 - Page 3

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
Top   ToC   RFC7524 - Page 4
           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
Top   ToC   RFC7524 - Page 5

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].
Top   ToC   RFC7524 - Page 6

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
Top   ToC   RFC7524 - Page 7
   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".
Top   ToC   RFC7524 - Page 8
   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
Top   ToC   RFC7524 - Page 9
   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
Top   ToC   RFC7524 - Page 10
   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
Top   ToC   RFC7524 - Page 11
   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.
Top   ToC   RFC7524 - Page 12
   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)

Next Section