idnits 2.17.1 draft-ietf-mpls-seamless-mcast-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 467 has weird spacing: '...MUST be adver...' == Line 479 has weird spacing: '...MUST be adver...' == Line 580 has weird spacing: '... System with ...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 18, 2011) is 4627 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BGP-MVPN' is mentioned on line 511, but not defined == Missing Reference: 'VPLS-P2MP' is mentioned on line 1352, but not defined == Missing Reference: 'RFC5331' is mentioned on line 214, but not defined == Missing Reference: 'RFC4360' is mentioned on line 246, but not defined == Missing Reference: 'BGP-VPLS' is mentioned on line 342, but not defined == Missing Reference: 'VPLS-AD' is mentioned on line 342, but not defined == Missing Reference: 'BGP-MP' is mentioned on line 596, but not defined == Missing Reference: 'RFC1997' is mentioned on line 717, but not defined == Missing Reference: 'RFC 5332' is mentioned on line 902, but not defined == Missing Reference: 'MVPN-WILDCARD-SPMSI' is mentioned on line 1107, but not defined == Unused Reference: 'RFC5332' is defined on line 1523, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Rekhter 3 Internet Draft Juniper Networks 4 Expiration Date: February 2012 5 R. Aggarwal 6 Juniper Networks 8 T. Morin 9 France Telecom 11 I. Grosclaude 12 France Telecom 14 N. Leymann 15 Deutsche Telekom AG 17 S. Saad 18 AT&T 20 August 18, 2011 22 Inter-Area P2MP Segmented LSPs 24 draft-ietf-mpls-seamless-mcast-01.txt 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that other 33 groups may also distribute working documents as Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Copyright and License Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Abstract 75 This document describes procedures for building inter-area point-to- 76 multipoint (P2MP) segmented service LSPs by partitioning such LSPs 77 into intra-area segments and using BGP as the inter-area routing and 78 label distribution protocol. Within each IGP area the intra-area 79 segments are either carried over intra-area P2MP LSPs, using P2MP LSP 80 hierarchy, or instantiated using ingress replication. The intra-area 81 P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress 82 replication is used in an IGP area then MP2P LDP LSPs or P2P RSVP-TE 83 LSPs may be used in the IGP area. The applications/services that use 84 such an inter-area service LSP may be BGP MVPN, VPLS multicast or 85 Internet multicast over MPLS. 87 Table of Contents 89 1 Specification of requirements ......................... 4 90 2 Introduction .......................................... 4 91 3 General Assumptions and Terminology ................... 5 92 4 Inter-area P2MP Segmented Next-Hop Extended Community . 6 93 5 Discovering the P2MP FEC of the Inter-Area P2MP Service LSP 7 94 5.1 BGP MVPN .............................................. 7 95 5.2 BGP VPLS or LDP VPLS with BGP A-D ..................... 8 96 5.3 Internet Multicast .................................... 9 97 6 Egress PE Procedures .................................. 10 98 6.1 Determining the Upstream ABR/PE/ASBR .................. 10 99 6.2 Originating a Leaf Auto-Discovery Route ............... 12 100 6.2.1 Leaf A-D Route for MVPN and VPLS ...................... 12 101 6.2.2 Leaf A-D Route for Internet Multicast ................. 12 102 6.2.3 Constructing the Rest of the Leaf A-D Route ........... 14 103 6.3 PIM-SM in ASM mode for Internet Multicast ............. 14 104 6.3.1 Option 1 .............................................. 15 105 6.3.1.1 Originating Source Active auto-discovery routes ....... 15 106 6.3.1.2 Receiving BGP Source Active auto-discovery route by PE ....15 107 6.3.1.3 Handling (S, G, RPTbit) state ......................... 16 108 6.3.2 Option 2 .............................................. 16 109 6.3.2.1 Originating Source Active auto-discovery routes ....... 16 110 6.3.2.2 Receiving BGP Source Active auto-discovery route ...... 17 111 6.3.2.3 Pruning Sources off the Shared Tree ................... 17 112 6.3.2.4 More on handling (S, G, RPTbit) state ................. 18 113 7 Egress ABR Procedures ................................. 18 114 7.1 P2MP LSP as the Intra-Area LSP in the Egress Area ..... 20 115 7.1.1 RD of the received Leaf-AD route is not zero or all ones ..20 116 7.1.2 RD of the received Leaf A-D route is zero or all ones . 21 117 7.1.2.1 Internet Multicast and S-PMSI A-D Routes .............. 21 118 7.1.2.2 Internet Multicast and Wildcard S-PMSI A-D Routes ..... 21 119 7.1.3 Internet Multicast and the Expected Upstream Node ..... 22 120 7.1.4 P2MP LDP LSP as the Intra-Area P2MP LSP in the Egress Area 22 121 7.1.5 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area 22 122 7.2 Ingress Replication in the Egress Area ................ 23 123 8 Ingress ABR Procedures for constructing segmented inter-area P2MP LSP 23 124 8.1 P2MP LSP as the Intra-Area LSP in the Backbone Area ... 23 125 8.2 Ingress Replication in the Backbone Area .............. 24 126 9 Ingress PE/ASBR Procedures ............................ 24 127 9.1 P2MP LSP as the intra-area LSP in the ingress area .... 25 128 9.2 Ingress Replication in the Ingress Area ............... 26 129 10 Common Tunnel Type in the Ingress and Egress Areas .... 26 130 11 Placement of Ingress and Egress PEs ................... 27 131 12 Data Plane ............................................ 27 132 12.1 Data Plane Procedures on an ABR ....................... 27 133 12.2 Data Plane Procedures on an Egress PE ................. 28 134 12.3 Data Plane Procedures on an Ingress PE ................ 29 135 12.4 Data Plane Procedures on Transit Routers .............. 29 136 13 Support for Inter-Area Transport LSPs ................. 29 137 13.1 Transport Tunnel Tunnel Type .......................... 30 138 13.2 Discovering Leaves of the Inter-Area P2MP Service LSP . 30 139 13.3 Discovering the P2MP FEC of the Inter-Area P2MP Transport LSP 30 140 13.4 Egress PE Procedures for Inter-Area P2MP Transport LSP ....31 141 13.5 Egress ABR, Ingress ABR, Ingress PE procedures for Inter-Area Transport LSP 32 142 13.6 Discussion ............................................ 32 143 14 IANA Considerations ................................... 34 144 15 Security Considerations ............................... 34 145 16 Acknowledgements ...................................... 35 146 17 References ............................................ 35 147 17.1 Normative References .................................. 35 148 17.2 Informative References ................................ 35 149 18 Author's Address ...................................... 35 151 1. Specification of requirements 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 2. Introduction 159 This document describes procedures for building inter-area point-to- 160 multipoint (P2MP) segmented service LSPs by partitioning such LSPs 161 into intra-area segments and using BGP as the inter-area routing and 162 label distribution protocol. Within each IGP area the intra-area 163 segments are either carried over intra-area P2MP LSPs, potentially 164 using P2MP LSP hierarchy, or instantiated using ingress replication. 165 The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP 166 mLDP. If ingress replication is used in an IGP area then MP2P LDP or 167 P2P RSVP-TE LSPs may be used in the IGP area. The 168 applications/services that use such an inter-area service LSP may be 169 BGP MVPN, VPLS multicast or Internet multicast over MPLS. 171 The primary use case of such segmented P2MP service LSPs is when the 172 PEs are in different areas but in the same AS and thousands or more 173 of PEs require P2MP connectivity. For instance this may be the case 174 when MPLS is pushed further to the metro edge and the metros are in 175 different IGP areas. This may also be the case when a Service 176 Provider's network comprises multiple IGP areas in a single 177 Autonomous System, with a large number of PEs. Seamless MPLS is the 178 industry term to address this case [SEAMLESS-MPLS]. Thus one of the 179 applicabilities of this document is that it describes the multicast 180 procedures for seamless MPLS. 182 It is to be noted that [BGP-MVPN], [VPLS-P2MP] already specify 183 procedures for building segmented inter-AS P2MP service LSPs. This 184 document complements those procedures as it extends the segmented 185 P2MP LSP model such that it is applicable to inter-area P2MP service 186 LSPs as well. Infact an inter-AS deployment could use inter-AS 187 segmented P2MP LSPs as specified in [BGP-MVPN, VPLS-P2MP] where each 188 intra-AS segment is constructed using inter-area segmented P2MP LSPs 189 as specified in this document. 191 3. General Assumptions and Terminology 193 This document assumes BGP is used as an inter-area routing and label 194 distribution protocol for the unicast IPv4 /32 or IPv6 /128 routes 195 for the PEs. This document also assumes ABRs act as Route Reflectors 196 (RR) for these routes. 198 When supporting segmentation of the inter-area P2MP MVPN service 199 LSPs, instead of assuming that BGP is used as an inter-area routing 200 and label distribution protocol for unicast IPv4 /32 or IPv6 /128 201 routes, it is sufficient to assume that BGP is used as an inter-area 202 routing protocol for unicast IPv4 /32 or IPv6 /128 routes used for 203 multicast forwarding (SAFI = 2). 205 Within an AS a P2MP service LSP is partitioned into 3 segments: 206 ingress area segment, backbone area segment, and egress area segment. 207 Within each area a segment is carried over an intra-area P2MP LSP or 208 instantiated using ingress replication. 210 When intra-area P2MP LSPs are used to instantiate the intra-area 211 segments there could be either 1:1 or n:1 mapping between intra-area 212 segments of the inter-area P2MP service LSP and a given intra-area 213 P2MP LSP. The latter is realized using P2MP LSP hierarchy with 214 upstream-assigned labels [RFC5331]. For simplicity we assume that 215 P2MP LSP hierarchy is used even with 1:1 mapping, in which case the 216 upstream-assigned label could be an implicit NULL. 218 When intra-area segments of the inter-area P2MP service LSP are 219 instantiated using ingress replication, then multiple such segments 220 may be carried in the same P2P RSVP-TE or MP2P LDP LSP. This can be 221 achieved using downstream-assigned labels alone. 223 The ingress area segment of a P2MP service LSP is rooted at a PE (or 224 at an ASBR in the case where the P2MP service LSP spans multiple 225 ASes). The leaves of this segment are other PEs/ASBRs and ABRs in 226 the same area as the root PE. The backbone area segment is rooted at 227 an ABR that is connected to the ingress area (ingress ABR), and has 228 as its leaves ABRs that are connected to the egress area(s) or PEs in 229 the backbone area. The egress area segment is rooted at an ABR in 230 the egress area (egress ABR), and has as its leaves PEs and ASBR in 231 that egress area (the latter covers the case where the P2MP service 232 LSP spans multiple ASes). Note that for a given P2MP service LSP 233 there may be more than one backbone segment, each rooted at its own 234 ingress ABR, and more than one egress area segment, each rooted at 235 its own egress ABR. 237 An implementation that supports this document MUST implement the 238 procedures described in the following sections to support inter-area 239 point-to-multipoint (P2MP) segmented service LSPs. 241 4. Inter-area P2MP Segmented Next-Hop Extended Community 243 This document defines a new BGP Extended Community "Inter-area P2MP 244 Next-Hop" extended community. This is an IP address specific Extended 245 Community, of an extended type and is transitive across AS boundaries 246 [RFC4360]. 248 A PE or an ABR or an ASBR constructs the Inter-area P2MP Segmented 249 Next-Hop Extended Community as follows: 251 - The Global Administrator field MUST be set to an IP address of 252 the PE or ASBR or ABR that originates or advertises the route, 253 which carries the P2MP Next-Hop Extended Community. For example 254 this address may be the loopback address or the PE, ASBR or ABR 255 that advertises the route. 257 - The Local Administrator field MUST be set to 0. 259 The detailed usage of this extended community is described in the 260 following sections. 262 5. Discovering the P2MP FEC of the Inter-Area P2MP Service LSP 264 The P2MP FEC identifies the inter-area P2MP service LSP. The egress 265 PEs need to learn this P2MP FEC in order to initiate the creation of 266 the egress area segment of the P2MP inter-area service LSP. 268 The P2MP FEC of the inter-area P2MP LSP is learned by the egress PEs 269 either by configuration, or based on the application-specific 270 procedures (e.g., MVPN-specific procedures, VPLS-specific 271 procedures). 273 5.1. BGP MVPN 275 Egress PEs discover the P2MP FEC of the service LSPs used by BGP MVPN 276 using the I-PMSI or S-PMSI A-D routes that are originated by the 277 ingress PEs or ASBRs following the procedures of [BGP-MVPN], along 278 with modifications as described in this document. The NLRI of such 279 routes encodes the P2MP FEC. The procedures in this document require 280 that at least one ABR in a given IGP area act as Route Reflector for 281 MVPN auto-discovery (A-D) routes. 283 The "Leaf Information Required" flag MUST be set in the P-Tunnel 284 attribute carried in such routes, when originated by the ingress PEs 285 or ASBRs, except for the case where (a) as a matter of policy 286 (provisioned on the ingress PEs or ASBRs) there is no aggregation of 287 ingress area segments of the service LSPs, and (b) mLDP is used as 288 the protocol to establish intra-area transport LSPs in the ingress 289 area. Before any Leaf auto discovery route is advertised by a PE or 290 ABR in the same area, as described in the following sections, an 291 I-/S-PMSI auto-discovery route is advertised either with an explicit 292 Tunnel Type and Tunnel Identifier in the PMSI Tunnel Attribute, if 293 the Tunnel Identifier has already been assigned, or with a special 294 Tunnel Type of "No tunnel information present" otherwise. 296 When the I/S-PMSI routes are re-advertised by an ingress ABR, the 297 "Leaf Information Required" flag MUST be set in the P-Tunnel 298 attribute present in the routes, except for the case where (a) as a 299 matter of policy (provisioned on the ingress ABR) there is no 300 aggregation of backbone area segments of the service LSPs, and (b) 301 mLDP is used as the protocol to establish intra-area transport LSPs 302 in the backbone area. Likewise, when the I/S-PMSI routes are re- 303 advertised by an egress ABR, the "Leaf Information Required" flag 304 MUST be set in the P-Tunnel attribute present in the routes, except 305 for the case where (a) as a matter of policy (provisioned on the 306 egress ABR) there is no aggregation of egress area segments of the 307 service LSPs, and (b) mLDP is used as the protocol to establish 308 intra-area transport LSPs in the egress area. 310 Note that the procedures in the above paragraph apply when intra-area 311 segments are realized by either intra-area P2MP LSPs or by ingress 312 replication. 314 When BGP MVPN I-PMSI or S-PMSI A-D routes are advertised or 315 propagated to signal Inter-area P2MP service LSPs, to indicate that 316 these LSPs should be segmented using the procedures specified in this 317 document, these routes MUST carry the Inter-area P2MP Segmented Next- 318 Hop Extended Community. This Extended Community MUST be included in 319 the I/S-PMSI A-D route by the PE or ASBR that originates such a route 320 and the Global Administrator field MUST be set to the advertising PE 321 or ASBR's IP address. This Extended Community MUST also be included 322 by ABRs as they re-advertise such routes. An ABR MUST set the Global 323 Administrator field of the P2MP Segmented Next-Hop Extended Community 324 to its own IP address. This allows ABRs and PEs/ASBRs to follow the 325 procedures in this document when these procedures differ from those 326 in [BGP-MVPN]. 328 To avoid requiring ABRs to participate in the propagation of C- 329 multicast routes, this document requires ABRs NOT to modify BGP Next 330 Hop when re-advertising Inter-AS I-PMSI A-D routes. For consitancy 331 this document requires ABRs to NOT modify BGP Next-Hop when re- 332 advertising both Intra-AS and Inter-AS I/S-PMSI A-D routes. The 333 egress PEs may advertise the C-multicast routes to RRs that are 334 different than the ABRs. However ABRs still can be configured to be 335 the Route Reflectors for C-multicast routes, in which case they will 336 participate in the propagation of C-multicast routes. 338 5.2. BGP VPLS or LDP VPLS with BGP A-D 340 Egress PEs discover the P2MP FEC of the service LSPs used by VPLS, 341 using the VPLS A-D routes that are originated by the ingress PEs 342 [BGP-VPLS, VPLS-AD] or S-PMSI A-D routes that are originated by the 343 ingress PE [VPLS-P2MP]. The NLRI of such routes encodes the P2MP FEC. 345 The "Leaf Information Required" flag MUST be set in the P-Tunnel 346 attribute carried in such routes, when originated by the ingress PEs 347 or ASBRs, except for the case where (a) as a matter of policy 348 (provisioned on the ingress PEs or ASBRs) there is no aggregation of 349 ingress area segments of the service LSPs, and (b) mLDP is used as 350 the protocol to establish intra-area transport LSPs in the ingress 351 area. Before any Leaf auto-discovery route is advertised by a PE or 352 ABR in the same area, as described in the following sections, an 353 VPLS/S-PMSI auto-discovery route is advertised either with an 354 explicit Tunnel Type and Tunnel Identifier in the PMSI Tunnel 355 Attribute, if the Tunnel Identifier has already been assigned, or 356 with a special Tunnel Type of "No tunnel information present" 357 otherwise. 359 When the VPLS/S-PMSI auto-discovery routes are re-advertised by an 360 ingress ABR, the "Leaf Information Required" flag MUST be set in the 361 P-Tunnel attribute present in the routes, except for the case where 362 (a) as a matter of policy (provisioned on the ingress ABR) there is 363 no aggregation of backbone area segments of the service LSPs, and (b) 364 mLDP is used as the protocol to establish intra-area transport LSPs 365 in the backbone area. Likewise, when the VPLS/S-PMSI auto-discovery 366 routes are re-advertised by an egress ABR, the "Leaf Information 367 Required" flag MUST be set in the P-Tunnel attribute present in the 368 routes, except for the case where (a) as a matter of policy 369 (provisioned on the egress ABR) there is no aggregation of egress 370 area segments of the service LSPs, and (b) mLDP is used as the 371 protocol to establish intra-area transport LSPs in the egress area. 373 When VPLS A-D or S-PMSI A-D routes are advertised or propagated to 374 signal Inter-area P2MP service LSPs, to indicate that these LSPs 375 should be segmented using the procedures specified in this document, 376 these routes MUST carry the Inter-area P2MP Segmented Next-Hop 377 Extended Community. This Extended Community MUST be included in the 378 A-D route by the PE or ASBR that originates such a route and the 379 Global Administrator field MUST be set to the advertising PE or 380 ASBR's IP address. This Extended Community MUST also be included by 381 ABRs as they re-advertise such routes. An ABR MUST set the Global 382 Administrator field of the P2MP Segmented Next-Hop Extended Community 383 to its own IP address. This allows ABRs and PEs/ASBRs to follow the 384 procedures in this document when these procedures differ from those 385 in [VPLS-P2MP]. 387 Note that the procedures in the above paragraph apply when intra-area 388 segments are realized by either intra-area P2MP LSPs or by ingress 389 replication. 391 The procedures in this document require that at least one ABR in a 392 given area act as Route Reflector for MVPN auto-discovery (A-D) 393 routes. These ABRs/RRs MUST NOT modify BGP Next Hop when re- 394 advertising these A-D routes. 396 5.3. Internet Multicast 398 This section describes how the egress PEs discover the P2MP FEC when 399 the application is internet multicast. 401 In the case where Internet multicast uses PIM-SM in ASM mode the 402 following assumes that an inter-area P2MP service LSP could be used 403 to either carry traffic on a shared (*,G), or a source (S,G) tree. 405 An egress PE learns the (S/*, G) of a multicast stream as a result of 406 receiving IGMP or PIM messages on one of its IP multicast interfaces. 407 This (S/*, G) forms the P2MP FEC of the inter-area P2MP service LSP. 408 For each (S/*,G) for which an inter-area P2MP service LSP is 409 instantiated, there may exist a distinct inter-area P2MP service LSP 410 or multiple inter-area P2MP service LSPs may be aggregated using a 411 wildcard (*, *) S-PMSI. 413 Note that this document does not require the use of (*, G) Inter-area 414 P2MP service LSPs when Internet multicast uses PIM-SM in ASM mode. 415 Infact PIM-SM in ASM mode may be supported entirely by using (S, G) 416 trees alone. 418 6. Egress PE Procedures 420 This section describes egress PE procedures for constructing 421 segmented inter-area P2MP LSP. The procedures in this section apply 422 irrespective of whether the egress PE is in a leaf IGP area, or the 423 backbone area or even in the same IGP area as the ingress PE/ASBR. 425 An egress PE applies procedures specified in this section to MVPN I- 426 PMSI or S-PMSI A-D routes only if these routes carry the Inter-area 427 P2MP Segmented Next-Hop Extended Community. An egress PE applies 428 procedures specified in this section to VPLS A-D or S-PMSI A-D routes 429 only if these routes carry the Inter-area P2MP Segmented Next-Hop 430 Extended Community. 432 In order to support Internet Multicast an egress PE MUST auto- 433 configure an import Route Target with the global administrator field 434 set to the AS of the PE and the local administrator field set to 0. 436 Once an egress PE discovers the P2MP FEC of an inter-area segmented 437 P2MP service LSP, it MUST propagate this P2MP FEC in BGP in order to 438 construct the segmented inter-area P2MP service LSP. This propagation 439 uses BGP Leaf auto-discovery routes. 441 6.1. Determining the Upstream ABR/PE/ASBR 443 The egress PE discovers the P2MP FEC of an inter-area P2MP Segmented 444 Service LSP as described in section 5. When an egress PE discovers 445 this P2MP FEC it MUST first determine the upstream node to reach such 446 a FEC. If the egress PE is in the egress area and the ingress PE is 447 not in the that egress area, then this upstream node would be the 448 egress ABR. If the egress PE is in the backbone area and the ingress 449 PE is not in the backbone area, then this upstream node would be the 450 ingress ABR. If the egress PE is in the same area as the ingress PE 451 then this upstream node would be the ingress PE. 453 If the application is MVPN or VPLS then the upstream node's IP 454 address is the IP address determined from the Global Administrator 455 field of the Inter-area P2MP Segmented Next-hop Extended Community. 456 As described in section 5 this Extended Community MUST be carried in 457 the MVPN or VPLS A-D route from which the P2MP FEC of the inter-area 458 P2MP Segmented Service LSP is determined. 460 If the application is Internet Multicast then the unicast routes to 461 multicast sources/RPs SHOULD carry the VRF Route Import Extended 462 Community [BGP-MVPN] where the IP address in the Global Administrator 463 field is set to the IP address of the PE or ASBR advertising the 464 unicast route. The Local Administrator field of this community MUST 465 be set to 0. If it is not desirable to advertise the VRF Route Import 466 Extended Community in unicast routes, then unicast routes to 467 multicast sources/RPs MUST be advertised using the multicast SAFI 468 i.e. SAFI 2 and the VRF Route Import Extended Community MUST be 469 carried in such routes. 471 Further if the application is internet multicast then the BGP unicast 472 routes that advertise the route to the IP address of PEs or ASBRs or 473 ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop Extended 474 Community where the IP address in the Global Administrator field is 475 set to the IP address of the PE or ASBR or ABR advertising the 476 unicast route. The Local Administrator field of this community MUST 477 be set to 0. If it is not desirable to advertise the P2MP Segmented 478 Next-Hop Extended Community in BGP unicast routes, then unicast 479 routes to ABRs, ASBRs or PEs MUST be advertised using the multicast 480 SAFI i.e. SAFI 2 and the Inter-area P2MP Segmented Next-hop Extended 481 Community MUST be carried in such routes. The procedures for handling 482 the next-hop of SAFI 2 routes are the same as those of handling 483 regular Unicast routes and follow [SEAMLESS-MPLS]. 485 In order to determine the upstream node address the egress PE first 486 determines the ingress PE. The egress PE determines the best route to 487 reach S/RP. The ingress PE address is the IP address determined from 488 the Global Administrator field of the VRF Route Import Extended 489 Community, that is present in this route. The egress PE now finds the 490 best unicast route to reach the ingress PE. The upstream node address 491 is the IP address determined from the Global Administrator field of 492 the Inter-area P2MP Segmented Next-Hop Extended Community, that is 493 present in this route. 495 6.2. Originating a Leaf Auto-Discovery Route 497 If the P2MP FEC was derived from a MVPN or VPLS A-D route then the 498 egress PE MUST originate a Leaf auto-discovery (A-D) route if the 499 MVPN or VPLS A-D route carries a P-Tunnel Attribute with the "Leaf 500 Information Required" flag set. 502 If the P2MP FEC was derived from an Internet Multicast S/*, G and the 503 upstream node's address is not the same as the egress PE, then the 504 egress PE MUST originate a Leaf auto-discovery (A-D) route. 506 6.2.1. Leaf A-D Route for MVPN and VPLS 508 If the P2MP FEC was derived from MVPN or VPLS A-D routes then the 509 Route Key field of the Leaf A-D route contains the NLRI of the A-D 510 route from which the P2MP FEC was derived. This follows procedures 511 for constructing Leaf A-D routes described in [BGP-MVPN, VPLS-P2MP]. 513 6.2.2. Leaf A-D Route for Internet Multicast 515 If the application is internet multicast then the MCAST-VPN NLRI of 516 the Leaf A-D route is constructed as follows: 518 The Route Key field of MCAST-VPN NLRI has the following format: 520 +-----------------------------------+ 521 | RD (8 octets) | 522 +-----------------------------------+ 523 | Multicast Source Length (1 octet) | 524 +-----------------------------------+ 525 | Multicast Source (Variable) | 526 +-----------------------------------+ 527 | Multicast Group Length (1 octet) | 528 +-----------------------------------+ 529 | Multicast Group (Variable) | 530 +-----------------------------------+ 531 | Ingress PE's IP address | 532 +-----------------------------------+ 534 RD is set to 0 for (S,G) state and all 1s for (*,G) state, Multicast 535 Source is set to S for (S,G) state or RP for (*,G) state, Multicast 536 Group is set to G, Multicast Source Length and Multicast Group Length 537 is set to either 4 or 16 (depending on whether S/RP and G are IPv4 or 538 IPv6 addresses). 540 The Ingress PE's IP address is determined as described in the section 541 "Determining the Upstream ABR/PE/ASBR". 543 The Originating Router's IP address field of MCAST-VPN NLRI is set to 544 the address of the local PE (PE that originates the route). 546 Thus the entire MCAST-VPN NLRI of the route has the following format: 548 +-----------------------------------+ 549 | RD (8 octets) | 550 +-----------------------------------+ 551 | Multicast Source Length (1 octet) | 552 +-----------------------------------+ 553 | Multicast Source (Variable) | 554 +-----------------------------------+ 555 | Multicast Group Length (1 octet) | 556 +-----------------------------------+ 557 | Multicast Group (Variable) | 558 +-----------------------------------+ 559 | Ingress PE's IP address | 560 +-----------------------------------+ 561 | Originating Router's IP address | 562 +-----------------------------------+ 564 When the PE deletes (S,G)/(*,G) state that was created as a result of 565 receiving PIM or IGMP messages on one of its IP multicast interfaces, 566 if the PE previousely originated a Leaf auto-discovery route for that 567 state, then the PE SHOULD withdraw that route. 569 An Autonomous System with an IPv4 network may provide IP multicast 570 service for customers that use IPv6, and an Autonomous System with an 571 IPv6 network may provide IP multicast service for customers that use 572 IPv4. Therefore the address family of the Ingress PE's IP address and 573 Originating Router's IP address in the Leaf A-D routes used for 574 Internet multicast MUST NOT be inferred from the AFI field of the 575 associated MP_REACH_NLRI/MP_UNREACH_NLRI attribute of these routes. 576 The address family is determined from the length of the address (a 577 length of 4 octets for IPv4 addresses, a length of 16 octets for IPv6 578 addresses). 580 For example if an Autonomous System with an IPv4 network is 581 providing IPv6 multicast service to a customer, the Ingress PE's IP 582 address and Originating Router's IP address in the Leaf A-D routes 583 used for IPv6 Internet multicast will be a four-octet IPv4 address, 584 even though the AFI of those routes will have the value 2. 586 Note that the Ingress PE's IP address and the Originating Router's IP 587 address must be either both IPv4 or both IPv6 addresses, and thus 588 must be of the same length. Since the two variable length fields 589 (Multicast Source and Multicast Group) in the Leaf A-D routes used 590 for Internet multicast have their own length field, from these two 591 length fields, and the Length field of the MCAST-VPN NLRI, one can 592 compute length of the Ingress PE's IP address and the Originating 593 Router's IP address fields. If the computed length of these fields 594 is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered 595 to be "incorrect", and MUST be handled as specified in section 7 of 596 [BGP-MP]. 598 6.2.3. Constructing the Rest of the Leaf A-D Route 600 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 601 be set to the same IP address as the one carried in the Originating 602 Router's IP Address field of the route. 604 When Ingress Replication is used to instantiate the egress area 605 segment then the Leaf A-D route MUST carry a downstream assigned 606 label in the P-Tunnel Attribute where the P-Tunnel type is set to 607 Ingress Replication. A PE MUST assign a distinct MPLS label for each 608 Leaf A-D route originated by the PE. 610 To constrain distribution of this route, the originating PE 611 constructs an IP-based Route Target community by placing the IP 612 address of the upstream node in the Global Administrator field of the 613 community, with the Local Administrator field of this community set 614 to 0. The originating PE then adds this Route Target Extended 615 Community to this Leaf auto-discovery route. The upstream node's 616 address is as determined in section 6.1. 618 The PE then advertises this route to the upstream node. 620 6.3. PIM-SM in ASM mode for Internet Multicast 622 This specification allows two options for supporting Internet 623 Multicast with PIM-SM in ASM mode. The first option does not transit 624 IP multicast shared trees over the MPLS network. The second option 625 does transit shared trees over the MPLS network and relies on shared 626 tree to source tree switchover. 628 6.3.1. Option 1 630 This option does not transit IP multicast shared trees over the MPLS 631 network. Therefore, when an (egress) PE creates (*, G) state (as a 632 result of receiving PIM messages on one of its IP multicast 633 interfaces), the PE does not propagate this state using Leaf A-D 634 routes. 636 6.3.1.1. Originating Source Active auto-discovery routes 638 Whenever as a result of receiving PIM Register or MSDP messages an RP 639 discovers a new multicast source the RP SHOULD originate a BGP Source 640 Active auto-discovery route. Similarly whenever as a result of 641 receiving MSDP messages a PE, that is not configured as a RP, 642 discovers a new multicast source the PE SHOULD originate a BGP Source 643 Active auto-discovery route. The BGP Source Active auto-discovery 644 route carries a single MCAST-VPN NLRI constructed as follows: 646 + The RD in this NLRI is set to 0. 648 + The Multicast Source field MUST be set to S. The Multicast 649 Source Length field is set appropriately to reflect this. 651 + The Multicast Group field MUST be set to G. The Multicast Group 652 Length field is set appropriately to reflect this. 654 To constrain distribution of the Source Active auto-discovery route 655 to the AS of the advertising RP this route SHOULD carry the NO_EXPORT 656 Community ([RFC1997]). 658 Using the normal BGP procedures the Source Active auto-discovery 659 route is propagated to all other PEs within the AS. 661 Whenever the RP discovers that the source is no longer active, the RP 662 MUST withdraw the Source Active auto-discovery route, if such a route 663 was previousely advertised by the RP. 665 6.3.1.2. Receiving BGP Source Active auto-discovery route by PE 667 When as a result of receiving PIM messages on one of its IP multicast 668 interfaces an (egress) PE creates in its Tree Information Base (TIB) 669 a new (*, G) entry with a non-empty outgoing interface list that 670 contains one or more IP multicast interfaces, the PE MUST check if it 671 has any Source Active auto-discovery routes for that G. If there is 672 such a route, S of that route is reachable via an MPLS interface, and 673 the PE does not have (S, G) state in its TIB for (S, G) carried in 674 the route, then the PE originates a Leaf A-D routes carrying that (S, 675 G), as specified in Section "Leaf A-D Route for Internet Multicast". 677 When an (egress) PE receives a new Source Active auto-discovery 678 route, the PE MUST check if its TIB contains an (*, G) entry with the 679 same G as carried in the Source Active auto-discovery route. If such 680 an entry is found, S is reachable via an MPLS interface, and the PE 681 does not have (S, G) state in its TIB for (S, G) carried in the 682 route, then the PE originates a Leaf A-D routes carrying that (S, G), 683 as specified in Section "Leaf A-D Route for Internet Multicast". 685 6.3.1.3. Handling (S, G, RPTbit) state 687 Creation and deletion of (S, G, RPTbit) state on a PE that resulted 688 from receiving PIM messages on one of its IP multicast interfaces 689 does not result in any BGP actions by the PE. 691 6.3.2. Option 2 693 This option does transit IP multicast shared trees over the MPLS 694 network. Therefore, when an (egress) PE creates (*, G) state (as a 695 result of receiving PIM messages on one of its IP multicast 696 interfaces), the PE does propagate this state using Leaf A-D routes. 698 6.3.2.1. Originating Source Active auto-discovery routes 700 Whenever a PE creates an (S, G) state as a result of receiving Leaf 701 A-D routes associated with Internet multicast service, if S is 702 reachable via one of the IP multicast capable interfaces, and the PE 703 determines that G is in the PIM-SM in ASM mode range, the PE MUST 704 originate a BGP Source Active auto-discovery route. The route carries 705 a single MCAST-VPN NLRI constructed as follows: 707 + The RD in this NLRI is set to 0. 709 + The Multicast Source field MUST be set to S. The Multicast 710 Source Length field is set appropriately to reflect this. 712 + The Multicast Group field MUST be set to G. The Multicast Group 713 Length field is set appropriately to reflect this. 715 To constrain distribution of the Source Active auto-discovery route 716 to the AS of the advertising PE this route SHOULD carry the NO_EXPORT 717 Community ([RFC1997]). 719 Using the normal BGP procedures the Source Active auto-discovery 720 route is propagated to all other PEs within the AS. 722 Whenever the PE deletes the (S, G) state that was previously created 723 as a result of receiving a Leaf A-D route for (S, G), the PE that 724 deletes the state MUST also withdraw the Source Active auto-discovery 725 route, if such a route was advertised when the state was created. 727 6.3.2.2. Receiving BGP Source Active auto-discovery route 729 Procedures for receiving BGP Source Active auto-discovery routes are 730 the same as with Option 1. 732 6.3.2.3. Pruning Sources off the Shared Tree 734 If after receiving a new Source Active auto-discovery route for (S,G) 735 a PE determines that (a) it has the (*, G) entry in its TIB, (b) the 736 incoming interface list (iif) for that entry contains one of the IP 737 interfaces, (c) a MPLS LSP is in the outgoing interface list (oif) 738 for that entry, and (d) the PE does not originate a Leaf A-D route 739 for (S,G), then the PE MUST transition the (S,G,rpt) downstream state 740 to the Prune state. [Conceptually the PIM state machine on the PE 741 will act "as if" it had received Prune(S,G,Rpt) from some other PE, 742 without actually having received one.] Depending on the (S,G,rpt) 743 state on the iifs, this may result in the PE using PIM procedures to 744 prune S off the Shared (*,G) tree. 746 Transitioning the state machine to the Prune state SHOULD be done 747 after a delay that is controlled by a timer. The value of the timer 748 MUST be configurable. The purpose of this timer is to ensure that S 749 is not pruned off the shared tree until all PEs have had time to 750 receive the Source Active A-D route for (S,G). 752 The PE MUST keep the (S,G,rpt) downstream state machine in the Prune 753 state for as long as (a) the outgoing interface list (oif) for (*, G) 754 contains a MPLS LSP, and (b) the PE has at least one Source Active 755 auto-discovery route for (S,G), and (c) the PE does not originate the 756 Leaf A-D route for (S,G). Once either of these conditions become no 757 longer valid, the PE MUST transition the (S,G,rpt) downstream state 758 machine to the NoInfo state. 760 Note that except for the scenario described in the first paragraph of 761 this section, in all other scenarios relying solely on PIM procedures 762 on the PE is sufficient to ensure the correct behavior when pruning 763 sources off the shared tree. 765 6.3.2.4. More on handling (S, G, RPTbit) state 767 Creation and deletion of (S, G, RPTbit) state on a PE that resulted 768 from receiving PIM messages on one of its IP multicast interfaces 769 does not result in any BGP actions by the PE. 771 7. Egress ABR Procedures 773 This section describes Egress ABR Procedures for constructing 774 segmented inter-area P2MP LSP. 776 When an egress ABR receives a Leaf auto-discovery route and the Route 777 Target extended community carried by the route contains the IP 778 address of this ABR, then the following procedures will be executed. 780 If the RD of the received A-D route is not set to all 0s or all 1s, 781 then the egress ABR MUST find a S-PMSI or I-PMSI route whose NLRI has 782 the same value as the Route Key field of the received Leaf A-D route. 783 If such a matching route is found then the Leaf A-D route MUST be 784 accepted else it MUST be discarded. If the Leaf A-D route is accepted 785 and if its the first Leaf A-D route update for the Route Key field in 786 the route or the withdrawl of the last Leaf A-D route for the Route 787 Key field then the following procedures will be executed. 789 If the RD of the received A-D route is set to all 0s or all 1s then 790 the received Leaf A-D route is for Internet Multicast. In that case 791 for the following procedure the Route Prefix is set to all fields of 792 the Route Key minus the Ingress PE address. If this is the first Leaf 793 A-D route update for this Route Prefix or the withdrawl of the last 794 Leaf A-D route for the Route Prefix then the following procedures 795 will be executed. 797 While generating a Leaf A-D route update, the egress ABR originates a 798 Leaf A-D route, whose MCAST-VPN NLRI is constructed as follows. 800 The Route Key field of MCAST-VPN NLRI is the same as the Route Key 801 field of MCAST-VPN NLRI of the received Leaf A-D route. The 802 Originating Router's IP address field of MCAST-VPN NLRI is set to the 803 address of the local ABR (the ABR that originates the route). In 805 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 806 be set to the same IP address as the one carried in the Originating 807 Router's IP Address field of the route. 809 To constrain distribution of this route the originating egress ABR 810 constructs an IP-based Route Target community by placing the IP 811 address of the upstream node in the Global Administrator field of the 812 community, with the Local Administrator field of this community set 813 to 0, and sets the Extended Communities attribute of this Leaf auto- 814 discovery route to that community. 816 The upstream node's IP address is the IP address determined from the 817 Global Administrator field of the Inter-area P2MP Segmented Next-hop 818 Extended Community, where this Extended Community is obtained as 819 follows. When the Leaf A-D route is for MVPN or VPLS then this 820 Extended Community is the one included in the I-S/PMSI A-D route that 821 matches the Leaf A-D route. When the Leaf A-D route is for Internet 822 Multicast then this Extended Community is obtained from the best 823 unicast route to the Ingress PE. The Ingress PE address is 824 determined from the received Leaf A-D route. The best unicast route 825 MUST first be determined from multicast SAFI i.e., SAFI 2 routes, if 826 present. 828 The ABR then advertises this Leaf A-D route to the upstream node 829 in the backbone area. 831 Mechanisms specific in RFC4684 for constrained BGP route distribution 832 can be used along with this specification to ensure that only the 833 needed PE/ABR will have to process a said Leaf auto-discovery route. 835 When Ingress Replication is used to instantiate the backbone area 836 segment then the Leaf A-D route originated by the egress ABR MUST 837 carry a downstream assigned label in the P-Tunnel Attribute where the 838 P-Tunnel type is set to Ingress Replication. An ABR MUST assign a 839 distinct MPLS label for each Leaf A-D route originated by the ABR. 841 In order to support Internet Multicast an egress ABR MUST auto- 842 configure an import Route Target with the global administrator field 843 set to the AS of the ABR and the local administrator field set to 0. 845 When the Leaf A-D route is for Internet Multicast and if the 846 following conditions hold true: 848 - Its not the first Leaf A-D route for the Route Prefix, 849 where the Route Prefix is determined as described above 851 - The set of ingress PEs associated with the Route Prefix 852 changes as a result of the new Leaf A-D route. 854 - The ABR determines based on local policy to propagate 855 the Leaf A-D route towards a different ingress PE than 856 the one to which the Leaf A-D route is being currently 857 propagated. 859 Then the egress ABR MUST originate the Leaf A-D route as described in 860 this section. 862 If the received Leaf A-D route is the last Leaf A-D route for the 863 Route Key for MVPN or VPLS or for the Route Prefix, as described 864 above, for Internet Multicast, then the ABR must withdraw the 865 previously advertised Leaf A-D route. 867 7.1. P2MP LSP as the Intra-Area LSP in the Egress Area 869 This section describes procedures for using intra-area P2MP LSPs in 870 the egress area. The procedures that are common to both P2MP RSVP-TE 871 and P2MP LDP are described first, followed by procedures that are 872 specific to the signaling protocol. 874 When P2MP LSPs are used as the intra-area LSPs, note that an existing 875 intra-area P2MP LSP may be used solely for a particular inter-area 876 P2MP service LSP, or for other inter-area P2MP service LSPs as well. 877 The choice between the two options is purely local to the egress ABR. 878 The first option provides one-to-one mapping between inter-area P2MP 879 service LSPs and intra-area P2MP LSPs; the second option provides 880 many-to-one mapping, thus allowing to aggregate forwarding state. 882 7.1.1. RD of the received Leaf-AD route is not zero or all ones 884 When the RD of the received Leaf A-D route is not set to zero or all 885 ones then the ABR MUST re-advertise in the egress area the MVPN/VPLS 886 A-D route, that matches the Leaf A-D route to signal the binding of 887 the intra-area P2MP LSP to the inter-area P2MP service LSP. This must 888 be done ONLY if a) such a binding hasn't already been advertised or 889 b) The binding has changed. The re-advertised route MUST carry the 890 Inter-area P2MP Segmented Next-Hop Extended Community. 892 The PMSI Tunnel attribute of the re-advertised route specifies either 893 an intra-area P2MP RSVP-TE LSP or an intra-area P2MP LDP LSP rooted 894 at the ABR and MUST also carry an upstream assigned MPLS label. The 895 upstream-assigned MPLS label MUST be set to implicit NULL if the 896 mapping between the inter-area P2MP service LSP and the intra-area 897 P2MP LSP is one-to-one. If the mapping is many-to-one the intra-area 898 segment of the inter-area P2MP service LSP (referred to as the 899 "inner" P2MP LSP) is constructed by nesting the inter-area P2MP 900 service LSP in an intra-area P2MP LSP (referred to as the "outer" 901 intra-area P2MP LSP), by using P2MP LSP hierarchy based on upstream- 902 assigned MPLS labels [RFC 5332]. 904 If segments of multiple MVPN or VPLS S-PMSI service LSPs are carried 905 over a given intra-area P2MP LSP, each of these segments MUST carry a 906 distinct upstream-assigned label, even if all these service LSPs are 907 for (C-S/*, C-G/*)s from the same MVPN/VPLS. Therefore, an ABR 908 maintains an LFIB state for each of the (C-S/*, C-G/*)s carried over 909 S-PMSIs traversting this ABR (that applies to both the ingress and 910 the egress ABRs). 912 7.1.2. RD of the received Leaf A-D route is zero or all ones 914 When the RD of the received Leaf A-D route is set to zero or all ones 915 then this is the case of inter-area P2MP service LSP being associated 916 with the Internet multicast service. The procedures for this are 917 described below. 919 7.1.2.1. Internet Multicast and S-PMSI A-D Routes 921 This section applies only if it is desirable to send a particular 922 Internet Multicast flow to only those egress PEs that have receivers 923 in a particular (S, G) or a particular (*, G) multicast flow. 925 The egress ABR MUST originate a S-PMSI A-D route. The PMSI Tunnel 926 attribute of the route MUST contain the identity of the intra-area 927 P2MP LSP and an upstream assigned MPLS label. The RD, Multicast 928 Source Length, Multicast Source, Multicast Group Length (1 octet), 929 and Multicast Group fields of the NLRI of this route are the same as 930 of the Leaf A-D route. The egress ABR MUST advertise this route into 931 the egress area. The Route Target of this route is an AS specific 932 route-target with the AS set to the AS of the advertising ABR while 933 the local administrator field is set to 0. 935 7.1.2.2. Internet Multicast and Wildcard S-PMSI A-D Routes 937 It may be desirable for an ingress PE to aggregate Internet Multicast 938 routes over a single Inter-area P2MP LSP. This can be achieved using 939 wildcard, i.e., (*,*) S-PMSI A-D routes. An ingress PE MAY advertise 940 a wildcard S-PMSI route as described in section "Ingress PE 941 Procedures". If the ingress PE does indeed originate such a route the 942 egress ABR would receive this route from the ingress ABR and MUST re- 943 advertise it with the PMSI Tunnel Attribute containing the identifier 944 of the intra-area P2MP LSP in the egress area and an upstream 945 assigned label assigned to the inter-area wildcard S-PMSI. 947 7.1.3. Internet Multicast and the Expected Upstream Node 949 If the mapping between the inter-area P2MP service LSP for Internet 950 multicast service and the intra-area P2MP LSP is many-to-one then an 951 egress PE must be able to determine whether a given multicast packet 952 for a particular (S, G) is received from the "expected" upstream 953 node. The expected node is the node towards which the Leaf A-D route 954 is sent by the egress PE. Packets received from another upstream 955 node for that (S, G) MUST be dropped. To allow the egress PE to 956 determine the sender upstream node, the intra-area P2MP LSP must be 957 signaled with no PHP, when the mapping between the inter-area P2MP 958 service LSP for Internet multicast service and the intra-area P2MP 959 LSP is many-to-one. 961 Further the egress ABR MUST first push onto the label stack the 962 upstream assigned label advertised in the S-PMSI route, if the label 963 is not an Implicit NULL. 965 7.1.4. P2MP LDP LSP as the Intra-Area P2MP LSP in the Egress Area 967 The procedures above are sufficient if P2MP LDP LSPs are used as the 968 Intra-area P2MP LSP in the Egress area. 970 7.1.5. P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area 972 If P2MP RSVP-TE LSP is used as the the intra-area LSP in the egress 973 area, then the egress ABR can either (a) graft the leaf (whose IP 974 address is specified in the received Leaf auto-discovery route) into 975 an existing P2MP LSP rooted at the egress ABR, and use that LSP for 976 carrying traffic for the inter-area segmented P2MP service LSP, or 977 (b) originate a new P2MP LSP to be used for carrying (S,G). 979 When the RD of the received Leaf A-D route is zero or all ones, then 980 the procedures are as described in section 7.1.2 ("RD of the 981 received Leaf A-D route is zero or all ones"). 983 Note also that the SESSION object that the egress ABR would use for 984 the intra-area P2MP LSP need not encode the P2MP FEC from the 985 received Leaf auto-discovery route. 987 7.2. Ingress Replication in the Egress Area 989 When Ingress Replication is used to instantiate the egress area 990 segment then the Leaf A-D route advertised by the egress PE MUST 991 carry a downstream assigned label in the P-Tunnel Attribute where the 992 P-Tunnel type is set to Ingress Replication. We will call this the 993 egress PE downstream assigned label. 995 The egress ABR MUST forward packets received from the backbone area 996 intra-area segment, for a particular inter-area P2MP LSP, to all the 997 egress PEs from which the egress ABR has imported a Leaf A-D route 998 for the inter-area P2MP LSP. A packet to a particular egress PE is 999 encapsulated, by the egress ABR, using a MPLS label stack the bottom 1000 label of which is the egress PE downstream assigned label. The top 1001 label is the P2P RSVP-TE or the MP2P LDP label to reach the egress 1002 PE. 1004 Note that these procedures ensures that an egress PE always receives 1005 packets only from the expected upstream PE. 1007 8. Ingress ABR Procedures for constructing segmented inter-area P2MP LSP 1009 When an ingress ABR receives a Leaf auto-discovery route and the 1010 Route Target extended community carried by the route contains the IP 1011 address of this ABR, then the following procedures will be executed. 1013 These procedures are the same as in the section "Egress ABR 1014 Procedures" with egress ABR replaced with ingress ABR, backbone area 1015 replaced with ingress area and backbone area segment replaced with 1016 ingress area segment. 1018 In order to support Internet Multicast the ingress ABR MUST auto- 1019 configure an import Route Target with the global administrator field 1020 set to the AS of the ABR and the local administrator field set to 0. 1022 8.1. P2MP LSP as the Intra-Area LSP in the Backbone Area 1024 If the RD of the received Leaf A-D route is not zero, and P2MP LSP is 1025 used as the the intra-area LSP in the backbone area, then the 1026 procedures for binding the backbone area segment of the inter-area 1027 P2MP LSP to the intra-area P2MP LSP in the backbone area, are the 1028 same as in section "Egress ABR Procedures" and sub-section "P2MP LSP 1029 as the Intra-Area LSP in the Egress Area". 1031 When the RD of the received Leaf A-D route is zero, as is the case 1032 where the inter-area service P2MP LSP is associated with the Internet 1033 multicast service, then the procedures are the same as in section 1034 "Egress ABR Procedures", and and sub-section "P2MP LSP as the Intra- 1035 Area LSP in the Egress Area", with egress ABR replaced with the 1036 ingress ABR. It is to be noted that if the backbone area uses 1037 wildcard S-PMSI then the egress area also must use wildcard S-PMSI 1038 for Internet Multicast or the ABRs must merge the wildcard S-PMSI 1039 onto the egress area (S, G) or (*, G) S-PMSI. The procedures for such 1040 merge require IP processing on the ABRs. 1042 8.2. Ingress Replication in the Backbone Area 1044 When Ingress Replication is used to instantiate the backbone area 1045 segment then the Leaf A-D route advertised by the egress ABR MUST 1046 carry a downstream assigned label in the P-Tunnel Attribute where the 1047 P-Tunnel type is set to Ingress Replication. We will call this the 1048 egress ABR downstream assigned label. The egress ABR MUST assign a 1049 distinct MPLS label for each Leaf A-D route originated by the ABR. 1051 The ingress ABR MUST forward packets received from the ingress area 1052 intra-area segment, for a particular inter-area P2MP LSP, to all the 1053 egress ABRs from which the ingress ABR has imported a Leaf A-D route 1054 for the inter-area P2MP LSP. A packet to a particular egress ABR is 1055 encapsulated, by the inress ABR, using a MPLS label stack the bottom 1056 label of which is the egress ABR downstream assigned label. The top 1057 label is the P2P RSVP-TE or the MP2P LDP label to reach the egress 1058 ABR. 1060 9. Ingress PE/ASBR Procedures 1062 This section describes Ingress PE/ASBR procedures for constructing 1063 segmented inter-area P2MP LSP. 1065 When an ingress PE/ASBR receives a Leaf auto-discovery route and the 1066 Route Target extended community carried by the route contains the IP 1067 address of this PE/ASBR, then the following procedures will be 1068 executed. 1070 If the RD of the received A-D route is not set to all 0s or all 1s, 1071 then the egress ABR MUST find a S-PMSI or I-PMSI route whose NLRI has 1072 the same value as the Route Key field of the received Leaf A-D route. 1073 If such a matching route is found then the Leaf A-D route MUST be 1074 accepted else it MUST be discarded. If the Leaf A-D route is accepted 1075 then it MUST be processed as per MVPN or VPLS procedures. 1077 If the RD of the received A-D route is set to all 0s or all 1s then 1078 the received Leaf A-D route is for Internet Multicast. In that case 1079 for the following procedure the Route Prefix is set to all fields of 1080 the Route Key minus the Ingress PE address. If this is the first Leaf 1081 A-D route update for this Route Prefix or the withdrawl of the last 1082 Leaf A-D route for the Route Prefix then the following procedures 1083 will be executed. The information carried in the MCAST-VPN NLRI of 1084 the route MUST be decoded. The PIM implementation should set its 1085 upstream (S/RP,G) state machine in Joined state for the (S/RP, G) 1086 received via a Leaf auto-discovery route update. Likewise, the PIM 1087 implementation should set its upstream (S/RP, G) state machine in 1088 Pruned state for the (S/RP, G) received via a Leaf auto-discovery 1089 route withdrawl. 1091 9.1. P2MP LSP as the intra-area LSP in the ingress area 1093 If the RD of the received Leaf A-D route is not zero, and P2MP LSP is 1094 used as the the intra-area LSP in the ingress area, then the 1095 procedures for binding the ingress area segment of the inter-area 1096 P2MP LSP to the intra-area P2MP LSP in the ingress area, are the same 1097 as in section "Egress ABR Procedures" and sub-section "P2MP LSP as 1098 the Intra-Area LSP in the Egress Area". 1100 When the RD of the received Leaf A-D route is zero, as is the case 1101 where the inter-area service P2MP LSP is associated with the Internet 1102 multicast service, then the ingress PE may originate a S-PMSI route 1103 with the RD, multicast source, multicast group fields being the same 1104 as those in the received Leaf A-D route. 1106 Further an ingress PE may originate a wildcard S-PMSI route as per 1107 the procedures in [MVPN-WILDCARD-SPMSI] with the RD set to 0. This 1108 route may be originated by the ingress PE based on configuration or 1109 based on the import of a Leaf A-D route with RD set to 0. If an 1110 ingress PE originates such a route, then the ingress PE may decide 1111 not to originate (S, G) or (*, G) S-PMSI routes. 1113 It is to be noted that if ingress area uses wildcard S-PMSI then the 1114 backbone area also must use wildcard S-PMSI for Internet Multicast or 1115 the ABRs must merge the wildcard S-PMSI onto the backbone area (S, G) 1116 or (*, G) S-PMSI. The procedures for such merge require IP processing 1117 on the ABRs. 1119 9.2. Ingress Replication in the Ingress Area 1121 When Ingress Replication is used to instantiate the ingress area 1122 segment then the Leaf A-D route advertised by the ingress ABR MUST 1123 carry a downstream assigned label in the P-Tunnel Attribute where the 1124 P-Tunnel type is set to Ingress Replication. We will call this the 1125 ingress ABR downstream assigned label. The ingress ABR MUST assign a 1126 distinct MPLS label for each Leaf A-D route originated by the ABR. 1128 The ingress PE/ASBR MUST forward packets received from the CE, for a 1129 particular inter-area P2MP LSP, to all the ingress ABRs from which 1130 the ingress PE/ASBR has imported a Leaf A-D route for the inter-area 1131 P2MP LSP. A packet to a particular ingress ABR is encapsulated, by 1132 the inress PE/ASBR, using a MPLS label stack the bottom label of 1133 which is the ingress ABR downstream assigned label. The top label is 1134 the P2P RSVP-TE or the MP2P LDP label to reach the ingress ABR. 1136 10. Common Tunnel Type in the Ingress and Egress Areas 1138 For a given inter-area service P2MP LSP, the PE/ASBR that is the root 1139 of that LSP controls the tunnel type of the intra-area P-tunnel that 1140 carries the ingress area segment of that LSP. However, the tunnel 1141 type of the intra-area P-tunnel that carries the backbone area 1142 segment of that LSP may be different from the tunnel type of the 1143 intra-area P-tunnels that carry the ingress area segment and the 1144 egress area segment of that LSP. In that situation if for a given 1145 inter-area P2MP LSP it is desirable/necessary to use the same tunnel 1146 type for the intra-area P-tunnels that carry the ingress area segment 1147 and the egress area segment of that LSP, then the following 1148 procedures on the ingress ABR and egress ABR provide this 1149 functionality. 1151 When an ingress ABR re-advertises into the backbone area a BGP MVPN 1152 I-PMSI, or S-PMSI A-D route, or VPLS A-D route, the ingress ABR 1153 places the PMSI Tunnel attribute of this route into the ATTR_SET BGP 1154 Attribute [L3VPN-IBGP], adds this attribute to the re-advertised 1155 route, and then replaces the original PMSI Tunnel attribute with a 1156 new one (note, that the Tunnel type of the new attribute may be 1157 different from the Tunnel type of the original attribute). 1159 When an egress ABR re-advertises into the egress area a BGP MVPN I- 1160 PMSI or S-PMSI A-D route, or VPLS A-D route, if the route carries the 1161 ATTR_SET BGP attribute [L3VPN-IBGP], then the ABR sets the Tunnel 1162 type of the PMSI Tunnel attribute in the re-advertised route to the 1163 Tunnel type of the PMSI Tunnel attribute carried in the ATTR_SET BGP 1164 attribute, and removes the ATTR_SET from the route. 1166 11. Placement of Ingress and Egress PEs 1168 As described in earlier sections, procedures in this document allow 1169 the placement of ingress and egress PEs in the backbone area. They 1170 also allow the placement of egress PEs in the ingress area or the 1171 placement of ingress PEs in the egress area. 1173 For instance ABRs in the backbone area may act as ingress and egress 1174 PEs for Internet Multicast, as per the ingress and egress PE 1175 definition in this document. This may be the case if the service is 1176 Internet Multicast and relies on Internet Multicast in the ingress 1177 and egress areas and its desirable to carry Internet Multicast over 1178 MPLS in the backbone area. This may also be the case if the service 1179 is Multicast VPN and the P-tunnel technology in the ingress and 1180 egress areas uses PIM based IP/GRE P-tunnels. As far as the ABRs are 1181 concerned PIM signaling for such P-Tunnels is handled as per the 1182 ingress/egress PE Internet Multicast procedures in this document. To 1183 facilitate this the ABRs may advertise their loopback addresses in 1184 BGP using multicast-SAFI i.e., SAFI 2, if non-congruence between 1185 unicast and multicast is desired. 1187 12. Data Plane 1189 This section describes the data plane procedures on the ABRs, ingress 1190 PEs, egress PEs and transit routers. 1192 12.1. Data Plane Procedures on an ABR 1194 When procedures in this document are followed to signal inter-area 1195 P2MP Segmented LSPs then ABRs are required to perform only MPLS 1196 switching. When an ABR receives a MPLS packet from an "incoming" 1197 intra-area segment of the inter-area P2MP Segmented LSP, it forwards 1198 the packet, based on MPLS switching, onto another "outgoing" intra- 1199 area segment of the inter-area P2MP Segmented LSP. 1201 If the outgoing intra-area segment is instantiated using a P2MP LSP, 1202 and if there is a one-to-one mapping between the outgoing intra-area 1203 segment and the P2MP LSP, then the ABR MUST pop the incoming 1204 segment's label stack and push the label stack of the outgoing P2MP 1205 LSP. If there is a many-to-one mapping between outgoing intra-area 1206 segments and the P2MP LSP then the ABR MUST pop the incoming 1207 segment's label stack and first push the upstream assigned label 1208 corresponding to the outgoing intra-area segment, if such a label has 1209 been assigned, and then push the label stack of the outgoing P2MP 1210 LSP. 1212 If the outgoing intra-area segment is instantiated using ingress 1213 replication then the ABR must pop the incoming segment's label stack 1214 and replicate the packet once to each leaf ABR or PE of the outgoing 1215 intra-area segment. The label stack of the packet sent to each such 1216 leaf MUST first include a downstream assigned label assigned by the 1217 leaf to the segment, followed by the label stack of the P2P or MP2P 1218 LSP to the leaf. 1220 12.2. Data Plane Procedures on an Egress PE 1222 An egress PE must first identify the inter-area P2MP segmented LSP 1223 based on the incoming label stack. After this identification the 1224 egress PE must forward the packet using the application that is bound 1225 to the inter-area P2MP segmented LSP. 1227 Note that the application specific forwarding for MVPN service may 1228 require the egress PE to determine whether the packets were received 1229 from the expected sender PE. When the application is MVPN then the 1230 FEC of an inter-area P2MP Segmented LSP is at the granularity of the 1231 sender PE. Note that MVPN intra-AS I-PMSI A-D routes and S-PMSI A-D 1232 routes both carry the Originating Router IP Address. Thus an egress 1233 PE could associate the data arriving on P-tunnels advertised by these 1234 routes with the Originating Router IP Address carried by these routes 1235 which is the same as the ingress PE. Since a unique label stack is 1236 associated with each such FEC, the egress PE can determine the sender 1237 PE from the label stack. 1239 Likewise for VPLS service for the purposes of MAC learning the egress 1240 PE must be able to determine the "VE-ID" from which the packets have 1241 been received. The FEC of the VPLS A-D routes carries the VE-ID. Thus 1242 an egress PE could associate the data arriving on P-tunnels 1243 advertised by these routes with the VE-ID carried by these routes. 1244 Since a unique label stack is associated with each such FEC, the 1245 egress PE can perform MAC learning for packets received from a given 1246 VE-ID. 1248 When the application is Internet Multicast it is sufficient for the 1249 label stack to include identification of the sender upstream node. 1250 When P2MP LSPs are used this requires that PHP MUST be turned off. 1251 When Ingress Replication is used the egress PE knows the incoming 1252 downstream assigned label to which it has bound a particlar (S/*, G) 1253 and must accept packets with only that label for that (S/*. G). 1255 12.3. Data Plane Procedures on an Ingress PE 1257 The Ingress PE must perform application specific forwarding 1258 procedures to identify the outgoing inta-area segment of an incoming 1259 packet. 1261 If the outgoing intra-area segment is instantiated using a P2MP LSP, 1262 and if there is a one-to-one mapping between the outgoing intra-area 1263 segment and the P2MP LSP, then the ingress PE MUST encapsulate the 1264 packet in the label stack of the outgoing P2MP LSP. If there is a 1265 many-to-one mapping between outgoing intra-area segments and the P2MP 1266 LSP then the PE MUST first push the upstream assigned label 1267 corresponding to the outgoing intra-area segment, if such a label has 1268 been assigned, 1269 and then push the label stack of the outgoing P2MP LSP. 1271 If the outgoing intra-area segment is instantiated using ingress 1272 replication then the PE must replicate the packet once to each leaf 1273 ABR or PE of the outgoing intra-area segment. The label stack of the 1274 packet sent to each such leaf MUST first include a downstream 1275 assigned label assigned by the leaf to the segment, followed by the 1276 label stack of the P2P or MP2P LSP to the leaf. 1278 12.4. Data Plane Procedures on Transit Routers 1280 When procedures in this document are followed to signal inter-area 1281 P2MP Segmented LSPs then tansit routers in each area perform only 1282 MPLS switching. 1284 13. Support for Inter-Area Transport LSPs 1286 This section describes OPTIONAL procedures that allow to aggregate 1287 multiple (inter-area) P2MP service LSPs into a single inter-area P2MP 1288 transport LSPs, and then apply the segmentation procedures, as 1289 specified in this document, to these inter-area P2MP transport LSPs 1290 (rather than applying these procedures directly to the inter-area 1291 P2MP service LSPs). 1293 13.1. Transport Tunnel Tunnel Type 1295 For the PMSI Tunnel Attribute we define a new Tunnel type, called 1296 "Transport Tunnel", whose Tunnel Identifier is a tuple . This Tunnel type is assigned a value of 8. 1298 The Source PE Address is the address of the PE that originates the 1299 (service) A-D route that carries this attribute, and the Local Number 1300 is a number that is unique to the Source PE. The length of the Local 1301 Number part is the same as the length of the Source PE Address. Thus 1302 if the Source PE Address is an IPv4 address, then the Local Number 1303 part is 4 octets, and if the Source PE Address is an IPv6 address, 1304 then the Local Number part is 16 octets. 1306 13.2. Discovering Leaves of the Inter-Area P2MP Service LSP 1308 When aggregating multiple P2MP LSPs using P2MP LSP hierarchy, 1309 determining the leaf nodes of the LSPs being aggregated is essential 1310 for being able to tradeoff the overhead due to the P2MP LSPs vs 1311 suboptimal use of bandwidth due to the partial congruency of the LSPs 1312 being aggregated. 1314 Therefore, if a PE that is a root of a given service P2MP LSP wants 1315 to aggregate this LSP with other (service) p2mp LSPs rooted at the 1316 same PE into an inter-area P2MP transport LSP, the PE should first 1317 determine all the leaf nodes of that service LSP, as well as those of 1318 the other service LSPs being aggregated). 1320 To accomplish this the PE sets the PMSI Tunnel attribute of the 1321 service A-D route associated with that LSP as follows. The Tunnel 1322 Type is set to "No tunnel information present", Leaf Information 1323 Required flag is set to 1, the route MUST NOT carry the P2MP 1324 Segmented Next-Hop extended community. In contrast to the procedures 1325 for the MVPN and VPLS A-D routes described so far, the Route 1326 Reflectors that participate in the distribution of this route need 1327 not be ABRs 1329 13.3. Discovering the P2MP FEC of the Inter-Area P2MP Transport LSP 1331 Once the root PE determines all the leaves of a given P2MP service 1332 LSP, the PE (using some local to the PE criteria) selects a 1333 particular inter-area transport P2MP LSP to be used for carrying the 1334 (inter-area) service P2MP LSP. 1336 Once the PE selects the transport P2MP LSP, the PE (re)originates the 1337 service A-D route. The PMSI Tunnel attribute of this route now 1338 carries the Transport Tunnel ID of the selected transport tunnel, 1339 with the Tunnel Type set to "Transport Tunnel". Just as described 1340 earlier, this service A-D route MUST NOT carry the P2MP Segmented 1341 Next-Hop extended community. Just as described earlier, the Route 1342 Reflectors that participate in the distribution of this route need 1343 not be ABRs. 1345 13.4. Egress PE Procedures for Inter-Area P2MP Transport LSP 1347 When an egress PE receives and accepts an MVPN or VPLS service A-D 1348 route, if the Leaf Information Required flag in the PMSI Tunnel 1349 attribute of the received A-D route is set to 1, and the route does 1350 not carry the P2MP Segmented Next-Hop extended community, then the 1351 egress PE following the "regular" MVPN or VPLS procedures, as 1352 specified in [MVPN-BGP] and [VPLS-P2MP], associated with the received 1353 A-D route originates a Leaf A-D route. 1355 In addition, if the Tunnel Type in the PMSI Tunnel attribute of the 1356 received service A-D route is set to "Transport Tunnel", the egress 1357 PE originates yet another Leaf A-D route. 1359 The format of the Route Key field of MCAST-VPN NLRI of this 1360 additional Leaf A-D route is the same as defined in Section "Leaf A-D 1361 Route for Internet Multicast". The Route Key field of MCAST-VPN NLRI 1362 of this route is constructed as follows: 1364 RD (8 octets) - set to 0 1366 Multicast Source Length, Multicast Source - constructed from 1367 the Source PE address part of the Tunnel Identifier carried 1368 in the received S-PMSI A-D route. 1370 Multicast Group Length, Multicast Group - constructed from 1371 Local Number part of the Tunnel Identifier carried in the 1372 received S-PMSI A-D route. 1374 Ingress PE IP Address is constructed from the Source PE 1375 address part of the Tunnel Identifier carried in the 1376 received S-PMSI A-D route. 1378 The egress PE, when determining the upstream ABR, follows the 1379 procedures specified in Section 6.1 for Internet Multicast. 1381 From that point on we follow the procedures used for the Leaf A-D 1382 routes for Internet multicast, as outlined below. 1384 13.5. Egress ABR, Ingress ABR, Ingress PE procedures for Inter-Area 1385 Transport LSP 1387 When an egress ABR receives the Leaf A-D route, the egress ABR will 1388 advertise into the egress area an S-PMSI A-D route whose NLRI is the 1389 same as the received Leaf A-D route, minus the Ingress PE IP address. 1390 The PMSI Tunnel attribute of this route contains the identity of a 1391 particular intra-area P2MP LSP and an upstream-assigned MPLS label. 1392 The egress PE(s) will import this route. 1394 The egress ABR will also propagate, with appropriate modifications, 1395 the received Leaf A-D route into the backbone area. 1397 Likewise, an ingress ABR will advertise into the backbone area an S- 1398 PMSI A-D route whose NLRI is the same as the received Leaf A-D route, 1399 minus the Ingress PE IP address. The egress ABR(s) will import this 1400 route. 1402 The ingress ABR will also propagate, with appropriate modifications, 1403 the received Leaf A-D route into the ingress area. 1405 Finally the ingress PE will advertise into the ingress area an S-PMSI 1406 A-D route whose NLRI is the same as the received Leaf A-D route, 1407 minus the Ingress PE IP address. The ingress ABR(s) and other PE(s) 1408 in the ingress area, if any, will import this route. The ingress PE 1409 will use the (intra-area) P2MP LSP advertised in this route for 1410 carrying traffic associated with the original service A-D route 1411 advertised by the PE. 1413 . 1414 . 1416 13.6. Discussion 1418 Use of inter-area transport P2MP LSPs, as described in this section, 1419 creates a level of indirection between (inter-area) P2MP service 1420 LSPs, and intra-area transport LSPs that carry the service LSPs. 1421 Rather than segmenting (inter-area) service P2MP LSPs, and then 1422 aggregating (intra-area) segments of these service LSPs into intra- 1423 area transport LSPs, this approach first aggregates multiple (inter- 1424 area) service P2MP LSPs into a single inter-area transport P2MP LSP, 1425 then segments such inter-area transport P2MP LSPs, and then 1426 aggregates (intra-area) segments of these inter-area transport LSPs 1427 into intra-area transport LSPs. 1429 On one hand this approach could result in reducing the state (and the 1430 overhead associated with maintaining the state) on ABRs. This is 1431 because instead of requiring ABRs to maintain state for individual 1432 P2MP service LSPs, ABRs would need to maintain state only for the 1433 inter-area P2MP transport LSPs. Note however, that this reduction is 1434 possible only if a single inter-area P2MP transport LSP aggregates 1435 more than one (inter-area) service LSP. In the absence of such 1436 aggregation, use of inter-area transport LSPs provides no benefits, 1437 yet results in extra overhead. And while such aggregation does allow 1438 to reduce state on ABRs, it comes at a price, as described below. 1440 As we mentioned before, aggregating multiple P2MP service LSPs into a 1441 single inter-area P2MP transport LSP requires the PE rooted at these 1442 LSPs to determine all the leaf nodes of the service LSPs to be 1443 aggregated. This means that the root PE has to track all the leaf PEs 1444 of these LSPs. In contrast, when one applies segmentation procedures 1445 directly to the P2MP service LSPs, the root PE has to track only the 1446 leaf PEs in its own IGP area, plus the ingress ABR(s). Likewise, an 1447 ingress ABR has to track only the egress ABRs. Finally, an egress ABR 1448 has to track only the leaf PEs in its own area. Therefore, while the 1449 total overhead of leaf tracking due to the P2MP service LSPs is about 1450 the same in both approaches, the distribution of this overhead is 1451 different. Specifically, when one uses inter-area P2MP transport 1452 LSPs, this overhead is concentrated on the ingress PE. When one 1453 applies segmentation procedures directly to the P2MP service LSPs, 1454 this overhead is distributed among ingress PE and ABRs. 1456 Moreover, when one uses inter-area P2MP transport LSPs, ABRs have to 1457 bear the overhead of leaf tracking for inter-area P2MP transport 1458 LSPs. In contrast, when one applies segmentation procedures directly 1459 to the P2MP service LSPs, there is no such overhead (as there are no 1460 inter-area P2MP transport LSPs). 1462 Use of inter-area P2MP transport LSPs may also result in more 1463 bandwidth inefficiency, as compared to applying segmentation 1464 procedures directly to the P2MP service LSPs. This is because with 1465 inter-area P2MP transport LSPs the ABRs aggregate segments of inter- 1466 area P2MP transport LSPs, rather than segments of (inter-area) P2MP 1467 service LSPs. To illustrate this consider the following example. 1469 Assume PE1 in Area 1 is an ingress PE, with two multicast streams, 1470 (C-S1, C-G1) and (C-S2, C-G2), originated by an MVPN site connected 1471 to PE1. Assume that PE2 in Area 2 has an MVPN site with receivers 1472 for (C-S1, C-G1), PE3 and PE4 in Area 3 have an MVPN site with 1473 receivers both for (C-S1, C-G1) and for (C-S2, C-G2). Finally, assume 1474 that PE5 in Area 4 has an MVPN site with receivers for (C-S2, C-G2). 1476 When segmentation applies directly to the P2MP service LSPs then Area 1477 2 would have just one intra-area transport LSP which would carry the 1478 egress area segment of the P2MP service LSP for (C-S1, C-G1); Area 3 1479 would have just one intra-area transport LSP which would carry the 1480 egress area segments of both the P2MP service LSP for (C-S1, C-G1) 1481 and the P2MP service LSP for (C-S2, C-G2); Area 4 would have just one 1482 intra-area transport LSP which would carry the egress area segment of 1483 the P2MP service LSP for (C-S2, C-G2). Note that there is no 1484 bandwidth inefficiency in this case at all. 1486 When using inter-area P2MP transport LSPs, to achieve the same state 1487 overhead on the routers within each of the egress areas (except for 1488 egress ABRs), PE1 would need to aggregate the P2MP service LSP for 1489 (C-S1, C-G1) and the P2MP service LSP for (C-S2, C-G2) into the same 1490 inter-area P2MP transport LSP. While such aggregation would reduce 1491 state on ABRs, it would also result in bandwidth inefficiency, as (C- 1492 S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but also 1493 to PE5, which has no receivers for this stream. Likewise, (C-S2, C- 1494 G2) will be delivered not just to PE3, PE4, and PE5, but also to PE2, 1495 which has no receivers for this stream. 1497 14. IANA Considerations 1499 This document defines a new BGP Extended Community called "Inter-area 1500 P2MP Segmented Next-Hop". This community is IP Address Specific, of 1501 an extended type, and is transitive. A codepoint for this community 1502 should be assigned both from the IPv4 Address Specific Extended 1503 Community registry, and from the IPv6 Address Specific Extended 1504 Community registry. The same code point should be assigned from both 1505 registries. 1507 This document also assigns a new Tunnel Type in the PMSI Tunnel 1508 Attribute, called the "Transport Tunnel". This Tunnel Type is 1509 assigned a value of 8. 1511 15. Security Considerations 1513 These will be spelled out in a future revision. 1515 16. Acknowledgements 1517 We would like to thank Eric Rosen for his comments. 1519 17. References 1521 17.1. Normative References 1523 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332 1525 [RFC2119] "Key words for use in RFCs to Indicate Requirement 1526 Levels.", Bradner, March 1997 1528 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 1529 VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, draft-ietf- 1530 l3vpn-2547bis-mcast-bgp 1532 [[VPLS-P2MP] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang, 1533 draft-ietf-l2vpn-vpls-mcast 1535 [L3VPN-IBGP] "Internal BGP as PE-CE protocol", Pedro Marques, et al., 1536 draft-ietf-l3vpn-ibgp, work in progress 1538 17.2. Informative References 1540 [SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al., 1541 draft-leymann-mpls-seamless-mpls 1543 18. Author's Address 1545 Yakov Rekhter 1546 Juniper Networks 1547 1194 North Mathilda Ave. 1548 Sunnyvale, CA 94089 1549 Email: yakov@juniper.net 1551 Rahul Aggarwal 1552 Juniper Networks 1553 1194 North Mathilda Ave. 1554 Sunnyvale, CA 94089 1555 Phone: +1-408-936-2720 1556 Email: rahul@juniper.net 1558 Thomas Morin 1559 France Telecom R & D 1560 2, avenue Pierre-Marzin 1561 22307 Lannion Cedex 1562 France 1563 Email: thomas.morin@orange-ftgroup.com 1565 Irene Grosclaude 1566 France Telecom R & D 1567 2, avenue Pierre-Marzin 1568 22307 Lannion Cedex 1569 France 1570 Email: irene.grosclaude@orange-ftgroup.com 1572 Nicolai Leymann 1573 Deutsche Telekom AG 1574 Winterfeldtstrasse 21 1575 Berlin 10781 1576 DE 1577 Email: n.leymann@telekom.de 1579 Samir Saad 1580 AT&T 1581 Email: ss2539@att.com