Network Working Group Y. Rekhter Internet Draft Juniper Networks Expiration Date: June 2011 R. Aggarwal Juniper Networks T. Morin France Telecom I. Grosclaude France Telecom N. Leymann Deutsche Telekom AG December 07, 2010 Inter-Area P2MP Segmented LSPs draft-raggarwa-mpls-seamless-mcast-02.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-raggarwa-mpls-seamless-mcast-02.txt December 2010 Copyright and License Notice Copyright (c) 2010 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 in an IGP area then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used. The applications/services that use such an inter- area service LSP may be BGP MVPN, VPLS multicast or Internet multicast over MPLS. Rekhter [Page 2] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 Table of Contents 1 Specification of requirements ......................... 3 2 Introduction .......................................... 4 3 General Assumptions and Terminology ................... 4 4 Discovering the P2MP FEC of the Inter-Area P2MP Service LSP 5 4.1 BGP MVPN .............................................. 5 4.2 BGP VPLS or LDP VPLS with BGP A-D ..................... 6 4.3 Internet Multicast .................................... 6 5 Procedures for constructing segmented inter-area P2MP LSP .6 5.1 Egress PEs ............................................ 7 5.1.1 Determining the Ingress PE/ASBR ....................... 7 5.1.2 Originating a Leaf Auto-Discovery Route ............... 7 5.1.2.1 Leaf A-D Route for MVPN and VPLS ...................... 7 5.1.2.2 Leaf A-D Route for Internet Multicast ................. 8 5.1.2.3 Constructing Rest of the Leaf A-D Route ............... 9 5.2 Egress ABR ............................................ 9 5.2.1 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area 10 5.2.2 P2MP mLDP LSP as the intra-area LSP in the egress area ....12 5.3 Ingress ABR ........................................... 13 5.3.1 P2MP RSVP-TE LSP as the intra-area LSP in the backbone area 13 5.3.2 P2MP mLDP LSP as the intra-area LSP in the backbone area ..13 5.4 Ingress PE/ASBR ....................................... 14 5.4.1 P2MP RSVP-TE LSP as the intra-area LSP in the ingress area 14 5.4.2 P2MP mLDP LSP as the intra-area LSP in the ingress area ...14 6 IANA Considerations ................................... 15 7 Security Considerations ............................... 15 8 References ............................................ 15 8.1 Normative References .................................. 15 9 Author's Address ...................................... 15 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]. Rekhter [Page 3] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 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, 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 LSPs or P2P RSVP-TE LSPs may be used. The applications/services that use such an inter- area service LSP may be BGP MVPN, VPLS multicast or Internet multicast over MPLS. The primary use case of such segmented P2MP service LSPs is when the PEs are in different areas but in the same AS and thousands or more of PEs require P2MP connectivity. This may be the case when MPLS is pushed further to the metro edge and the metros are in different areas. 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-MCAST] 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-MCAST] where each intra-AS segment is constructed using inter-area segmented P2MP LSPs as specified in this document. 3. General Assumptions and Terminology Assume BGP is used as an inter-area routing and label distribution protocol for unicast /32 routes for the PEs. Assume ABRs act as Route Reflectors for these routes. Futhermore, assume ABRs set BGP Next Hop to self for these routes. 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. There could be either 1:1 or n:1 mapping between segments 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. Rekhter [Page 4] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 The ingress area segment of a P2MP service LSP is rooted at PE (or at ASBR in the case where the P2MP service LSP spans multiple ASes). The leaves of this segment are other PEs 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 it leaves ABRs that are connected to the egress area(s). 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. 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. 4. 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). 4.1. BGP MVPN Egress PEs discover the P2MP FEC of the service LSPs used by BGP MVPN using the I-PMSI or S-PMSI A-D routes that are originated by the ingress PEs or ASBRs following the procedures of [BGP-MVPN]. The NLRI of such routes encodes the P2MP FEC. The procedures in this document assume all ABRs act as Route Reflectors for MVPN auto- discovery (A-D) routes. The "Leaf Information Required" flag MUST be set in the P-Tunnel attribute carried in such routes. Before any Leaf auto discovery route is avertised by a PE or ABR in the same area, as described in the following sections, an I-/S-PMSI autodiscovery 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. 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 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 still can be configured to be the Route Reflectors for C-multicast routes, in which case they will participate in the Rekhter [Page 5] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 propagation of C-multicast routes. 4.2. BGP VPLS or LDP VPLS with BGP A-D Egress PEs discover the P2MP FEC of the service LSPs used by VPLS, using using the VPLS A-D routes that are originated by the ingress PEs [BGP-VPLS, VPLS-AD] or S-PMSI A-D 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. Before any Leaf auto discovery route is avertised by a PE or ABR in its own area, as described in the following sections, an VPLS/S-PMSI autodiscovery 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. The procedures in this document assume all ABRs act as Route Reflectors for VPLS auto-discovery (A-D) routes. These ABRs/RRs do NOT modify BGP Next Hop when re-advertising these A-D routes. 4.3. Internet Multicast This section describes how the egress PEs discover the P2MP FEC when the application is internet multicast. 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. This document assumes that for each (S/*,G) we have a distinct inter- area P2MP service LSP. 5. Procedures for constructing segmented inter-area P2MP LSP This section applies to the scenario where the egress PE and the ingress PE/ASBR are in different IGP areas. Rekhter [Page 6] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 5.1. Egress PEs 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. 5.1.1. Determining the Ingress PE/ASBR The egress PE discovers the P2MP FEC of an inter-area P2MP Segmented Service LSP as described in section 3. When an egress PE discovers this P2MP FEC it MUST first determine the ingress PE/ASBR of such a FEC as follows. If the application is MVPN or VPLS the ingress PE/ASBR's address is the BGP next-hop of the MVPN or VPLS A-D route from which the P2MP FEC is derived. If the application is internet 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 PE 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 MUST be advertised using the multicast SAFI i.e. SAFI 2 and the VRF Route Import Extended Community MUST be carried in such routes. The ingress PE address as determined by the egress PE is the IP address determined from the VRF Route Import Extended community, that is present in the best route to reach S/RP. 5.1.2. Originating a Leaf Auto-Discovery Route If the P2MP FEC was derived from a MVPN or VPLS A-D route then the egress PE MUST originate a Leaf auto-discovery (A-D) route if the MVPN or VPLS A-D route carries a P-Tunnel Attribute with the "Leaf Information Required" flag set. If the P2MP FEC was derived from an Internet Multicast S/*, G and the ingress PE's address is not the same as the egress PE, then the egress PE MUST originate a Leaf auto-discovery (A-D) route. 5.1.2.1. Leaf A-D Route for MVPN and VPLS If the P2MP FEC was derived from MVPN or VPLS A-D routes then the Route Key field of the Leaf A-D route contains the NLRI of the A-D Rekhter [Page 7] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 route from which the P2MP FEC was derived. This follows procedures described in [BGP-MVPN, VPLS-P2MP]. 5.1.2.2. Leaf A-D Route for Internet Multicast If the application is internet multicast than the the MCAST-VPN NLRI of the Leaf A-D 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) | +-----------------------------------+ | Ingress PE 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), and Ingress PE IP Address is set to the address carried in the BGP Next Hop of the route to S/RP. 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 whole MCAST-VPN NLRI of the route 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 8] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 | Ingress PE IP Addr | +-----------------------------------+ | Originating Router's IP address | +-----------------------------------+ When the PE deletes (S,G)/(*,G) state that was created as a result of receiving PIM 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. The support of PIM-SM in ASM mode requires further details and they will be provided in the next revision. 5.1.2.3. Constructing Rest of the Leaf A-D Route The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD be set to the same IP address as the one carried in the Originating Router's IP Address field of the route. To constrain distribution of this route, the originating PE constructs an IP-based Route Target community by placing the IP address of the egress ABR 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 egress ABR's address is the BGP next-hop of the BGP route to reach the ingress PE/ASBR. The PE then advertises this route to the (egress) ABR/RR. 5.2. Egress ABR When an egress ABR receives a Leaf auto-discovery route, or a withdraw of a previousely received 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 egress ABR originates a Leaf A-D 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 A-D 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). 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 Rekhter [Page 9] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 Router's IP Address field of the route. To constrain distribution of this route, the originating PE constructs an IP-based Route Target community by placing the IP address of the ingress ABR 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. The ingress ABR is the BGP Next Hop of the route to the ingress PE/ASBR. If the RD of the received Leaf A-D route is 0, then the Ingress PE address is determined from the the received Leaf A-D route. If the RD of the received Leaf A-D route is not 0, the ABR finds an MVPN I-PMSI/S-PMSI A-D route or VPLS A-D or S-PMSI A-D route whose NLRI has the same value as the Route Key field of the the Leaf A-D route. The BGP next-hop of this NLRI is the address of the ingress PE. To carry information identifying the upstream PE/ABR that has to process this Leaf Auto-Discovery route, the originating PE constructs an IP-based Route Target community by placing the IP address of the ingress ABR 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. The ingress ABR is the BGP Next Hop of the route to the ingress PE/ASBR. If the RD of the received Leaf A-D route is 0, then the Ingress PE address is determined from the the received Leaf A-D route. If the RD of the received Leaf A-D route is not 0, the ABR finds an MVPN I-PMSI/S-PMSI A-D route or VPLS A-D or S-PMSI A-D route whose NLRI has the same value as the Route Key field of the the Leaf A-D route. The BGP next-hop of this NLRI is the address of the ingress PE. The ABR then advertises this Leaf A-D route to the ABRs 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. 5.2.1. 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). Note that an existing intra-area P2MP LSP may be used solely for that particular inter-area P2MP service LSP, or for other inter-area P2MP Rekhter [Page 10] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 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. When the RD of the received Leaf A-D route is not set to zero then the ABR MUST re-advertise in the egress area the MVPN/VPLS A-D route, that matches the Leaf A-D route to signal the binding of the intra- area P2MP RSVP-TE 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 PMSI Tunnel attribute of the re- advertised route specifies an intra-area P2MP RSVP-TE 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]. If the RD of the received Leaf A-D route is zero, then the egress ABR need not advertise any auto-discovery routes. As this is the case of inter-area P2MP service LSP being associated with the Internet multicast service. In this case the the egress PEs do not require the binding of the intra-area P2MP LSP to the inter-area P2MP service LSP. If an egress PE receives multicast packets over an intra-area P2MP LSP, with no MPLS label in the stack to identify the inter-area P2MP service LSP, the egress PE must forward the packets using its internet multicast forwarding table. If the mapping between the inter-area P2MP service LSP for Internet 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 PE/ABR. The expected PE/ABR is the PE/ABR to which the Leaf A-D route is sent by the egress PE. Packets received from another PE/ABR for that (S, G) MUST be dropped. To allow the egress PE to determine the sender, the intra-area P2MP LSP must be signaled with no PHP, when the mapping between the inter-area P2MP service LSP for Internet multicast service and the intra-area P2MP LSP is many-to-one. This document assumes that a single S-PMSI service LSP carries only a single (C-S,C-G). Thus if segments of multiple MVPN or VPLS S-PMSI service LSPs are carried over a given intra-area P2MP LSP, each of these segments would require a distinct upstream-assigned label, even Rekhter [Page 11] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 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 traversting this ABR (that applies to both the ingress and the egress ABRs). 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. 5.2.2. P2MP mLDP LSP as the intra-area LSP in the egress area If P2MP mLDP LSP is used as the intra-area LSP in the egress area, and the RD of the received Leaf A-D route is set to 0 then the egress ABR constructs an S-PMSI A-D. The PMSI Tunnel attribute of the route contains the identity of the intra-area P2MP LSP. Note that the PMSI Tunnel attribute does not carry an upstream assigned 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 A-D route. The egress ABR advertises this route into the egress area. The forwarding considerations including the determination of whether packets are received from an expected sender are the same as the ones above with P2MP RSVP-TE. If P2MP mLDP LSP is used as the intra-area LSP in the egress area, and the RD of the received Leaf A-D route is not set to 0, ABR MUST re-advertise the MVPN/VPLS A-D route, that matches the Leaf A-D route to signal the binding of the intra-area P2MP RSVP-TE 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 PMSI Tunnel attribute of the re-advertised route specifies an intra-area P2MP RSVP-TE 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. The egress PEs MUST join the intra-area P2MP LDP LSP that is encoded in the PMSI Tunnel Attribute of the A-D routes that carry the binding of the inter-area P2MP service LSP to the intra-area P2MP LDP LSP. Rekhter [Page 12] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 5.3. Ingress ABR When an ingress ABR receives a Leaf auto-discovery route, or a withdraw of a previousely received Leaf auto-discovery route from an (egress) ABR, 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 originates a Leaf A-D route towards the ingress PE/ASBR, whose MCAST-VPN-NLRI is constructed using procedures in section 4.2 with the difference that the IP based RT contains the ingress PE/ASBR address and not the ingress ABR address. 5.3.1. P2MP RSVP-TE LSP as the intra-area LSP in the backbone area If the RD of the received Leaf A-D route is not zero, and P2MP RSVP- TE LSP is used as the the intra-area LSP in the backbone area, then the procedures for binding the backbone area segment of the inter- area P2MP LSP to the intra-area P2MP LSP in the backbone area, are the same as in section 4.2.1. When the RD of the received Leaf A-D route is zero, as is the case where the inter-area service P2MP LSP is associated with the Internet multicast service, then in addition to the procedures in section 4.2.1 the ingress ABR MUST originate a S-PMSI A-D route. The PMSI Tunnel attribute of the route contains the identity of the intra-area P2MP LSP and a distinct 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 A-D route. The ingress ABR advertises this route into the backbone area. 5.3.2. P2MP mLDP LSP as the intra-area LSP in the backbone area If the RD of the received Leaf A-D route is not zero, and P2MP mLDP LSP is used as the the intra-area LSP in the backbone area, then the procedures for binding the backbone area segment of the inter-area P2MP LSP to the intra-area P2MP LSP in the backbone area, are the same as in section 4.2.2. When the RD of the received Leaf A-D route is zero then in addition to the procedures in section 4.2.2 the S-PMSI A-D route's PMSI Tunnel Attribute MUST carry an upstream assigned MPLS label. Rekhter [Page 13] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 5.4. Ingress PE/ASBR When an ingress PE/ASBR receives a Leaf auto-discovery route, or a withdraw of a previously received Leaf auto-discovery route, and the Route Target extended community carried by the route contains the IP address of this PE, then the following procedures will be executed. If the RD of the received Leaf A-D route is 0, as is the case when the inter-area service P2MP LSP is associated with the Internet multicast service, 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. 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. If the RD of the received Leaf A-D route is not 0, the ingress PE/ASBR finds an MVPN I-PMSI/S-PMSI A-D route or VPLS A-D or S-PMSI A-D route whose NLRI has the same value as the Route Key field of the the Leaf A-D route. 5.4.1. P2MP RSVP-TE LSP as the intra-area LSP in the ingress area If the RD of the received Leaf A-D route is not zero, and P2MP RSVP- TE LSP is used as the the intra-area LSP in the ingress area, then the procedures for binding the ingress segment of the inter-area P2MP LSP to the intra-area P2MP LSP in the ingress area, are the same as in section 4.2.1. When the RD of the received Leaf A-D route is zero than in addition to the procedures in section 4.2.1 the ingress PE MUST originate a S- PMSI A-D route. The PMSI Tunnel attribute of the route contains 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 A-D route. The ingress PE advertises this route into the ingress area. 5.4.2. P2MP mLDP LSP as the intra-area LSP in the ingress area If the RD of the received Leaf A-D route is not zero, and P2MP RSVP- TE LSP is used as the the intra-area LSP in the ingress area, then the procedures for binding the ingress segment of the inter-area P2MP LSP to the intra-area P2MP LSP in the ingress area, are the same as in section 4.2.2. Rekhter [Page 14] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 When the RD of the received Leaf A-D route is zero than in addition to the procedures in section 4.2.2 the S-PMSI A-D route's PMSI Tunnel Attribute MUST carry an upstream assigned MPLS label. 6. IANA Considerations These will be spelled out in the next revision. 7. Security Considerations These will be spelled out in a future revision. 8. References 8.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 [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 9. Author's Address Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: yakov@juniper.net Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Rekhter [Page 15] Internet Draft draft-raggarwa-mpls-seamless-mcast-02.txt December 2010 Phone: +1-408-936-2720 Email: rahul@juniper.net Thomas Morin France Telecom R & D 2, avenue Pierre-Marzin 22307 Lannion Cedex France Email: thomas.morin@francetelecom.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 Rekhter [Page 16]