Network Working Group                                         Y. Rekhter
Internet Draft                                          Juniper Networks
Expiration Date: June 2012
                                                             R. Aggarwal


                                                                T. Morin
                                                          France Telecom

                                                           I. Grosclaude
                                                          France Telecom

                                                              N. Leymann
                                                     Deutsche Telekom AG

                                                                 S. Saad
                                                                    AT&T

                                                         December 7 2011


                     Inter-Area P2MP Segmented LSPs


                 draft-ietf-mpls-seamless-mcast-03.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.






Rekhter                                                         [Page 1]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


Copyright and License Notice

   Copyright (c) 2011 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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.



Abstract

   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, using P2MP LSP
   hierarchy, or instantiated using ingress replication.  The intra-area
   P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress
   replication is used within an IGP area, then MP2P LDP LSPs or P2P
   RSVP-TE LSPs may be used in the IGP area. The applications/services
   that use such inter-area service LSPs may be BGP MVPN, VPLS multicast
   or IP multicast over MPLS.









Rekhter                                                         [Page 2]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


Table of Contents

 1          Specification of requirements  .........................   4
 2          Introduction  ..........................................   4
 3          General Assumptions and Terminology  ...................   5
 4          Inter-area P2MP Segmented Next-Hop Extended Community  .   6
 5          Discovering the P2MP FEC of the Inter-Area P2MP Service LSP  7
 5.1        BGP MVPN  ..............................................   7
 5.2        BGP VPLS or LDP VPLS with BGP auto-discovery  ..........   8
 5.3        IP Multicast over MPLS  ................................  10
 6          Egress PE Procedures  ..................................  10
 6.1        Determining the Upstream ABR/PE/ASBR  ..................  11
 6.2        Originating a Leaf Auto-Discovery Route  ...............  12
 6.2.1      Leaf Auto-Discovery Route for MVPN and VPLS  ...........  12
 6.2.2      Leaf Auto-Discovery Route for Global Table Multicast  ..  12
 6.2.3      Constructing the Rest of the Leaf Auto-Discovery Route  ....14
 6.3        PIM-SM in ASM mode for Global Table Multicast  .........  15
 6.3.1      Option 1  ..............................................  15
 6.3.1.1    Originating Source Active auto-discovery routes  .......  15
 6.3.1.2    Receiving BGP Source Active auto-discovery route by PE  ....16
 6.3.1.3    Handling (S, G, RPTbit) state  .........................  16
 6.3.2      Option 2  ..............................................  17
 6.3.2.1    Originating Source Active auto-discovery routes  .......  17
 6.3.2.2    Receiving BGP Source Active auto-discovery route  ......  17
 6.3.2.3    Pruning Sources off the Shared Tree  ...................  18
 6.3.2.4    More on handling (S, G, RPTbit) state  .................  18
 7          Egress ABR Procedures  .................................  19
 7.1        P2MP LSP as the Intra-Area LSP in the Egress Area  .....  21
 7.1.1      RD of the received Leaf auto-discovery route is not all 0s or all 1s  21
 7.1.2      RD of the received Leaf auto-discovery route is all 0s or all 1s  22
 7.1.2.1    Global Table Multicast and S-PMSI Auto-Discovery Routes  ...22
 7.1.2.2    Global Table Multicast and Wildcard S-PMSI Auto-Discovery Routes  22
 7.1.3      Global Table Multicast and the Expected Upstream Node  .  23
 7.1.4      P2MP LDP LSP as the Intra-Area P2MP LSP in the Egress Area  23
 7.1.5      P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area  23
 7.2        Ingress Replication in the Egress Area  ................  24
 8          Ingress ABR Procedures for constructing segmented inter-area P2MP LSP  24
 8.1        P2MP LSP as the Intra-Area LSP in the Backbone Area  ...  24
 8.2        Ingress Replication in the Backbone Area  ..............  25
 9          Ingress PE/ASBR Procedures  ............................  25
 9.1        P2MP LSP as the intra-area LSP in the ingress area  ....  26
 9.2        Ingress Replication in the Ingress Area  ...............  27
10          Common Tunnel Type in the Ingress and Egress Areas  ....  27
11          Placement of Ingress and Egress PEs  ...................  28



Rekhter                                                         [Page 3]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


