tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7524

Proposed STD
Pages: 42
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MPLS

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

Part 1 of 3, p. 1 to 12
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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       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 RFC Part