12          Data Plane  ............................................  28
12.1        Data Plane Procedures on an ABR  .......................  28
12.2        Data Plane Procedures on an Egress PE  .................  29
12.3        Data Plane Procedures on an Ingress PE  ................  30
12.4        Data Plane Procedures on Transit Routers  ..............  30
13          Support for Inter-Area Transport LSPs  .................  30
13.1        Transport Tunnel Tunnel Type  ..........................  31
13.2        Discovering Leaves of the Inter-Area P2MP Service LSP  .  31
13.3        Discovering the P2MP FEC of the Inter-Area P2MP Transport LSP  31
13.4        Egress PE Procedures for Inter-Area P2MP Transport LSP  ....32
13.5        Egress ABR, Ingress ABR, Ingress PE procedures for Inter-Area   33
13.6        Discussion  ............................................  33
14          IANA Considerations  ...................................  35
15          Security Considerations  ...............................  35
16          Acknowledgements  ......................................  36
17          References  ............................................  36
17.1        Normative References  ..................................  36
17.2        Informative References  ................................  36
18          Author's Address  ......................................  37
seamless-mcast.nroff:1820: warning: macro `.' not defined






1. Specification of requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2. 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 or P2MP
   mLDP. If ingress replication is used in an IGP area then MP2P LDP or
   P2P RSVP-TE LSPs may be used within the IGP area.  The
   applications/services that use such inter-area service LSPs may be
   BGP MVPN, VPLS multicast or IP multicast over MPLS.

   The primary use case of such segmented P2MP service LSPs is when the



Rekhter                                                         [Page 4]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   PEs are in different areas but in the same 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
   Autonomous System, 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 [BGP-MVPN], [VPLS-P2MP] 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. Infact an inter-AS deployment could use inter-AS
   segmented P2MP LSPs as specified in [BGP-MVPN, VPLS-P2MP] where each
   intra-AS segment is constructed using inter-area segmented P2MP LSPs
   as specified in this document.


3. General Assumptions and Terminology

   This document assumes BGP is used as an inter-area routing and label
   distribution protocol for the unicast IPv4 /32 or IPv6 /128 routes
   for the PEs. This document also assumes ABRs act as Route Reflectors
   (RR) for these routes.

   When supporting segmentation of the inter-area P2MP MVPN service
   LSPs, instead of assuming that BGP is used as an inter-area routing
   and label distribution protocol for unicast IPv4 /32 or IPv6 /128
   routes, it is sufficient to assume that BGP is used as an inter-area
   routing protocol for unicast IPv4 /32 or IPv6 /128 routes used for
   multicast forwarding (SAFI = 2).

   Within an AS a P2MP service LSP is partitioned into 3 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 we assume that
   P2MP LSP hierarchy is used even with 1:1 mapping, in which case the
   upstream-assigned label could be an implicit NULL.

   When intra-area segments of the inter-area P2MP service LSP are



Rekhter                                                         [Page 5]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   instantiated using ingress replication, then 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 an
   ABR that is connected to the ingress area (ingress ABR), and has as
   its leaves ABRs that are connected to the egress area(s) or PEs in
   the backbone area. The egress area segment is rooted at an ABR in the
   egress area (egress ABR), and has as its leaves PEs and ASBR in that
   egress area (the latter covers the case where the P2MP service LSP
   spans multiple ASes). Note that for a given P2MP service LSP 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.

   An implementation that supports this document MUST implement the
   procedures described in the following sections to support inter-area
   point-to-multipoint (P2MP) segmented service LSPs.


4. Inter-area P2MP Segmented Next-Hop Extended Community

   This document defines a new BGP Extended Community "Inter-area P2MP
   Next-Hop" extended community. This is an IP address specific Extended
   Community, of an extended type and is transitive across AS boundaries
   [RFC4360].

   A PE or 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 or ASBR or ABR that originates or advertises the route,
       which carries the P2MP Next-Hop Extended Community. For example
       this address may be the loopback address or the PE, ASBR or ABR
       that advertises the route.

     -  The Local Administrator field MUST be set to 0.


   The detailed usage of this extended community is described in the
   following sections.







Rekhter                                                         [Page 6]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


5. Discovering the P2MP FEC of the Inter-Area P2MP Service LSP

   The P2MP FEC identifies the inter-area P2MP service LSP. 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, VPLS-specific
   procedures).


5.1. BGP MVPN

   Egress PEs discover the P2MP FEC of the service LSPs used by BGP MVPN
   using the I-PMSI or S-PMSI auto-discovery routes that are originated
   by the ingress PEs or ASBRs following the procedures of [BGP-MVPN],
   along with modifications as described in this document.  The 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 Route
   Reflector for MVPN auto-discovery routes.

   The "Leaf Information Required" flag MUST be set in the P-Tunnel
   attribute carried in such 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 auto discovery route is advertised by a PE or
   ABR in the same area, as described in the following sections, an I-
   PMSI/S-PMSI auto-discovery 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.

   When the I-PMSI/S-PMSI routes are re-advertised by an ingress ABR,
   the "Leaf Information Required" flag MUST be set in the P-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 routes are re-
   advertised by an egress ABR, the "Leaf Information Required" flag
   MUST be set in the P-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



Rekhter                                                         [Page 7]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   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.

   When BGP MVPN I-PMSI or S-PMSI auto-discovery 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 auto-discovery 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 P2MP
   Segmented Next-Hop Extended Community to its own IP address.
   Presense of this community in the I-PMSI/S-PMSI auto-discovery routes
   indicates to ABRs and PEs/ASBRs that they have to follow the
   procedures in this document when these procedures differ from those
   in [BGP-MVPN].

   To avoid requiring ABRs to participate in the propagation of C-
   multicast routes, this document requires ABRs NOT to modify BGP Next
   Hop when re-advertising Inter-AS I-PMSI auto-discovery routes.  For
   consistency this document requires ABRs to NOT modify BGP Next-Hop
   when re-advertising both Intra-AS and Inter-AS I-PMSI/S-PMSI auto-
   discovery routes. The egress PEs may advertise the C-multicast routes
   to RRs that are different than the ABRs. However ABRs still can 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. BGP VPLS or LDP VPLS with BGP auto-discovery

   Egress PEs discover the P2MP FEC of the service LSPs used by VPLS,
   using the VPLS auto-discovery routes that are originated by the
   ingress PEs [BGP-VPLS, VPLS-AD] or S-PMSI auto-discovery routes that
   are originated by the ingress PE [VPLS-P2MP]. The NLRI of such routes
   encodes the P2MP FEC.

   The "Leaf Information Required" flag MUST be set in the P-Tunnel
   attribute carried in such 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



Rekhter                                                         [Page 8]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   area. Before any Leaf auto-discovery route is advertised by a PE or
   ABR in the same area, as described in the following sections, an
   VPLS/S-PMSI auto-discovery 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.

   When the VPLS/S-PMSI auto-discovery routes are re-advertised by an
   ingress ABR, the "Leaf Information Required" flag MUST be set in the
   P-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 auto-discovery
   routes are re-advertised by an egress ABR, the "Leaf Information
   Required" flag MUST be set in the P-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.

   When VPLS auto-discovery or S-PMSI auto-discovery 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 auto-discovery 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 P2MP
   Segmented Next-Hop Extended Community to its own IP address.
   Presense of this community in the I-PMSI/S-PMSI auto-discovery routes
   indicates to ABRs and PEs/ASBRs that they have to follow the
   procedures in this document when these procedures differ from those
   in [VPLS-P2MP].

   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 Route Reflector for MVPN auto-discovery routes.
   These ABRs/RRs MUST NOT modify BGP Next Hop when re-advertising these
   auto-discovery routes.





Rekhter                                                         [Page 9]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


5.3. IP Multicast over MPLS

   This section describes how the egress PEs discover the P2MP FEC when
   the application is IP multicast over an MPLS-capable infrastructure.
   In the rest of the document we will refer to this application as
   "global table multicast".

   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 either carry traffic 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 (S/*,G) for which an inter-area P2MP service LSP is
   instantiated, there may exist a distinct inter-area P2MP service LSP
   or multiple inter-area P2MP service LSPs may be aggregated using a
   wildcard (*, *) S-PMSI [MVPN-WILDCARD-SPMSI].

   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. Infact PIM-SM in ASM mode may be supported entirely by using
   (S, G) trees alone.


6. Egress PE Procedures

   This section describes egress PE procedures for constructing
   segmented inter-area P2MP LSP. The procedures in this section apply
   irrespective of whether the egress PE is in a leaf IGP area, or the
   backbone area or even in the same IGP area as the ingress PE/ASBR.

   An egress PE applies procedures specified in this section to MVPN I-
   PMSI or S-PMSI auto-discovery routes only if these routes carry the
   Inter-area P2MP Segmented Next-Hop Extended Community. An egress PE
   applies procedures specified in this section to VPLS auto-discovery
   or S-PMSI auto-discovery routes only if these routes carry the Inter-
   area P2MP Segmented Next-Hop Extended Community.

   In order to support global table multicast an egress PE MUST auto-
   configure an import Route Target with the global administrator field
   set to the AS of the PE and the local administrator field set to 0.

   Once an egress PE 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. This propagation
   uses BGP Leaf auto-discovery routes.




Rekhter                                                        [Page 10]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


6.1. Determining the Upstream ABR/PE/ASBR

   The egress PE discovers the P2MP FEC of an inter-area P2MP Segmented
   Service LSP as described in section 5. When an egress PE discovers
   this P2MP FEC it MUST first determine the upstream node to reach such
   a FEC. If the egress PE is in the egress area and the ingress PE is
   not in the that egress area, then this upstream node would be the
   egress ABR. If the egress PE is in the backbone area and the ingress
   PE is not in the backbone area, then this upstream node would be the
   ingress ABR. If the egress PE is in the same area as the ingress PE
   then this upstream node would be the ingress PE.

   If the application is MVPN or VPLS then the upstream node's IP
   address is the IP address determined from 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 auto-discovery route from which the P2MP FEC of the
   inter-area P2MP Segmented Service LSP is determined.

   If the application is global table multicast then the unicast routes
   to multicast sources/RPs SHOULD carry the VRF Route Import Extended
   Community [BGP-MVPN] where the IP address in the Global Administrator
   field is set to the IP address of the PE or ASBR advertising the
   unicast route. The Local Administrator field of this community MUST
   be set to 0. If it is not 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 SAFI
   i.e.  SAFI 2, and such routes MUST carry the VRF Route Import
   Extended Community.

   Further if the application is global table multicast then the BGP
   unicast routes that advertise the route to the IP address of PEs or
   ASBRs or ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop
   Extended Community where the IP address in the Global Administrator
   field is set to the IP address of the PE or ASBR or ABR advertising
   the unicast route. The Local Administrator field of this community
   MUST be set to 0. If it is not desirable to advertise the P2MP
   Segmented Next-Hop Extended Community in BGP unicast routes, then
   unicast routes to ABRs, ASBRs or PEs 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 of handling regular Unicast routes and
   follow [SEAMLESS-MPLS].

   If the application is global table multicast, then in order to
   determine the upstream node address the egress PE first determines



Rekhter                                                        [Page 11]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   the ingress PE. In order to determine the ingress PE the egress PE
   determines the best route to reach S/RP. The ingress PE address is
   the IP address determined from the Global Administrator field of the
   VRF Route Import Extended Community, that is present in this route.
   The egress PE now finds the best unicast route to reach the ingress
   PE. The upstream node address is the IP address determined from the
   Global Administrator field of the Inter-area P2MP Segmented Next-Hop
   Extended Community, that is present in this route.


6.2. Originating a Leaf Auto-Discovery Route

   If the P2MP FEC was derived from a MVPN or VPLS auto-discovery route
   then the egress PE MUST originate a Leaf auto-discovery route if the
   MVPN or VPLS auto-discovery route carries a P-Tunnel Attribute with
   the "Leaf Information Required" flag set.

   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 auto-discovery route.


6.2.1. Leaf Auto-Discovery Route for MVPN and VPLS

   If the P2MP FEC was derived from MVPN or VPLS auto-discovery routes
   then the Route Key field of the Leaf auto-discovery route contains
   the NLRI of the auto-discovery route from which the P2MP FEC was
   derived. This follows procedures for constructing Leaf auto-discovery
   routes described in [BGP-MVPN, VPLS-P2MP].


6.2.2. Leaf Auto-Discovery Route for Global Table Multicast

   If the application is global table multicast then the MCAST-VPN NLRI
   of the Leaf auto-discovery route is constructed as follows:

   The Route Key field of MCAST-VPN NLRI has the following format:

                   +-----------------------------------+
                   |      RD   (8 octets)              |
                   +-----------------------------------+
                   | Multicast Source Length (1 octet) |
                   +-----------------------------------+
                   |  Multicast Source (Variable)      |
                   +-----------------------------------+
                   |  Multicast Group Length (1 octet) |
                   +-----------------------------------+
                   |  Multicast Group   (Variable)     |



Rekhter                                                        [Page 12]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


                   +-----------------------------------+
                   |  Ingress PE's IP address          |
                   +-----------------------------------+


   RD is set to 0 for (S,G) state and all 1s for (*,G) state, Multicast
   Source is set to S for (S,G) state or RP for (*,G) state, Multicast
   Group is set to G, Multicast Source Length and Multicast Group Length
   is set to either 4 or 16 (depending on whether S/RP and G are IPv4 or
   IPv6 addresses).

   The Ingress PE's IP address is determined as described in the section
   "Determining the Upstream ABR/PE/ASBR".

   The Originating Router's IP address field of MCAST-VPN NLRI is set to
   the address of the local PE (PE that originates the route).

   Thus the entire MCAST-VPN NLRI of the route has the following format:

                   +-----------------------------------+
                   |      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  |
                   +-----------------------------------+

   Note that the encoding of MCAST-VPN NLRI for the Leaf auto-discovery
   routes used for global table multicast is different from the encoding
   used by the Leaf auto-discovery routes originated in response to S-
   PMSI or I-PMSI auto-discovery routes. A router that receives a Leaf
   auto-discover route can distinguish between these two cases by
   examining the third octet of the MCAST-VPN NLRI of the route.  If the
   value of this octet is either 0x00 or 0xff, then this is a Leaf auto-
   discovery route used for global table multicast. If the value of this
   octet is 0x01 or 0x02, or 0x03 then this Leaf auto-discovery route



Rekhter                                                        [Page 13]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   was originated in response to an S-PMSI or I-PMSI auto-discovery
   route.

   When the PE deletes (S,G)/(*,G) state that was created as a result of
   receiving PIM or IGMP messages on one of its IP multicast interfaces,
   if the PE previousely originated a Leaf auto-discovery route for that
   state, then the PE SHOULD withdraw that route.

   An Autonomous System with an IPv4 network may provide IP multicast
   service for customers that use IPv6, and an Autonomous System with an
   IPv6 network may provide IP multicast service for customers that use
   IPv4. Therefore the address family of the Ingress PE's IP address and
   Originating Router's IP address in the Leaf auto-discovery routes
   used for global table multicast MUST NOT be inferred from the AFI
   field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI attribute of
   these routes.  The address family is determined from the length of
   the address (a length of 4 octets for IPv4 addresses, a length of 16
   octets for IPv6 addresses).

   For example if an Autonomous System  with an IPv4 network is
   providing IPv6 multicast service to a customer, the Ingress PE's IP
   address and Originating Router's IP address in the Leaf auto-
   discovery routes used for IPv6 global table multicast will be a four-
   octet IPv4 address, even though the AFI of those routes will have the
   value 2.

   Note that the Ingress PE's IP address and the Originating Router's IP
   address must be either both IPv4 or both IPv6 addresses, and thus
   must be of the same length.  Since the two variable length fields
   (Multicast Source and Multicast Group) in the Leaf auto-discovery
   routes used for global table multicast have their own length field,
   from these two length fields, and the Length field of the MCAST-VPN
   NLRI, one can compute length of the Ingress PE's IP address and the
   Originating Router's IP address fields.  If the computed length of
   these 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 [BGP-MP].


6.2.3. Constructing the Rest of the Leaf Auto-Discovery 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 carried in the Originating
   Router's IP Address field of the route.

   When Ingress Replication is used to instantiate the egress area
   segment then the Leaf auto-discovery route MUST carry a downstream
   assigned label in the P-Tunnel Attribute where the P-Tunnel type is



Rekhter                                                        [Page 14]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   set to Ingress Replication. A PE MUST assign a distinct MPLS label
   for each Leaf auto-discovery route originated by the PE.

   To constrain distribution of this route, the originating PE
   constructs an IP-based Route Target community by placing the IP
   address of the upstream node in the Global Administrator field of the
   community, with the Local Administrator field of this community set
   to 0. The originating PE then adds this Route Target Extended
   Community to this Leaf auto-discovery route. The upstream node's
   address is as determined in section 6.1.

   The PE then advertises this route to the upstream node.


6.3. PIM-SM in ASM mode for Global Table Multicast

   This specification allows two options for supporting global table
   multicast with PIM-SM in ASM mode. The first option does not transit
   IP multicast shared trees over the MPLS network. The second option
   does transit shared trees over the MPLS network and relies on shared
   tree to source tree switchover.


6.3.1. Option 1

   This option does not transit IP multicast shared trees over the MPLS
   network. Therefore, when an (egress) PE creates (*, G) state (as a
   result of receiving PIM or IGMP messages on one of its IP multicast
   interfaces), the PE does not propagate this state using Leaf auto-
   discovery routes.


6.3.1.1. Originating Source Active auto-discovery routes

   Whenever as a result of receiving PIM Register or MSDP messages an RP
   discovers a new multicast source, the RP SHOULD originate a BGP
   Source Active auto-discovery route. Similarly whenever as a result of
   receiving MSDP messages a PE, that is not configured as a RP,
   discovers a new multicast source the PE SHOULD originate a BGP Source
   Active auto-discovery route. The BGP Source Active auto-discovery
   route carries a single MCAST-VPN NLRI constructed as follows:

        + 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



Rekhter                                                        [Page 15]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


          Length field is set appropriately to reflect this.

   To constrain distribution of the Source Active auto-discovery route
   to the AS of the advertising RP this route SHOULD carry the NO_EXPORT
   Community ([RFC1997]).

   Using the normal BGP procedures the Source Active auto-discovery
   route is propagated to all other PEs within the AS.

   Whenever the RP discovers that the source is no longer active, the RP
   MUST withdraw the Source Active auto-discovery route, if such a route
   was previousely advertised by the RP.


6.3.1.2. Receiving BGP Source Active auto-discovery route by PE

   When as a result of receiving PIM or IGMP messages on one of its IP
   multicast interfaces an (egress) PE creates in its Tree Information
   Base (TIB) a new (*, G) entry with a non-empty outgoing interface
   list that contains one or more IP multicast interfaces, the PE MUST
   check if it has any Source Active auto-discovery routes for that G.
   If there is such a route, S of that route is reachable via an MPLS
   interface, and the PE does not have (S, G) state in its TIB for (S,
   G) carried in the route, then the PE originates a Leaf auto-discovery
   routes carrying that (S, G), as specified in Section "Leaf Auto-
   Discovery Route for Global Table Multicast".

   When an (egress) PE receives a new Source Active auto-discovery
   route, the PE MUST check if its TIB contains an (*, G) entry with the
   same G as carried in the Source Active auto-discovery route.  If such
   an entry is found, S is reachable via an MPLS interface, and the PE
   does not have (S, G) state in its TIB for (S, G) carried in the
   route, then the PE originates a Leaf auto-discovery routes carrying
   that (S, G), as specified in Section "Leaf Auto-Discovery Route for
   Global Table Multicast".


6.3.1.3. Handling (S, G, RPTbit) state

   Creation and deletion of (S, G, RPTbit) state on a PE that resulted
   from receiving PIM messages on one of its IP multicast interfaces
   does not result in any BGP actions by the PE.









Rekhter                                                        [Page 16]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


6.3.2. Option 2

   This option does transit IP multicast shared trees over the MPLS
   network. Therefore, when an (egress) PE creates (*, G) state (as a
   result of receiving PIM or IGMP messages on one of its IP multicast
   interfaces), the PE does propagate this state using Leaf auto-
   discovery routes.


6.3.2.1. Originating Source Active auto-discovery routes

   Whenever a PE creates an (S, G) state as a result of receiving Leaf
   auto-discovery routes associated with the global table multicast
   service, if 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 PE MUST originate a BGP Source Active auto-discovery
   route. The route carries a single MCAST-VPN NLRI constructed as
   follows:

        + 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.

   To constrain distribution of the Source Active auto-discovery route
   to the AS of the advertising PE this route SHOULD carry the NO_EXPORT
   Community ([RFC1997]).

   Using the normal BGP procedures the Source Active auto-discovery
   route is propagated to all other PEs within the AS.

   Whenever the PE deletes the (S, G) state that was previously created
   as a result of receiving a Leaf auto-discovery route for (S, G), the
   PE that deletes the state MUST also withdraw the Source Active auto-
   discovery route, if such a route was advertised when the state was
   created.


6.3.2.2. Receiving BGP Source Active auto-discovery route

   Procedures for receiving BGP Source Active auto-discovery routes are
   the same as with Option 1.






Rekhter                                                        [Page 17]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


6.3.2.3. Pruning Sources off the Shared Tree

   If after receiving a new Source Active auto-discovery route for (S,G)
   a PE determines that (a) it has the (*, G) entry in its TIB, (b) the
   incoming interface list (iif) for that entry contains one of the IP
   interfaces, (c) a MPLS LSP is in the outgoing interface list (oif)
   for that entry, and (d) the PE does not originate a Leaf auto-
   discovery route for (S,G), then the PE MUST transition the (S,G,rpt)
   downstream state to the Prune state. [Conceptually the PIM state
   machine on the PE will act "as if" it had received Prune(S,G,Rpt)
   from some other PE, without actually having received one.] Depending
   on the (S,G,rpt) state on the iifs, this may result in the PE using
   PIM procedures to prune S off the Shared (*,G) tree.

   Transitioning the state machine to the Prune state SHOULD be done
   after a delay that is controlled by a timer. The value of the timer
   MUST be configurable. The purpose of this timer is to ensure that S
   is not pruned off the shared tree until all PEs have had time to
   receive the Source Active auto-discovery route for (S,G).

   The PE MUST keep the (S,G,rpt) downstream state machine in the Prune
   state for as long as (a) the outgoing interface list (oif) for (*, G)
   contains a MPLS LSP, and (b) the PE has at least one Source Active
   auto-discovery route for (S,G), and (c) the PE does not originate the
   Leaf auto-discovery route for (S,G).  Once either of these conditions
   become no longer valid, the PE MUST transition the (S,G,rpt)
   downstream state machine to the NoInfo state.

   Note that except for the scenario described in the first paragraph of
   this section, in all other scenarios relying solely on PIM procedures
   on the PE is sufficient to ensure the correct behavior when pruning
   sources off the shared tree.


6.3.2.4. More on handling (S, G, RPTbit) state

   Creation and deletion of (S, G, RPTbit) state on a PE that resulted
   from receiving PIM messages on one of its IP multicast interfaces
   does not result in any BGP actions by the PE.












Rekhter                                                        [Page 18]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


7. Egress ABR Procedures

   This section describes Egress ABR Procedures for constructing
   segmented inter-area P2MP LSP.

   When an egress ABR receives a Leaf auto-discovery route and the Route
   Target extended community carried by the route contains the IP
   address of this ABR, then the following procedures will be executed.

   If the RD of the received Leaf auto-discovery route is not set to all
   0s or all 1s, then the egress ABR MUST find a S-PMSI or I-PMSI route
   whose NLRI has the same value as the Route Key field of the received
   Leaf auto-discovery route. If such a matching route is found then the
   Leaf auto-discovery route MUST be accepted, else it MUST be
   discarded. If the Leaf auto-discovery route is accepted and if its
   the first Leaf auto-discovery route update for the Route Key field in
   the route, or the withdrawl of the last Leaf auto-discovery route for
   the Route Key field then the following procedures will be executed.

   If the RD of the received Leaf auto-discovery route is set to all 0s
   or all 1s then the received Leaf auto-discovery route is for the
   global table multicast service. In that case for the following
   procedure the Route Prefix is set to all fields of the Route Key
   minus the Ingress PE address. If this is the first Leaf auto-
   discovery route update for this Route Prefix or the withdrawl of the
   last Leaf auto-discovery route for the Route Prefix then the
   following procedures will be executed.

   While generating a Leaf auto-discovery route update, the egress ABR
   originates a Leaf auto-discovery route, whose MCAST-VPN NLRI is
   constructed as follows.

   The Route Key field of MCAST-VPN NLRI is the same as the Route Key
   field of MCAST-VPN NLRI of the received Leaf auto-discovery route.
   The Originating Router's IP address field of MCAST-VPN NLRI is set to
   the address of the local ABR (the ABR that originates the route).  In

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

   To constrain distribution of this route the originating egress ABR
   constructs an IP-based Route Target community by placing the IP
   address of the upstream node in the Global Administrator field of the
   community, with the Local Administrator field of this community set
   to 0, and sets the Extended Communities attribute of this Leaf auto-
   discovery route to that community.




Rekhter                                                        [Page 19]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   The upstream node's IP address is the IP address determined from the
   Global Administrator field of the Inter-area P2MP Segmented Next-hop
   Extended Community, where this Extended Community is obtained as
   follows.  When the Leaf auto-discovery route is for MVPN or VPLS then
   this Extended Community is the one included in the I-PMSI/S-PMSI
   auto-discovery route that matches the Leaf auto-discovery route.
   When the Leaf auto-discovery route is for global table multicast then
   this Extended Community is obtained from the best unicast route to
   the Ingress PE. The Ingress PE address is determined from the
   received Leaf auto-discovery route.  The best unicast route MUST
   first be determined from multicast SAFI i.e., SAFI 2 routes, if
   present.

   The ABR then advertises this Leaf auto-discovery route to the
   upstream node in the backbone area.

   Mechanisms specific in [RFC4684] for constrained BGP route
   distribution can be used along with this specification to ensure that
   only the needed PE/ABR will have to process a said Leaf auto-
   discovery route.

   When Ingress Replication is used to instantiate the backbone area
   segment then the Leaf auto-discovery route originated by the egress
   ABR MUST carry a downstream assigned label in the P-Tunnel Attribute
   where the P-Tunnel type is set to Ingress Replication. An ABR MUST
   assign a distinct MPLS label for each Leaf auto-discovery route
   originated by the ABR.

   In order to support global table multicast an egress ABR MUST auto-
   configure an import Route Target with the global administrator field
   set to the AS of the ABR and the local administrator field set to 0.

   When the Leaf auto-discovery route is for global table multicast and
   if the following conditions hold true:


   - its not the first Leaf auto-discovery route for the Route Prefix,
   where the Route Prefix is determined as described above, and

   - the set of ingress PEs associated with the Route Prefix
   changes as a result of the new Leaf auto-discovery route, or

   - the ABR determines based on local policy to propagate
   the Leaf auto-discovery route towards a different ingress PE than
   the one to which the Leaf auto-discovery route is being currently
   propagated,





Rekhter                                                        [Page 20]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   then the egress ABR MUST originate the Leaf auto-discovery route as
   described in this section.

   If the received Leaf auto-discovery route is the last Leaf auto-
   discovery route for the Route Key for MVPN or VPLS or for the Route
   Prefix, as described above, for global table multicast, then the ABR
   must withdraw the previously advertised Leaf auto-discovery route.


7.1. P2MP LSP as the Intra-Area LSP in the Egress Area

   This section describes procedures for using intra-area P2MP LSPs in
   the egress area. The procedures that are common to both P2MP RSVP-TE
   and P2MP LDP are described first, followed by procedures that are
   specific to the signaling protocol.

   When P2MP LSPs are used as the intra-area LSPs, note that an existing
   intra-area P2MP LSP may be used solely for a particular inter-area
   P2MP service LSP, or for other inter-area P2MP service LSPs as well.
   The choice between the two options is purely local to the egress ABR.
   The first option provides one-to-one mapping between inter-area P2MP
   service LSPs and intra-area P2MP LSPs; the second option provides
   many-to-one mapping, thus allowing to aggregate forwarding state.


7.1.1. RD of the received Leaf auto-discovery route is not all 0s or all
   1s

   When the RD of the received Leaf auto-discovery route is not set to
   all 0s or all 1s, then the ABR MUST re-advertise in the egress area
   the MVPN/VPLS auto-discovery route, that matches the Leaf auto-
   discovery route to signal the binding of the intra-area P2MP LSP to
   the inter-area P2MP service LSP. This must be done ONLY if (a) such a
   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 specifies either
   an intra-area P2MP RSVP-TE LSP or an intra-area P2MP LDP LSP rooted
   at the ABR and MUST also carry an upstream assigned MPLS label. The
   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 (referred to as the
   "inner" P2MP LSP) is constructed by nesting the inter-area P2MP
   service LSP in an intra-area P2MP LSP (referred to as the "outer"
   intra-area P2MP LSP), by using P2MP LSP hierarchy based on upstream-
   assigned MPLS labels [RFC 5332].



Rekhter                                                        [Page 21]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   If segments of multiple MVPN or VPLS S-PMSI service LSPs are carried
   over a given intra-area P2MP LSP, each of these segments MUST carry a
   distinct upstream-assigned label, even if all these service LSPs are
   for (C-S/*, C-G/*)s from the same MVPN/VPLS. Therefore, an ABR
   maintains an LFIB state for each of the (C-S/*, C-G/*)s carried over
   S-PMSIs traversing this ABR (that applies to both the ingress and the
   egress ABRs).


7.1.2. RD of the received Leaf auto-discovery route is all 0s or all 1s

   When the RD of the received Leaf auto-discovery route is set to all
   0s or all 1s, then this is the case of inter-area P2MP service LSP
   being associated with the global table multicast service. The
   procedures for this are described below.


7.1.2.1. Global Table Multicast and S-PMSI Auto-Discovery Routes

   This section applies only if it is desirable to send a particular
   global table multicast flow to only those egress PEs that have
   receivers in a particular (S, G) or a particular (*, G) multicast
   flow.

   The egress ABR MUST originate a S-PMSI auto-discovery route. The PMSI
   Tunnel attribute of the route MUST contain the identity of the intra-
   area P2MP LSP and an upstream assigned MPLS label. The RD, Multicast
   Source Length, Multicast Source, Multicast Group Length (1 octet),
   and Multicast Group fields of the NLRI of this route are the same as
   of the Leaf auto-discovery route. The egress ABR MUST advertise this
   route into the egress area. The Route Target of this route is an AS
   specific route-target with the AS set to the AS of the advertising
   ABR while the local administrator field is set to 0.


7.1.2.2. Global Table Multicast and Wildcard S-PMSI Auto-Discovery
   Routes

   It may be desirable for an ingress PE to carry multiple multicast
   flows associated with the global table multicast routes over the same
   inter-area P2MP LSP. This can be achieved using wildcard, i.e., (*,*)
   S-PMSI auto-discovery routes [MVPN-WILDCARD-SPMSI].  An ingress PE
   MAY advertise a wildcard S-PMSI auto-discovery route as described in
   section "Ingress PE Procedures". If the ingress PE does indeed
   originate such a route, the egress ABR would receive this route from
   the ingress ABR and MUST re-advertise it with the PMSI Tunnel
   Attribute containing the identifier of the intra-area P2MP LSP in the
   egress area and an upstream assigned label assigned to the inter-area



Rekhter                                                        [Page 22]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   wildcard S-PMSI.


7.1.3. Global Table Multicast and the Expected Upstream Node

   If the mapping between the inter-area P2MP service LSP for global
   table multicast service and the intra-area P2MP LSP is many-to-one
   then an egress PE must be able to determine whether a given multicast
   packet for a particular (S, G) is received from the "expected"
   upstream node. The expected node is the node towards which the Leaf
   auto-discovery route is sent by the egress PE.  Packets received from
   another upstream node for that (S, G) MUST be dropped.  To allow the
   egress PE to determine the sender upstream node, the intra-area P2MP
   LSP must be signaled with no PHP, when the mapping between the inter-
   area P2MP service LSP for global table multicast service and the
   intra-area P2MP LSP is many-to-one.

   Further the egress ABR MUST first push onto the label stack the
   upstream assigned label advertised in the S-PMSI route, if the label
   is not an Implicit NULL.


7.1.4. P2MP LDP LSP as the Intra-Area P2MP LSP in the Egress Area

   The above procedures are sufficient if P2MP LDP LSPs are used as the
   Intra-area P2MP LSP in the Egress area.


7.1.5. P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area

   If P2MP RSVP-TE LSP is used as the the intra-area LSP in the egress
   area, then the egress ABR can either (a) graft the leaf (whose IP
   address is specified in the received Leaf auto-discovery route) into
   an existing P2MP LSP rooted at the egress ABR, and use that LSP for
   carrying traffic for the inter-area segmented P2MP service LSP, or
   (b) originate a new P2MP LSP to be used for carrying (S,G).

   When the RD of the received Leaf auto-discovery route is all 0s or
   all 1s, then the procedures are as described in section  7.1.2 ("RD
   of the received Leaf Auto-Discovery route is all 0s or all 1s").

   Note also that the SESSION object that the egress ABR would use for
   the intra-area P2MP LSP need not encode the P2MP FEC from the
   received Leaf auto-discovery route.







Rekhter                                                        [Page 23]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


7.2. Ingress Replication in the Egress Area

   When Ingress Replication is used to instantiate the egress area
   segment then the Leaf auto-discovery route advertised by the egress
   PE MUST carry a downstream assigned label in the P-Tunnel Attribute
   where the P-Tunnel type is set to Ingress Replication. We will call
   this label the egress PE downstream assigned label.

   The egress ABR MUST forward packets received from the backbone area
   intra-area segment, for a particular inter-area P2MP LSP, to all the
   egress PEs from which the egress ABR has imported a Leaf auto-
   discovery route for the inter-area P2MP LSP. A packet to a particular
   egress PE is encapsulated, by the egress ABR, using a MPLS label
   stack the bottom label of which is the egress PE downstream assigned
   label. The top label is the P2P RSVP-TE or the MP2P LDP label to
   reach the egress PE.

   Note that these procedures ensures that an egress PE always receives
   packets only from the expected upstream PE.


8. Ingress ABR Procedures for constructing segmented inter-area P2MP LSP

   When an ingress ABR receives a Leaf auto-discovery route and the
   Route Target extended community carried by the route contains the IP
   address of this ABR, then the following procedures will be executed.

   The ingress ABR follows the same procedures as in the section "Egress
   ABR Procedures" with egress ABR replaced with ingress ABR, backbone
   area replaced with ingress area and backbone area segment replaced
   with ingress area segment.

   In order to support global table multicast the ingress ABR MUST be
   auto-configured with an import Route Target whose global
   administrator field is set to the AS of the ABR and the 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 section "Egress ABR Procedures" and sub-section "P2MP LSP as
   the Intra-Area LSP in the Egress Area", with the egress ABR replaced
   by the ingress ABR. This applies to the inter-area P2MP LSPs
   associated with either MVPN, or VPLS, or global table multicast.

   It is to be noted that in the case of global table multicast, if the



Rekhter                                                        [Page 24]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   backbone area uses wildcard S-PMSI, then the egress area also must
   use wildcard S-PMSI for global table multicast, or the ABRs must
   merge the wildcard S-PMSI onto the egress area (S, G) or (*, G) S-
   PMSI. The procedures for such merge require IP processing on the
   ABRs.



8.2. Ingress Replication in the Backbone Area

   When Ingress Replication is used to instantiate the backbone area
   segment then the Leaf auto-discovery route advertised by the egress
   ABR MUST carry a downstream assigned label in the P-Tunnel Attribute
   where the P-Tunnel type is set to Ingress Replication. We will call
   this the egress ABR downstream assigned label. The egress ABR MUST
   assign a distinct MPLS label for each Leaf auto-discovery route
   originated by the ABR.

   The ingress ABR MUST forward packets received from the ingress area
   intra-area segment, for a particular inter-area P2MP LSP, to all the
   egress ABRs from which the ingress ABR has imported a Leaf auto-
   discovery route for the inter-area P2MP LSP. A packet to a particular
   egress ABR is encapsulated, by the inress ABR, using a MPLS label
   stack the bottom label of which is the egress ABR downstream assigned
   label. The top label is the P2P RSVP-TE or the MP2P LDP label to
   reach the egress ABR.


9. Ingress PE/ASBR Procedures

   This section describes Ingress PE/ASBR procedures for constructing
   segmented inter-area P2MP LSP.

   When an ingress PE/ASBR receives a Leaf auto-discovery route and the
   Route Target extended community carried by the route contains the IP
   address of this PE/ASBR, then the following procedures will be
   executed.

   If the RD of the received auto-discovery route is not set to all 0s
   or all 1s, then the egress ABR MUST find a S-PMSI or I-PMSI route
   whose NLRI has the same value as the Route Key field of the received
   Leaf auto-discovery route. If such a matching route is found then the
   Leaf auto-discovery route MUST be accepted else it MUST be discarded.
   If the Leaf auto-discovery route is accepted then it MUST be
   processed as per MVPN or VPLS procedures.

   If the RD of the received auto-discovery route is set to all 0s or
   all 1s then the received Leaf auto-discovery route is for the global



Rekhter                                                        [Page 25]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   table multicast service. In that case for the following procedure the
   Route Prefix is set to all fields of the Route Key minus the Ingress
   PE address. If this is the first Leaf auto-discovery route update for
   this Route Prefix or the withdrawl of the last Leaf auto-discovery
   route for the Route Prefix then the following procedures will be
   executed. The information carried in the MCAST-VPN NLRI of the route
   MUST be decoded. The PIM implementation should set its upstream
   (S/RP,G) state machine in Joined state for the (S/RP, G) received via
   a Leaf auto-discovery route update. Likewise, the PIM implementation
   should set its upstream (S/RP, G) state machine in Pruned state for
   the (S/RP, G) received via a Leaf auto-discovery route withdrawl.


9.1. P2MP LSP as the intra-area LSP in the ingress area

   If the RD of the received Leaf auto-discovery route is not all 0s or
   all 1s, and P2MP LSP is used as the 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 section "Egress ABR Procedures" and sub-section
   "P2MP LSP as the Intra-Area LSP in the Egress Area".

   When the RD of the received Leaf auto-discovery route is all 0s or
   all 1s, as is the case where the inter-area service P2MP LSP is
   associated with the global table multicast service, then the ingress
   PE may originate a S-PMSI route with the RD, multicast source,
   multicast group fields being the same as those in the received Leaf
   auto-discovery route.

   Further an ingress PE may originate a wildcard S-PMSI route as per
   the procedures in [MVPN-WILDCARD-SPMSI] with the RD set to 0. This
   route may be originated by the ingress PE based on configuration or
   based on the import of a Leaf auto-discovery route with RD set to 0.
   If an ingress PE originates such a route, then the ingress PE may
   decide not to originate (S, G) or (*, G) S-PMSI routes.

   It is to be noted that if ingress area uses wildcard S-PMSI then the
   backbone area also must use wildcard S-PMSI for global table
   multicast, or the ABRs must merge the wildcard S-PMSI onto the
   backbone area (S, G) or (*, G) S-PMSI. The procedures for such merge
   require IP processing on the ABRs.










Rekhter                                                        [Page 26]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


9.2. Ingress Replication in the Ingress Area

   When Ingress Replication is used to instantiate the ingress area
   segment then the Leaf auto-discovery route advertised by the ingress
   ABR MUST carry a downstream assigned label in the P-Tunnel Attribute
   where the P-Tunnel type is set to Ingress Replication. We will call
   this the ingress ABR downstream assigned label. The ingress ABR MUST
   assign a distinct MPLS label for each Leaf auto-discovery route
   originated by the ABR.

   The ingress PE/ASBR MUST forward packets received from the CE, for a
   particular inter-area P2MP LSP, to all the ingress ABRs from which
   the ingress PE/ASBR has imported a Leaf auto-discovery route for the
   inter-area P2MP LSP. A packet to a particular ingress ABR is
   encapsulated, by the ingress PE/ASBR, using a MPLS label stack the
   bottom label of which is the ingress ABR downstream assigned label.
   The top label is the P2P RSVP-TE or the MP2P LDP label to reach the
   ingress ABR.


10. Common Tunnel Type in the Ingress and Egress Areas

   For a given inter-area service P2MP LSP, the PE/ASBR that is the root
   of that LSP controls the tunnel type of the intra-area P-tunnel that
   carries the ingress area segment of that LSP. However, the tunnel
   type of the intra-area P-tunnel that carries the backbone area
   segment of that LSP may be different from the tunnel type of the
   intra-area P-tunnels that carry the ingress area segment and the
   egress area segment of that LSP. In that situation if for a given
   inter-area P2MP LSP it is desirable/necessary to use the same tunnel
   type for the intra-area P-tunnels that carry the ingress area segment
   and the egress area segment of that LSP, then the following
   procedures on the ingress ABR and egress ABR provide this
   functionality.

   When an ingress ABR re-advertises into the backbone area a BGP MVPN
   I-PMSI, or S-PMSI auto-discovery route, or VPLS auto-discovery route,
   the ingress ABR places the PMSI Tunnel attribute of this route into
   the ATTR_SET BGP Attribute [L3VPN-IBGP], adds this attribute to the
   re-advertised route, and then replaces the original PMSI Tunnel
   attribute with a new one (note, that the Tunnel type of the new
   attribute may be different from the Tunnel type of the original
   attribute).

   When an egress ABR re-advertises into the egress area a BGP MVPN I-
   PMSI or S-PMSI auto-discovery route, or VPLS auto-discovery route, if
   the route carries the ATTR_SET BGP attribute [L3VPN-IBGP], then the
   ABR sets the Tunnel type of the PMSI Tunnel attribute in the re-



Rekhter                                                        [Page 27]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   advertised route to the Tunnel type of the PMSI Tunnel attribute
   carried in the ATTR_SET BGP attribute, and removes the ATTR_SET from
   the route.


11. Placement of Ingress and Egress PEs

   As described in the earlier sections, procedures in this document
   allow the placement of ingress and egress PEs in the backbone area.
   They also allow the placement of egress PEs in the ingress area or
   the placement of ingress PEs in the egress area.

   For instance, ABRs in the backbone area may act as ingress and egress
   PEs for global table multicast, as per the ingress and egress PE
   definition in this document. This may be the case if the service is
   global table multicast and relies on global table multicast in the
   ingress and egress areas and its desirable to carry global table
   multicast over MPLS in the backbone area.  This may also be the case
   if the service is MVPN and the P-tunnel technology in the ingress and
   egress areas uses PIM based IP/GRE P-tunnels.  As far as the ABRs are
   concerned PIM signaling for such P-Tunnels is handled as per the
   ingress/egress PE global table multicast procedures specified in this
   document. To facilitate this the ABRs may advertise their loopback
   addresses in BGP using multicast-SAFI i.e., SAFI 2, if non-congruence
   between unicast and multicast is desired.


12. Data Plane

   This section describes the data plane procedures on the ABRs, ingress
   PEs, egress PEs and transit routers.


12.1. Data Plane Procedures on an ABR

   When procedures in this document are followed to signal inter-area
   P2MP Segmented LSPs, then ABRs are required to perform only MPLS
   switching. When an ABR receives a MPLS packet from an "incoming"
   intra-area segment of the inter-area P2MP Segmented LSP, it forwards
   the packet, based on MPLS switching, onto another "outgoing" intra-
   area segment of the inter-area P2MP Segmented LSP.

   If the outgoing intra-area segment is instantiated using a P2MP LSP,
   and if there is a one-to-one mapping between the outgoing intra-area
   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 is a many-to-one mapping between outgoing intra-area
   segments and the P2MP LSP then the ABR MUST pop the incoming



Rekhter                                                        [Page 28]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   segment's label stack and first push the upstream assigned label
   corresponding to the outgoing intra-area segment, if such a label 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 assigned by the
   leaf to the segment, followed by the label stack of the P2P or MP2P
   LSP to the leaf.


12.2. Data Plane Procedures on an Egress PE

   An egress PE must first identify the inter-area P2MP segmented LSP
   based on the incoming label stack. After this identification the
   egress PE must forward the packet using the application that is bound
   to the inter-area P2MP segmented LSP.

   Note that the application specific forwarding for MVPN service may
   require the egress PE to determine whether the packets were received
   from the expected sender PE.  When the application is MVPN then the
   FEC of an inter-area P2MP Segmented LSP is at the granularity of the
   sender PE. Note that MVPN intra-AS I-PMSI auto-discovery routes and
   S-PMSI auto-discovery routes both carry the Originating Router IP
   Address. Thus an egress PE could associate the data arriving on P-
   tunnels advertised by these routes with the Originating Router IP
   Address carried by these routes which is the same as the ingress PE.
   Since a unique label stack is associated with each such FEC, the
   egress PE can determine the sender PE from the label stack.

   Likewise for VPLS service for the purposes of MAC learning the egress
   PE must be able to determine the "VE-ID" from which the packets have
   been received. The FEC of the VPLS auto-discovery routes carries the
   VE-ID. Thus an egress PE could associate the data arriving on P-
   tunnels advertised by these routes with the VE-ID carried by these
   routes. Since a unique label stack is associated with each such FEC,
   the egress PE can perform MAC learning for packets received from a
   given VE-ID.

   When the application is global table multicast it is sufficient for
   the label stack to include identification of 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 to which it has bound a particular
   (S/*, G) and must accept packets with only that label for that (S/*,



Rekhter                                                        [Page 29]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   G).


12.3. Data Plane Procedures on an Ingress PE

   The Ingress PE must perform application specific forwarding
   procedures to identify the outgoing inta-area segment of an incoming
   packet.

   If the outgoing intra-area segment is instantiated using a P2MP LSP,
   and if there is a one-to-one mapping between the outgoing intra-area
   segment and the P2MP LSP, then the ingress PE MUST encapsulate the
   packet in the label stack of the outgoing P2MP LSP.  If there is a
   many-to-one mapping between outgoing intra-area segments and the P2MP
   LSP then the PE  MUST first push the upstream assigned label
   corresponding to the outgoing intra-area segment, if such a label 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 assigned by the leaf to the segment, followed by the
   label stack of the P2P or MP2P LSP to the leaf.


12.4. Data Plane Procedures on Transit Routers

   When procedures in this document are followed to signal inter-area
   P2MP Segmented LSPs then tansit routers in each area perform only
   MPLS switching.



13. Support for Inter-Area Transport LSPs

   This section describes OPTIONAL procedures that allow to aggregate
   multiple (inter-area) P2MP service LSPs into a single inter-area P2MP
   transport LSPs, and then apply the segmentation procedures, as
   specified in this document, to these inter-area P2MP transport LSPs
   (rather than applying these procedures directly to the inter-area
   P2MP service LSPs).








Rekhter                                                        [Page 30]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


13.1. Transport Tunnel Tunnel Type

   For the PMSI Tunnel Attribute we define a new Tunnel type, called
   "Transport Tunnel", whose Tunnel Identifier is a tuple <Source PE
   Address, Local Number>. This Tunnel type is assigned a value of 8.
   The Source PE Address is the address of the PE that originates the
   (service) auto-discovery route that carries this attribute, and the
   Local Number is a number that is unique to the Source PE. The length
   of the Local Number part is the same as the length of the Source PE
   Address. Thus if the Source PE Address is an IPv4 address, then the
   Local Number part is 4 octets, and if the Source PE Address is an
   IPv6 address, then the Local Number part is 16 octets.


13.2. Discovering Leaves of the Inter-Area P2MP Service LSP

   When aggregating multiple P2MP LSPs using P2MP LSP hierarchy,
   determining the leaf nodes of the LSPs being aggregated is essential
   for being able to tradeoff the overhead due to the P2MP LSPs vs
   suboptimal use of bandwidth due to the partial congruency of the LSPs
   being aggregated.

   Therefore, if a PE that is a 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, as well as those of
   the other service LSPs being aggregated).

   To accomplish this the PE sets the PMSI Tunnel attribute of the
   service auto-discovery route associated with that LSP as follows.
   The Tunnel Type is set to "No tunnel information present", Leaf
   Information Required flag is set to 1, the route MUST NOT carry the
   P2MP Segmented Next-Hop extended community. In contrast to the
   procedures for the MVPN and VPLS auto-discovery routes described so
   far, the Route Reflectors that participate in the distribution of
   this route need not be ABRs


13.3. Discovering the P2MP FEC of the Inter-Area P2MP Transport LSP

   Once the root PE determines all the leaves of a given P2MP service
   LSP, the PE (using some local to the PE criteria) selects a
   particular inter-area transport P2MP LSP to be used for carrying the
   (inter-area) service P2MP LSP.

   Once the PE selects the transport P2MP LSP, the PE (re)originates the
   service auto-discovery route. The PMSI Tunnel attribute of this route
   now carries the Transport Tunnel ID of the selected transport tunnel,



Rekhter                                                        [Page 31]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   with the Tunnel Type set to "Transport Tunnel". Just as described
   earlier, this service auto-discovery route MUST NOT carry the P2MP
   Segmented Next-Hop extended community. Just as described earlier, the
   Route Reflectors that participate in the distribution of this route
   need not be ABRs.


13.4. Egress PE Procedures for Inter-Area P2MP Transport LSP

   When an egress PE receives and accepts an MVPN or VPLS service auto-
   discovery route, if the Leaf Information Required flag in the PMSI
   Tunnel attribute of the received auto-discovery route is set to 1,
   and the route does not carry the P2MP Segmented Next-Hop extended
   community, then the egress PE following the "regular" MVPN or VPLS
   procedures, as specified in [MVPN-BGP] and [VPLS-P2MP], associated
   with the received auto-discovery route originates a Leaf auto-
   discovery route.

   In addition, if the Tunnel Type in the PMSI Tunnel attribute of the
   received service auto-discovery route is set to "Transport Tunnel",
   the egress PE originates yet another Leaf auto-discovery route.

   The format of the Route Key field of MCAST-VPN NLRI of this
   additional Leaf auto-discovery route is the same as defined in
   Section "Leaf Auto-Discovery Route for Global Table Multicast". The
   Route Key field of MCAST-VPN NLRI of this route is constructed as
   follows:


       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 received S-PMSI auto-discovery route.

       Multicast Group Length, Multicast Group - constructed from
          Local Number part of the Tunnel Identifier carried in the
          received S-PMSI auto-discovery route.

       Ingress PE IP Address is constructed from the Source PE
          address part of the Tunnel Identifier carried in the
          received S-PMSI auto-discovery route.


   The egress PE, when determining the upstream ABR, follows the
   procedures specified in Section 6.1 for global table multicast.

   From that point on we follow the procedures used for the Leaf auto-



Rekhter                                                        [Page 32]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   discovery routes for global table multicast, as outlined below.


13.5. Egress ABR, Ingress ABR, Ingress PE procedures for Inter-Area

   Transport LSP"

   When an egress ABR receives the Leaf auto-discovery route, the egress
   ABR will advertise into the egress area an S-PMSI auto-discovery
   route whose NLRI is the same as the received Leaf auto-discovery
   route, minus the Ingress PE IP address. The PMSI Tunnel attribute of
   this route contains the identity of a particular intra-area P2MP LSP
   and an upstream-assigned MPLS label. The egress PE(s) will import
   this route.

   The egress ABR will also propagate, with appropriate modifications,
   the received Leaf auto-discovery route into the backbone area.

   Likewise, an ingress ABR will advertise into the backbone area an S-
   PMSI auto-discovery route whose NLRI is the same as the received Leaf
   auto-discovery route, minus the Ingress PE IP address. The egress
   ABR(s) will import this route.

   The ingress ABR will also propagate, with appropriate modifications,
   the received Leaf auto-discovery route into the ingress area.

   Finally the ingress PE will advertise into the ingress area an S-PMSI
   auto-discovery route whose NLRI is the same as the received Leaf
   auto-discovery route, minus the Ingress PE IP address. The ingress
   ABR(s) and other PE(s) in the ingress area, if any, will import this
   route. The ingress PE will use the (intra-area) P2MP LSP advertised
   in this route for carrying traffic associated with the original
   service auto-discovery route advertised by the PE.



13.6. Discussion

   Use of inter-area transport P2MP LSPs, as described in this section,
   creates a level of indirection between (inter-area) P2MP service
   LSPs, and intra-area transport LSPs that carry the service LSPs.
   Rather than segmenting (inter-area) service P2MP LSPs, and then
   aggregating (intra-area) segments of these 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,
   then segments such inter-area transport P2MP LSPs, and then
   aggregates (intra-area) segments of these inter-area transport LSPs
   into intra-area transport LSPs.



Rekhter                                                        [Page 33]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   On one hand this approach could result in reducing the state (and the
   overhead associated with maintaining the state) on ABRs.  This is
   because instead of requiring ABRs to maintain state for individual
   P2MP service LSPs, ABRs would need to maintain state only for the
   inter-area P2MP transport LSPs. Note however, that this reduction is
   possible only if a single inter-area P2MP transport LSP aggregates
   more than one (inter-area) service LSP. In the absence of such
   aggregation, use of inter-area transport LSPs provides no benefits,
   yet results in extra overhead. And while such aggregation does allow
   to reduce state on ABRs, it comes at a price, as described below.

   As we mentioned before, aggregating multiple P2MP service LSPs into a
   single inter-area P2MP transport LSP requires the PE rooted at these
   LSPs to determine all the leaf nodes of the service LSPs to be
   aggregated. This means that the root PE has to track all the leaf PEs
   of these LSPs. In contrast, when one applies segmentation procedures
   directly to the P2MP service LSPs, the root PE has to track only the
   leaf PEs in its own IGP area, plus the ingress ABR(s).  Likewise, an
   ingress ABR has to track only the egress ABRs. Finally, an egress ABR
   has to track only the leaf PEs in its own area.  Therefore, while the
   total overhead of leaf tracking due to the P2MP service LSPs is about
   the same in both approaches, the distribution of this overhead is
   different. Specifically, when one uses inter-area P2MP transport
   LSPs, this overhead is concentrated on the ingress PE.  When one
   applies segmentation procedures directly to the P2MP service LSPs,
   this overhead is distributed among ingress PE and ABRs.

   Moreover, when one uses inter-area P2MP transport LSPs, ABRs have to
   bear the overhead of leaf tracking for inter-area P2MP transport
   LSPs. In contrast, when one applies segmentation procedures directly
   to the P2MP service LSPs, there is no such overhead (as there are no
   inter-area P2MP transport LSPs).

   Use of inter-area P2MP transport LSPs may also result in more
   bandwidth inefficiency, as compared to 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. To illustrate this consider the following example.

   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 that PE2 in Area 2 has an MVPN site with receivers
   for (C-S1, C-G1), PE3 and PE4 in Area 3 have an MVPN site with
   receivers both for (C-S1, C-G1) and for (C-S2, C-G2). Finally, assume
   that PE5 in Area 4 has an MVPN site with receivers for (C-S2, C-G2).

   When segmentation applies directly to the P2MP service LSPs then Area



Rekhter                                                        [Page 34]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


   2 would have just one intra-area transport LSP which would carry the
   egress area segment of the P2MP service LSP for (C-S1, C-G1); Area 3
   would have just one intra-area transport LSP which would carry 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 would have just one
   intra-area transport LSP which would carry 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 achieve 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. While such aggregation would reduce
   state on ABRs, it would also result in bandwidth inefficiency, as (C-
   S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but also
   to PE5, which has no receivers for this stream. Likewise, (C-S2, C-
   G2) will be delivered not just to PE3, PE4, and PE5, but also to PE2,
   which has no receivers for this stream.



14. IANA Considerations

   This document defines a new BGP Extended Community called "Inter-area
   P2MP Segmented Next-Hop". This community is IP Address Specific, of
   an extended type, and is transitive.  A codepoint for this community
   should be assigned both from the IPv4 Address Specific Extended
   Community registry, and from the IPv6 Address Specific Extended
   Community registry.  The same code point should be assigned from both
   registries.

   This document also assigns a new Tunnel Type in the PMSI Tunnel
   Attribute, called the "Transport Tunnel". This Tunnel Type is
   assigned a value of 8.


15. Security Considerations

   These will be spelled out in a future revision.











Rekhter                                                        [Page 35]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


16. Acknowledgements

   We would like to thank Eric Rosen for his comments.


17. References

17.1. Normative References

   [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332

   [RFC2119] "Key words for use in RFCs to Indicate Requirement
   Levels.", Bradner, March 1997

   [RFC4684] P. Marques et. al., "Constrained Route Distribution for
   Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)
   Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684,
   November 2006

   [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP
   VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, draft-ietf-
   l3vpn-2547bis-mcast-bgp

   [[VPLS-P2MP] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang,
   draft-ietf-l2vpn-vpls-mcast

   [L3VPN-IBGP] "Internal BGP as PE-CE protocol", Pedro Marques, et al.,
   draft-ietf-l3vpn-ibgp, work in progress

   [MVPN-WILDCARD-SPMSI] "Wildcards in Multicast VPN Auto-Discovery
   Routes", Eric Rosen, et al., draft-ietf-l3vpn-mvpn-wildcards, work in
   progress

   [BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
   "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.


17.2. Informative References

   [SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al.,
   draft-ietf-mpls-seamless-mpls










Rekhter                                                        [Page 36]


Internet Draft    draft-ietf-mpls-seamless-mcast-03.txt    December 2011


18. Author's Address

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

   Rahul Aggarwal
   Email: raggarwa_1@yahoo.com

   Thomas Morin
   France Telecom R & D
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   Email: thomas.morin@orange-ftgroup.com

   Irene Grosclaude
   France Telecom R & D
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   Email: irene.grosclaude@orange-ftgroup.com

   Nicolai Leymann
   Deutsche Telekom AG
   Winterfeldtstrasse 21
   Berlin  10781
   DE
   Email: n.leymann@telekom.de

   Samir Saad
   AT&T
   Email: ss2539@att.com
















Rekhter                                                        [Page 37]