idnits 2.17.1 draft-ietf-mpls-seamless-mcast-04.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 15 instances of too long lines in the document, the longest one being 13 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 475 has weird spacing: '...MUST be adver...' == Line 487 has weird spacing: '...MUST be adver...' == Line 608 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- 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 523, but not defined == Missing Reference: 'VPLS-P2MP' is mentioned on line 1402, but not defined == Missing Reference: 'RFC5331' is mentioned on line 213, but not defined == Missing Reference: 'RFC4360' is mentioned on line 245, but not defined == Missing Reference: 'BGP-VPLS' is mentioned on line 345, but not defined == Missing Reference: 'VPLS-AD' is mentioned on line 345, but not defined == Missing Reference: 'RFC1997' is mentioned on line 750, but not defined == Missing Reference: 'RFC 5332' is mentioned on line 943, but not defined == Unused Reference: 'RFC5332' is defined on line 1574, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 15 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: November 2012 5 R. Aggarwal 7 T. Morin 8 France Telecom 10 I. Grosclaude 11 France Telecom 13 N. Leymann 14 Deutsche Telekom AG 16 S. Saad 17 AT&T 19 May 30 2012 21 Inter-Area P2MP Segmented LSPs 23 draft-ietf-mpls-seamless-mcast-04.txt 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that other 32 groups may also distribute working documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Copyright and License Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Abstract 74 This document describes procedures for building inter-area point-to- 75 multipoint (P2MP) segmented service LSPs by partitioning such LSPs 76 into intra-area segments and using BGP as the inter-area routing and 77 label distribution protocol. Within each IGP area the intra-area 78 segments are either carried over intra-area P2MP LSPs, using P2MP LSP 79 hierarchy, or instantiated using ingress replication. The intra-area 80 P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress 81 replication is used within an IGP area, then MP2P LDP LSPs or P2P 82 RSVP-TE LSPs may be used in the IGP area. The applications/services 83 that use such inter-area service LSPs may be BGP MVPN, VPLS multicast 84 or IP multicast over MPLS. 86 Table of Contents 88 1 Specification of requirements ......................... 4 89 2 Introduction .......................................... 4 90 3 General Assumptions and Terminology ................... 5 91 4 Inter-area P2MP Segmented Next-Hop Extended Community . 6 92 5 Discovering the P2MP FEC of the Inter-Area P2MP Service LSP 7 93 5.1 BGP MVPN .............................................. 7 94 5.2 BGP VPLS or LDP VPLS with BGP auto-discovery .......... 8 95 5.3 IP Multicast over MPLS ................................ 10 96 6 Egress PE Procedures .................................. 10 97 6.1 Determining the Upstream ABR/PE/ASBR .................. 11 98 6.2 Originating a Leaf Auto-Discovery Route ............... 12 99 6.2.1 Leaf Auto-Discovery Route for MVPN and VPLS ........... 12 100 6.2.2 Leaf Auto-Discovery Route for Global Table Multicast .. 12 101 6.2.3 Constructing the Rest of the Leaf Auto-Discovery Route ....14 102 6.3 PIM-SM in ASM mode for Global Table Multicast ......... 15 103 6.3.1 Option 1 .............................................. 15 104 6.3.1.1 Originating Source Active auto-discovery routes ....... 15 105 6.3.1.2 Receiving BGP Source Active auto-discovery route by PE ....16 106 6.3.1.3 Handling (S, G, RPTbit) state ......................... 16 107 6.3.2 Option 2 .............................................. 17 108 6.3.2.1 Originating Source Active auto-discovery routes ....... 17 109 6.3.2.2 Receiving BGP Source Active auto-discovery route ...... 17 110 6.3.2.3 Pruning Sources off the Shared Tree ................... 18 111 6.3.2.4 More on handling (S, G, RPTbit) state ................. 18 112 7 Egress ABR Procedures ................................. 19 113 7.1 P2MP LSP as the Intra-Area LSP in the Egress Area ..... 21 114 7.1.1 RD of the received Leaf auto-discovery route is not all 0s or all 1s 21 115 7.1.2 RD of the received Leaf auto-discovery route is all 0s or all 1s 22 116 7.1.2.1 Global Table Multicast and S-PMSI Auto-Discovery Routes ...22 117 7.1.2.2 Global Table Multicast and Wildcard S-PMSI Auto-Discovery Routes 22 118 7.1.3 Global Table Multicast and the Expected Upstream Node . 23 119 7.1.4 P2MP LDP LSP as the Intra-Area P2MP LSP in the Egress Area 23 120 7.1.5 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area 23 121 7.2 Ingress Replication in the Egress Area ................ 24 122 8 Ingress ABR Procedures for constructing segmented inter-area P2MP LSP 24 123 8.1 P2MP LSP as the Intra-Area LSP in the Backbone Area ... 24 124 8.2 Ingress Replication in the Backbone Area .............. 25 125 9 Ingress PE/ASBR Procedures ............................ 25 126 9.1 P2MP LSP as the intra-area LSP in the ingress area .... 26 127 9.2 Ingress Replication in the Ingress Area ............... 27 128 10 Common Tunnel Type in the Ingress and Egress Areas .... 27 129 11 Placement of Ingress and Egress PEs ................... 28 130 12 Data Plane ............................................ 28 131 12.1 Data Plane Procedures on an ABR ....................... 28 132 12.2 Data Plane Procedures on an Egress PE ................. 29 133 12.3 Data Plane Procedures on an Ingress PE ................ 30 134 12.4 Data Plane Procedures on Transit Routers .............. 30 135 13 Support for Inter-Area Transport LSPs ................. 30 136 13.1 Transport Tunnel Tunnel Type .......................... 31 137 13.2 Discovering Leaves of the Inter-Area P2MP Service LSP . 31 138 13.3 Discovering the P2MP FEC of the Inter-Area P2MP Transport LSP 31 139 13.4 Egress PE Procedures for Inter-Area P2MP Transport LSP ....32 140 13.5 Egress ABR, Ingress ABR, Ingress PE procedures for Inter-Area 33 141 13.6 Discussion ............................................ 33 142 14 IANA Considerations ................................... 35 143 15 Security Considerations ............................... 35 144 16 Acknowledgements ...................................... 36 145 17 References ............................................ 36 146 17.1 Normative References .................................. 36 147 17.2 Informative References ................................ 36 148 18 Author's Address ...................................... 37 150 1. Specification of requirements 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 2. Introduction 158 This document describes procedures for building inter-area point-to- 159 multipoint (P2MP) segmented service LSPs by partitioning such LSPs 160 into intra-area segments and using BGP as the inter-area routing and 161 label distribution protocol. Within each IGP area the intra-area 162 segments are either carried over intra-area P2MP LSPs, potentially 163 using P2MP LSP hierarchy, or instantiated using ingress replication. 164 The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP 165 mLDP. If ingress replication is used in an IGP area then MP2P LDP or 166 P2P RSVP-TE LSPs may be used within the IGP area. The 167 applications/services that use such inter-area service LSPs may be 168 BGP MVPN, VPLS multicast or IP multicast over MPLS. 170 The primary use case of such segmented P2MP service LSPs is when the 171 PEs are in different areas but in the same AS and thousands or more 172 of PEs require P2MP connectivity. For instance this may be the case 173 when MPLS is pushed further to the metro edge and the metros are in 174 different IGP areas. This may also be the case when a Service 175 Provider's network comprises multiple IGP areas in a single 176 Autonomous System, with a large number of PEs. Seamless MPLS is the 177 industry term to address this case [SEAMLESS-MPLS]. Thus one of the 178 applicabilities of this document is that it describes the multicast 179 procedures for seamless MPLS. 181 It is to be noted that [BGP-MVPN], [VPLS-P2MP] already specify 182 procedures for building segmented inter-AS P2MP service LSPs. This 183 document complements those procedures, as it extends the segmented 184 P2MP LSP model such that it is applicable to inter-area P2MP service 185 LSPs as well. Infact an inter-AS deployment could use inter-AS 186 segmented P2MP LSPs as specified in [BGP-MVPN, VPLS-P2MP] where each 187 intra-AS segment is constructed using inter-area segmented P2MP LSPs 188 as specified in this document. 190 3. General Assumptions and Terminology 192 This document assumes BGP is used as an inter-area routing and label 193 distribution protocol for the unicast IPv4 /32 or IPv6 /128 routes 194 for the PEs. This document also assumes ABRs act as Route Reflectors 195 (RR) for these routes. 197 When supporting segmentation of the inter-area P2MP MVPN service 198 LSPs, instead of assuming that BGP is used as an inter-area routing 199 and label distribution protocol for unicast IPv4 /32 or IPv6 /128 200 routes, it is sufficient to assume that BGP is used as an inter-area 201 routing protocol for unicast IPv4 /32 or IPv6 /128 routes used for 202 multicast forwarding (SAFI = 2). 204 Within an AS a P2MP service LSP is partitioned into 3 segments: 205 ingress area segment, backbone area segment, and egress area segment. 206 Within each area a segment is carried over an intra-area P2MP LSP or 207 instantiated using ingress replication. 209 When intra-area P2MP LSPs are used to instantiate the intra-area 210 segments there could be either 1:1 or n:1 mapping between intra-area 211 segments of the inter-area P2MP service LSP and a given intra-area 212 P2MP LSP. The latter is realized using P2MP LSP hierarchy with 213 upstream-assigned labels [RFC5331]. For simplicity we assume that 214 P2MP LSP hierarchy is used even with 1:1 mapping, in which case the 215 upstream-assigned label could be an implicit NULL. 217 When intra-area segments of the inter-area P2MP service LSP are 218 instantiated using ingress replication, then multiple such segments 219 may be carried in the same P2P RSVP-TE or MP2P LDP LSP. This can be 220 achieved using downstream-assigned labels alone. 222 The ingress area segment of a P2MP service LSP is rooted at a PE (or 223 at an ASBR in the case where the P2MP service LSP spans multiple 224 ASes). The leaves of this segment are other PEs/ASBRs and ABRs in the 225 same area as the root PE. The backbone area segment is rooted at an 226 ABR that is connected to the ingress area (ingress ABR), and has as 227 its leaves ABRs that are connected to the egress area(s) or PEs in 228 the backbone area. The egress area segment is rooted at an ABR in the 229 egress area (egress ABR), and has as its leaves PEs and ASBR in that 230 egress area (the latter covers the case where the P2MP service LSP 231 spans multiple ASes). Note that for a given P2MP service LSP there 232 may be more than one backbone segment, each rooted at its own ingress 233 ABR, and more than one egress area segment, each rooted at its own 234 egress ABR. 236 An implementation that supports this document MUST implement the 237 procedures described in the following sections to support inter-area 238 point-to-multipoint (P2MP) segmented service LSPs. 240 4. Inter-area P2MP Segmented Next-Hop Extended Community 242 This document defines a new BGP Extended Community "Inter-area P2MP 243 Next-Hop" extended community. This is an IP address specific Extended 244 Community, of an extended type and is transitive across AS boundaries 245 [RFC4360]. 247 A PE or an ABR or an ASBR constructs the Inter-area P2MP Segmented 248 Next-Hop Extended Community as follows: 250 - The Global Administrator field MUST be set to an IP address of 251 the PE or ASBR or ABR that originates or advertises the route, 252 which carries the P2MP Next-Hop Extended Community. For example 253 this address may be the loopback address or the PE, ASBR or ABR 254 that advertises the route. 256 - The Local Administrator field MUST be set to 0. 258 The detailed usage of this extended community is described in the 259 following sections. 261 5. Discovering the P2MP FEC of the Inter-Area P2MP Service LSP 263 The P2MP FEC identifies the inter-area P2MP service LSP. The egress 264 PEs need to learn this P2MP FEC in order to initiate the creation of 265 the egress area segment of the P2MP inter-area service LSP. 267 The P2MP FEC of the inter-area P2MP LSP is learned by the egress PEs 268 either by configuration, or based on the application-specific 269 procedures (e.g., MVPN-specific procedures, VPLS-specific 270 procedures). 272 5.1. BGP MVPN 274 Egress PEs discover the P2MP FEC of the service LSPs used by BGP MVPN 275 using the I-PMSI or S-PMSI auto-discovery routes that are originated 276 by the ingress PEs or ASBRs following the procedures of [BGP-MVPN], 277 along with modifications as described in this document. The NLRI of 278 such routes encodes the P2MP FEC. The procedures in this document 279 require that at least one ABR in a given IGP area act as Route 280 Reflector for MVPN auto-discovery routes. 282 The "Leaf Information Required" flag MUST be set in the P-Tunnel 283 attribute carried in such routes, when originated by the ingress PEs 284 or ASBRs, except for the case where (a) as a matter of policy 285 (provisioned on the ingress PEs or ASBRs) there is no aggregation of 286 ingress area segments of the service LSPs, and (b) mLDP is used as 287 the protocol to establish intra-area transport LSPs in the ingress 288 area. Before any Leaf auto discovery route is advertised by a PE or 289 ABR in the same area, as described in the following sections, an I- 290 PMSI/S-PMSI auto-discovery route is advertised either with an 291 explicit Tunnel Type and Tunnel Identifier in the PMSI Tunnel 292 Attribute, if the Tunnel Identifier has already been assigned, or 293 with a special Tunnel Type of "No tunnel information present" 294 otherwise. 296 When the I-PMSI/S-PMSI routes are re-advertised by an ingress ABR, 297 the "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-PMSI/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 auto-discovery routes are advertised 315 or propagated to signal Inter-area P2MP service LSPs, to indicate 316 that these LSPs should be segmented using the procedures specified in 317 this document, these routes MUST carry the Inter-area P2MP Segmented 318 Next-Hop Extended Community. This Extended Community MUST be included 319 in the I-PMSI/S-PMSI auto-discovery route by the PE or ASBR that 320 originates such a route, and the Global Administrator field MUST be 321 set to the advertising PE or ASBR's IP address. This Extended 322 Community MUST also be included by ABRs as they re-advertise such 323 routes. An ABR MUST set the Global Administrator field of the P2MP 324 Segmented Next-Hop Extended Community to its own IP address. 325 Presense of this community in the I-PMSI/S-PMSI auto-discovery routes 326 indicates to ABRs and PEs/ASBRs that they have to follow the 327 procedures in this document when these procedures differ from those 328 in [BGP-MVPN]. 330 To avoid requiring ABRs to participate in the propagation of C- 331 multicast routes, this document requires ABRs NOT to modify BGP Next 332 Hop when re-advertising Inter-AS I-PMSI auto-discovery routes. For 333 consistency this document requires ABRs to NOT modify BGP Next-Hop 334 when re-advertising both Intra-AS and Inter-AS I-PMSI/S-PMSI auto- 335 discovery routes. The egress PEs may advertise the C-multicast routes 336 to RRs that are different than the ABRs. However ABRs still can be 337 configured to be the Route Reflectors for C-multicast routes, in 338 which case they will participate in the propagation of C-multicast 339 routes. 341 5.2. BGP VPLS or LDP VPLS with BGP auto-discovery 343 Egress PEs discover the P2MP FEC of the service LSPs used by VPLS, 344 using the VPLS auto-discovery routes that are originated by the 345 ingress PEs [BGP-VPLS, VPLS-AD] or S-PMSI auto-discovery routes that 346 are originated by the ingress PE [VPLS-P2MP]. The NLRI of such routes 347 encodes the P2MP FEC. 349 The "Leaf Information Required" flag MUST be set in the P-Tunnel 350 attribute carried in such routes, when originated by the ingress PEs 351 or ASBRs, except for the case where (a) as a matter of policy 352 (provisioned on the ingress PEs or ASBRs) there is no aggregation of 353 ingress area segments of the service LSPs, and (b) mLDP is used as 354 the protocol to establish intra-area transport LSPs in the ingress 355 area. Before any Leaf auto-discovery route is advertised by a PE or 356 ABR in the same area, as described in the following sections, an 357 VPLS/S-PMSI auto-discovery route is advertised either with an 358 explicit Tunnel Type and Tunnel Identifier in the PMSI Tunnel 359 Attribute, if the Tunnel Identifier has already been assigned, or 360 with a special Tunnel Type of "No tunnel information present" 361 otherwise. 363 When the VPLS/S-PMSI auto-discovery routes are re-advertised by an 364 ingress ABR, the "Leaf Information Required" flag MUST be set in the 365 P-Tunnel attribute present in the routes, except for the case where 366 (a) as a matter of policy (provisioned on the ingress ABR) there is 367 no aggregation of backbone area segments of the service LSPs, and (b) 368 mLDP is used as the protocol to establish intra-area transport LSPs 369 in the backbone area. Likewise, when the VPLS/S-PMSI auto-discovery 370 routes are re-advertised by an egress ABR, the "Leaf Information 371 Required" flag MUST be set in the P-Tunnel attribute present in the 372 routes, except for the case where (a) as a matter of policy 373 (provisioned on the egress ABR) there is no aggregation of egress 374 area segments of the service LSPs, and (b) mLDP is used as the 375 protocol to establish intra-area transport LSPs in the egress area. 377 When VPLS auto-discovery or S-PMSI auto-discovery routes are 378 advertised or propagated to signal Inter-area P2MP service LSPs, to 379 indicate that these LSPs should be segmented using the procedures 380 specified in this document, these routes MUST carry the Inter-area 381 P2MP Segmented Next-Hop Extended Community. This Extended Community 382 MUST be included in the auto-discovery route by the PE or ASBR that 383 originates such a route and the Global Administrator field MUST be 384 set to the advertising PE or ASBR's IP address. This Extended 385 Community MUST also be included by ABRs as they re-advertise such 386 routes. An ABR MUST set the Global Administrator field of the P2MP 387 Segmented Next-Hop Extended Community to its own IP address. 388 Presense of this community in the I-PMSI/S-PMSI auto-discovery routes 389 indicates to ABRs and PEs/ASBRs that they have to follow the 390 procedures in this document when these procedures differ from those 391 in [VPLS-P2MP]. 393 Note that the procedures in the above paragraph apply when intra-area 394 segments are realized by either intra-area P2MP LSPs or by ingress 395 replication. 397 The procedures in this document require that at least one ABR in a 398 given area act as Route Reflector for MVPN auto-discovery routes. 399 These ABRs/RRs MUST NOT modify BGP Next Hop when re-advertising these 400 auto-discovery routes. 402 5.3. IP Multicast over MPLS 404 This section describes how the egress PEs discover the P2MP FEC when 405 the application is IP multicast over an MPLS-capable infrastructure. 406 In the rest of the document we will refer to this application as 407 "global table multicast". 409 In the case where global table multicast uses PIM-SM in ASM mode the 410 following assumes that an inter-area P2MP service LSP could be used 411 to either carry traffic on a shared (*,G), or a source (S,G) tree. 413 An egress PE learns the (S/*, G) of a multicast stream as a result of 414 receiving IGMP or PIM messages on one of its IP multicast interfaces. 415 This (S/*, G) forms the P2MP FEC of the inter-area P2MP service LSP. 416 For each (S/*,G) for which an inter-area P2MP service LSP is 417 instantiated, there may exist a distinct inter-area P2MP service LSP 418 or multiple inter-area P2MP service LSPs may be aggregated using a 419 wildcard (*, *) S-PMSI [MVPN-WILDCARD-SPMSI]. 421 Note that this document does not require the use of (*, G) Inter-area 422 P2MP service LSPs when global table multicast uses PIM-SM in ASM 423 mode. Infact PIM-SM in ASM mode may be supported entirely by using 424 (S, G) trees alone. 426 6. Egress PE Procedures 428 This section describes egress PE procedures for constructing 429 segmented inter-area P2MP LSP. The procedures in this section apply 430 irrespective of whether the egress PE is in a leaf IGP area, or the 431 backbone area or even in the same IGP area as the ingress PE/ASBR. 433 An egress PE applies procedures specified in this section to MVPN I- 434 PMSI or S-PMSI auto-discovery routes only if these routes carry the 435 Inter-area P2MP Segmented Next-Hop Extended Community. An egress PE 436 applies procedures specified in this section to VPLS auto-discovery 437 or S-PMSI auto-discovery routes only if these routes carry the Inter- 438 area P2MP Segmented Next-Hop Extended Community. 440 In order to support global table multicast an egress PE MUST auto- 441 configure an import Route Target with the global administrator field 442 set to the AS of the PE and the local administrator field set to 0. 444 Once an egress PE discovers the P2MP FEC of an inter-area segmented 445 P2MP service LSP, it MUST propagate this P2MP FEC in BGP in order to 446 construct the segmented inter-area P2MP service LSP. This propagation 447 uses BGP Leaf auto-discovery routes. 449 6.1. Determining the Upstream ABR/PE/ASBR 451 The egress PE discovers the P2MP FEC of an inter-area P2MP Segmented 452 Service LSP as described in section 5. When an egress PE discovers 453 this P2MP FEC it MUST first determine the upstream node to reach such 454 a FEC. If the egress PE is in the egress area and the ingress PE is 455 not in the that egress area, then this upstream node would be the 456 egress ABR. If the egress PE is in the backbone area and the ingress 457 PE is not in the backbone area, then this upstream node would be the 458 ingress ABR. If the egress PE is in the same area as the ingress PE 459 then this upstream node would be the ingress PE. 461 If the application is MVPN or VPLS then the upstream node's IP 462 address is the IP address determined from the Global Administrator 463 field of the Inter-area P2MP Segmented Next-hop Extended Community. 464 As described in section 5, this Extended Community MUST be carried in 465 the MVPN or VPLS auto-discovery route from which the P2MP FEC of the 466 inter-area P2MP Segmented Service LSP is determined. 468 If the application is global table multicast then the unicast routes 469 to multicast sources/RPs SHOULD carry the VRF Route Import Extended 470 Community [BGP-MVPN] where the IP address in the Global Administrator 471 field is set to the IP address of the PE or ASBR advertising the 472 unicast route. The Local Administrator field of this community MUST 473 be set to 0. If it is not desirable to advertise the VRF Route Import 474 Extended Community in unicast routes, then unicast routes to 475 multicast sources/RPs MUST be advertised using the multicast SAFI 476 i.e. SAFI 2, and such routes MUST carry the VRF Route Import 477 Extended Community. 479 Further if the application is global table multicast then the BGP 480 unicast routes that advertise the route to the IP address of PEs or 481 ASBRs or ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop 482 Extended Community where the IP address in the Global Administrator 483 field is set to the IP address of the PE or ASBR or ABR advertising 484 the unicast route. The Local Administrator field of this community 485 MUST be set to 0. If it is not desirable to advertise the P2MP 486 Segmented Next-Hop Extended Community in BGP unicast routes, then 487 unicast routes to ABRs, ASBRs or PEs MUST be advertised using the 488 multicast SAFI i.e. SAFI 2, and such routes MUST carry the Inter-area 489 P2MP Segmented Next-hop Extended Community. 491 The procedures for handling the BGP Next-Hop attribute of SAFI 2 492 routes are the same as those of handling regular Unicast routes and 493 follow [SEAMLESS-MPLS]. 495 If the application is global table multicast, then in order to 496 determine the upstream node address the egress PE first determines 497 the ingress PE. In order to determine the ingress PE the egress PE 498 determines the best route to reach S/RP. The ingress PE address is 499 the IP address determined from the Global Administrator field of the 500 VRF Route Import Extended Community, that is present in this route. 501 The egress PE now finds the best unicast route to reach the ingress 502 PE. The upstream node address is the IP address determined from the 503 Global Administrator field of the Inter-area P2MP Segmented Next-Hop 504 Extended Community, that is present in this route. 506 6.2. Originating a Leaf Auto-Discovery Route 508 If the P2MP FEC was derived from a MVPN or VPLS auto-discovery route 509 then the egress PE MUST originate a Leaf auto-discovery route if the 510 MVPN or VPLS auto-discovery route carries a P-Tunnel Attribute with 511 the "Leaf Information Required" flag set. 513 If the P2MP FEC was derived from a global table multicast (S/*, G), 514 and the upstream node's address is not the same as the egress PE, 515 then the egress PE MUST originate a Leaf auto-discovery route. 517 6.2.1. Leaf Auto-Discovery Route for MVPN and VPLS 519 If the P2MP FEC was derived from MVPN or VPLS auto-discovery routes 520 then the Route Key field of the Leaf auto-discovery route contains 521 the NLRI of the auto-discovery route from which the P2MP FEC was 522 derived. This follows procedures for constructing Leaf auto-discovery 523 routes described in [BGP-MVPN, VPLS-P2MP]. 525 6.2.2. Leaf Auto-Discovery Route for Global Table Multicast 527 If the application is global table multicast then the MCAST-VPN NLRI 528 of the Leaf auto-discovery route is constructed as follows: 530 The Route Key field of MCAST-VPN NLRI has the following format: 532 +-----------------------------------+ 533 | RD (8 octets) | 534 +-----------------------------------+ 535 | Multicast Source Length (1 octet) | 536 +-----------------------------------+ 537 | Multicast Source (Variable) | 538 +-----------------------------------+ 539 | Multicast Group Length (1 octet) | 540 +-----------------------------------+ 541 | Multicast Group (Variable) | 542 +-----------------------------------+ 543 | Ingress PE's IP address | 544 +-----------------------------------+ 546 RD is set to 0 for (S,G) state and all 1s for (*,G) state, Multicast 547 Source is set to S for (S,G) state or RP for (*,G) state, Multicast 548 Group is set to G, Multicast Source Length and Multicast Group Length 549 is set to either 4 or 16 (depending on whether S/RP and G are IPv4 or 550 IPv6 addresses). 552 The Ingress PE's IP address is determined as described in the section 553 "Determining the Upstream ABR/PE/ASBR". 555 The Originating Router's IP address field of MCAST-VPN NLRI is set to 556 the address of the local PE (PE that originates the route). 558 Thus the entire MCAST-VPN NLRI of the route has the following format: 560 +-----------------------------------+ 561 | Route Type = 4 (1 octet) | 562 +-----------------------------------+ 563 | Length (1 octet) | 564 +-----------------------------------+ 565 | RD (8 octets) | 566 +-----------------------------------+ 567 | Multicast Source Length (1 octet) | 568 +-----------------------------------+ 569 | Multicast Source (Variable) | 570 +-----------------------------------+ 571 | Multicast Group Length (1 octet) | 572 +-----------------------------------+ 573 | Multicast Group (Variable) | 574 +-----------------------------------+ 575 | Ingress PE's IP address | 576 +-----------------------------------+ 577 | Originating Router's IP address | 578 +-----------------------------------+ 580 Note that the encoding of MCAST-VPN NLRI for the Leaf auto-discovery 581 routes used for global table multicast is different from the encoding 582 used by the Leaf auto-discovery routes originated in response to S- 583 PMSI or I-PMSI auto-discovery routes. A router that receives a Leaf 584 auto-discover route can distinguish between these two cases by 585 examining the third octet of the MCAST-VPN NLRI of the route. If the 586 value of this octet is either 0x00 or 0xff, then this is a Leaf auto- 587 discovery route used for global table multicast. If the value of this 588 octet is 0x01 or 0x02, or 0x03 then this Leaf auto-discovery route 589 was originated in response to an S-PMSI or I-PMSI auto-discovery 590 route. 592 When the PE deletes (S,G)/(*,G) state that was created as a result of 593 receiving PIM or IGMP messages on one of its IP multicast interfaces, 594 if the PE previousely originated a Leaf auto-discovery route for that 595 state, then the PE SHOULD withdraw that route. 597 An Autonomous System with an IPv4 network may provide IP multicast 598 service for customers that use IPv6, and an Autonomous System with an 599 IPv6 network may provide IP multicast service for customers that use 600 IPv4. Therefore the address family of the Ingress PE's IP address and 601 Originating Router's IP address in the Leaf auto-discovery routes 602 used for global table multicast MUST NOT be inferred from the AFI 603 field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI attribute of 604 these routes. The address family is determined from the length of 605 the address (a length of 4 octets for IPv4 addresses, a length of 16 606 octets for IPv6 addresses). 608 For example if an Autonomous System with an IPv4 network is 609 providing IPv6 multicast service to a customer, the Ingress PE's IP 610 address and Originating Router's IP address in the Leaf auto- 611 discovery routes used for IPv6 global table multicast will be a four- 612 octet IPv4 address, even though the AFI of those routes will have the 613 value 2. 615 Note that the Ingress PE's IP address and the Originating Router's IP 616 address must be either both IPv4 or both IPv6 addresses, and thus 617 must be of the same length. Since the two variable length fields 618 (Multicast Source and Multicast Group) in the Leaf auto-discovery 619 routes used for global table multicast have their own length field, 620 from these two length fields, and the Length field of the MCAST-VPN 621 NLRI, one can compute length of the Ingress PE's IP address and the 622 Originating Router's IP address fields. If the computed length of 623 these fields is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be 624 considered to be "incorrect", and MUST be handled as specified in 625 section 7 of [BGP-MP]. 627 6.2.3. Constructing the Rest of the Leaf Auto-Discovery Route 629 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 630 be set to the same IP address as the one carried in the Originating 631 Router's IP Address field of the route. 633 When Ingress Replication is used to instantiate the egress area 634 segment then the Leaf auto-discovery route MUST carry a downstream 635 assigned label in the P-Tunnel Attribute where the P-Tunnel type is 636 set to Ingress Replication. A PE MUST assign a distinct MPLS label 637 for each Leaf auto-discovery route originated by the PE. 639 To constrain distribution of this route, the originating PE 640 constructs an IP-based Route Target community by placing the IP 641 address of the upstream node in the Global Administrator field of the 642 community, with the Local Administrator field of this community set 643 to 0. The originating PE then adds this Route Target Extended 644 Community to this Leaf auto-discovery route. The upstream node's 645 address is as determined in section 6.1. 647 The PE then advertises this route to the upstream node. 649 6.3. PIM-SM in ASM mode for Global Table Multicast 651 This specification allows two options for supporting global table 652 multicast with PIM-SM in ASM mode. The first option does not transit 653 IP multicast shared trees over the MPLS network. The second option 654 does transit shared trees over the MPLS network and relies on shared 655 tree to source tree switchover. 657 6.3.1. Option 1 659 This option does not transit IP multicast shared trees over the MPLS 660 network. Therefore, when an (egress) PE creates (*, G) state (as a 661 result of receiving PIM or IGMP messages on one of its IP multicast 662 interfaces), the PE does not propagate this state using Leaf auto- 663 discovery routes. 665 6.3.1.1. Originating Source Active auto-discovery routes 667 Whenever as a result of receiving PIM Register or MSDP messages an RP 668 discovers a new multicast source, the RP SHOULD originate a BGP 669 Source Active auto-discovery route. Similarly whenever as a result of 670 receiving MSDP messages a PE, that is not configured as a RP, 671 discovers a new multicast source the PE SHOULD originate a BGP Source 672 Active auto-discovery route. The BGP Source Active auto-discovery 673 route carries a single MCAST-VPN NLRI constructed as follows: 675 + The RD in this NLRI is set to 0. 677 + The Multicast Source field MUST be set to S. The Multicast 678 Source Length field is set appropriately to reflect this. 680 + The Multicast Group field MUST be set to G. The Multicast Group 681 Length field is set appropriately to reflect this. 683 To constrain distribution of the Source Active auto-discovery route 684 to the AS of the advertising RP this route SHOULD carry the NO_EXPORT 685 Community ([RFC1997]). 687 Using the normal BGP procedures the Source Active auto-discovery 688 route is propagated to all other PEs within the AS. 690 Whenever the RP discovers that the source is no longer active, the RP 691 MUST withdraw the Source Active auto-discovery route, if such a route 692 was previousely advertised by the RP. 694 6.3.1.2. Receiving BGP Source Active auto-discovery route by PE 696 When as a result of receiving PIM or IGMP messages on one of its IP 697 multicast interfaces an (egress) PE creates in its Tree Information 698 Base (TIB) a new (*, G) entry with a non-empty outgoing interface 699 list that contains one or more IP multicast interfaces, the PE MUST 700 check if it has any Source Active auto-discovery routes for that G. 701 If there is such a route, S of that route is reachable via an MPLS 702 interface, and the PE does not have (S, G) state in its TIB for (S, 703 G) carried in the route, then the PE originates a Leaf auto-discovery 704 routes carrying that (S, G), as specified in Section "Leaf Auto- 705 Discovery Route for Global Table Multicast". 707 When an (egress) PE receives a new Source Active auto-discovery 708 route, the PE MUST check if its TIB contains an (*, G) entry with the 709 same G as carried in the Source Active auto-discovery route. If such 710 an entry is found, S is reachable via an MPLS interface, and the PE 711 does not have (S, G) state in its TIB for (S, G) carried in the 712 route, then the PE originates a Leaf auto-discovery routes carrying 713 that (S, G), as specified in Section "Leaf Auto-Discovery Route for 714 Global Table Multicast". 716 6.3.1.3. Handling (S, G, RPTbit) state 718 Creation and deletion of (S, G, RPTbit) state on a PE that resulted 719 from receiving PIM messages on one of its IP multicast interfaces 720 does not result in any BGP actions by the PE. 722 6.3.2. Option 2 724 This option does transit IP multicast shared trees over the MPLS 725 network. Therefore, when an (egress) PE creates (*, G) state (as a 726 result of receiving PIM or IGMP messages on one of its IP multicast 727 interfaces), the PE does propagate this state using Leaf auto- 728 discovery routes. 730 6.3.2.1. Originating Source Active auto-discovery routes 732 Whenever a PE creates an (S, G) state as a result of receiving Leaf 733 auto-discovery routes associated with the global table multicast 734 service, if S is reachable via one of the IP multicast capable 735 interfaces, and the PE determines that G is in the PIM-SM in ASM mode 736 range, the PE MUST originate a BGP Source Active auto-discovery 737 route. The route carries a single MCAST-VPN NLRI constructed as 738 follows: 740 + The RD in this NLRI is set to 0. 742 + The Multicast Source field MUST be set to S. The Multicast 743 Source Length field is set appropriately to reflect this. 745 + The Multicast Group field MUST be set to G. The Multicast Group 746 Length field is set appropriately to reflect this. 748 To constrain distribution of the Source Active auto-discovery route 749 to the AS of the advertising PE this route SHOULD carry the NO_EXPORT 750 Community ([RFC1997]). 752 Using the normal BGP procedures the Source Active auto-discovery 753 route is propagated to all other PEs within the AS. 755 Whenever the PE deletes the (S, G) state that was previously created 756 as a result of receiving a Leaf auto-discovery route for (S, G), the 757 PE that deletes the state MUST also withdraw the Source Active auto- 758 discovery route, if such a route was advertised when the state was 759 created. 761 6.3.2.2. Receiving BGP Source Active auto-discovery route 763 Procedures for receiving BGP Source Active auto-discovery routes are 764 the same as with Option 1. 766 6.3.2.3. Pruning Sources off the Shared Tree 768 If after receiving a new Source Active auto-discovery route for (S,G) 769 a PE determines that (a) it has the (*, G) entry in its TIB, (b) the 770 incoming interface list (iif) for that entry contains one of the IP 771 interfaces, (c) a MPLS LSP is in the outgoing interface list (oif) 772 for that entry, and (d) the PE does not originate a Leaf auto- 773 discovery route for (S,G), then the PE MUST transition the (S,G,rpt) 774 downstream state to the Prune state. [Conceptually the PIM state 775 machine on the PE will act "as if" it had received Prune(S,G,Rpt) 776 from some other PE, without actually having received one.] Depending 777 on the (S,G,rpt) state on the iifs, this may result in the PE using 778 PIM procedures to prune S off the Shared (*,G) tree. 780 Transitioning the state machine to the Prune state SHOULD be done 781 after a delay that is controlled by a timer. The value of the timer 782 MUST be configurable. The purpose of this timer is to ensure that S 783 is not pruned off the shared tree until all PEs have had time to 784 receive the Source Active auto-discovery route for (S,G). 786 The PE MUST keep the (S,G,rpt) downstream state machine in the Prune 787 state for as long as (a) the outgoing interface list (oif) for (*, G) 788 contains a MPLS LSP, and (b) the PE has at least one Source Active 789 auto-discovery route for (S,G), and (c) the PE does not originate the 790 Leaf auto-discovery route for (S,G). Once either of these conditions 791 become no longer valid, the PE MUST transition the (S,G,rpt) 792 downstream state machine to the NoInfo state. 794 Note that except for the scenario described in the first paragraph of 795 this section, in all other scenarios relying solely on PIM procedures 796 on the PE is sufficient to ensure the correct behavior when pruning 797 sources off the shared tree. 799 6.3.2.4. More on handling (S, G, RPTbit) state 801 Creation and deletion of (S, G, RPTbit) state on a PE that resulted 802 from receiving PIM messages on one of its IP multicast interfaces 803 does not result in any BGP actions by the PE. 805 7. Egress ABR Procedures 807 This section describes Egress ABR Procedures for constructing 808 segmented inter-area P2MP LSP. 810 When an egress ABR receives a Leaf auto-discovery route and the Route 811 Target extended community carried by the route contains the IP 812 address of this ABR, then the following procedures will be executed. 814 If the RD of the received Leaf auto-discovery route is not set to all 815 0s or all 1s, then the egress ABR MUST find a S-PMSI or I-PMSI route 816 whose NLRI has the same value as the Route Key field of the received 817 Leaf auto-discovery route. If such a matching route is found then the 818 Leaf auto-discovery route MUST be accepted, else it MUST be 819 discarded. If the Leaf auto-discovery route is accepted and if its 820 the first Leaf auto-discovery route update for the Route Key field in 821 the route, or the withdrawl of the last Leaf auto-discovery route for 822 the Route Key field then the following procedures will be executed. 824 If the RD of the received Leaf auto-discovery route is set to all 0s 825 or all 1s then the received Leaf auto-discovery route is for the 826 global table multicast service. In that case for the following 827 procedure the Route Prefix is set to all fields of the Route Key 828 minus the Ingress PE address. If this is the first Leaf auto- 829 discovery route update for this Route Prefix or the withdrawl of the 830 last Leaf auto-discovery route for the Route Prefix then the 831 following procedures will be executed. 833 While generating a Leaf auto-discovery route update, the egress ABR 834 originates a Leaf auto-discovery route, whose MCAST-VPN NLRI is 835 constructed as follows. 837 The Route Key field of MCAST-VPN NLRI is the same as the Route Key 838 field of MCAST-VPN NLRI of the received Leaf auto-discovery route. 839 The Originating Router's IP address field of MCAST-VPN NLRI is set to 840 the address of the local ABR (the ABR that originates the route). 842 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 843 be set to the same IP address as the one carried in the Originating 844 Router's IP Address field of the route. 846 To constrain distribution of this route the originating egress ABR 847 constructs an IP-based Route Target community by placing the IP 848 address of the upstream node in the Global Administrator field of the 849 community, with the Local Administrator field of this community set 850 to 0, and sets the Extended Communities attribute of this Leaf auto- 851 discovery route to that community. 853 The upstream node's IP address is the IP address determined from the 854 Global Administrator field of the Inter-area P2MP Segmented Next-hop 855 Extended Community, where this Extended Community is obtained as 856 follows. When the Leaf auto-discovery route is for MVPN or VPLS then 857 this Extended Community is the one included in the I-PMSI/S-PMSI 858 auto-discovery route that matches the Leaf auto-discovery route. 859 When the Leaf auto-discovery route is for global table multicast then 860 this Extended Community is obtained from the best unicast route to 861 the Ingress PE. The Ingress PE address is determined from the 862 received Leaf auto-discovery route. The best unicast route MUST 863 first be determined from multicast SAFI i.e., SAFI 2 routes, if 864 present. 866 The ABR then advertises this Leaf auto-discovery route to the 867 upstream node in the backbone area. 869 Mechanisms specific in [RFC4684] for constrained BGP route 870 distribution can be used along with this specification to ensure that 871 only the needed PE/ABR will have to process a said Leaf auto- 872 discovery route. 874 When Ingress Replication is used to instantiate the backbone area 875 segment then the Leaf auto-discovery route originated by the egress 876 ABR MUST carry a downstream assigned label in the P-Tunnel Attribute 877 where the P-Tunnel type is set to Ingress Replication. An ABR MUST 878 assign a distinct MPLS label for each Leaf auto-discovery route 879 originated by the ABR. 881 In order to support global table multicast an egress ABR MUST auto- 882 configure an import Route Target with the global administrator field 883 set to the AS of the ABR and the local administrator field set to 0. 885 When the Leaf auto-discovery route is for global table multicast and 886 if the following conditions hold true: 888 - its not the first Leaf auto-discovery route for the Route Prefix, 889 where the Route Prefix is determined as described above, and 891 - the set of ingress PEs associated with the Route Prefix 892 changes as a result of the new Leaf auto-discovery route, or 894 - the ABR determines based on local policy to propagate 895 the Leaf auto-discovery route towards a different ingress PE than 896 the one to which the Leaf auto-discovery route is being currently 897 propagated, 898 then the egress ABR MUST originate the Leaf auto-discovery route as 899 described in this section. 901 If the received Leaf auto-discovery route is the last Leaf auto- 902 discovery route for the Route Key for MVPN or VPLS or for the Route 903 Prefix, as described above, for global table multicast, then the ABR 904 must withdraw the previously advertised Leaf auto-discovery route. 906 7.1. P2MP LSP as the Intra-Area LSP in the Egress Area 908 This section describes procedures for using intra-area P2MP LSPs in 909 the egress area. The procedures that are common to both P2MP RSVP-TE 910 and P2MP LDP are described first, followed by procedures that are 911 specific to the signaling protocol. 913 When P2MP LSPs are used as the intra-area LSPs, note that an existing 914 intra-area P2MP LSP may be used solely for a particular inter-area 915 P2MP service LSP, or for other inter-area P2MP service LSPs as well. 916 The choice between the two options is purely local to the egress ABR. 917 The first option provides one-to-one mapping between inter-area P2MP 918 service LSPs and intra-area P2MP LSPs; the second option provides 919 many-to-one mapping, thus allowing to aggregate forwarding state. 921 7.1.1. RD of the received Leaf auto-discovery route is not all 0s or all 922 1s 924 When the RD of the received Leaf auto-discovery route is not set to 925 all 0s or all 1s, then the ABR MUST re-advertise in the egress area 926 the MVPN/VPLS auto-discovery route, that matches the Leaf auto- 927 discovery route to signal the binding of the intra-area P2MP LSP to 928 the inter-area P2MP service LSP. This must be done ONLY if (a) such a 929 binding hasn't already been advertised, or (b) the binding has 930 changed. The re-advertised route MUST carry the Inter-area P2MP 931 Segmented Next-Hop Extended Community. 933 The PMSI Tunnel attribute of the re-advertised route specifies either 934 an intra-area P2MP RSVP-TE LSP or an intra-area P2MP LDP LSP rooted 935 at the ABR and MUST also carry an upstream assigned MPLS label. The 936 upstream-assigned MPLS label MUST be set to implicit NULL if the 937 mapping between the inter-area P2MP service LSP and the intra-area 938 P2MP LSP is one-to-one. If the mapping is many-to-one the intra-area 939 segment of the inter-area P2MP service LSP (referred to as the 940 "inner" P2MP LSP) is constructed by nesting the inter-area P2MP 941 service LSP in an intra-area P2MP LSP (referred to as the "outer" 942 intra-area P2MP LSP), by using P2MP LSP hierarchy based on upstream- 943 assigned MPLS labels [RFC 5332]. 945 If segments of multiple MVPN or VPLS S-PMSI service LSPs are carried 946 over a given intra-area P2MP LSP, each of these segments MUST carry a 947 distinct upstream-assigned label, even if all these service LSPs are 948 for (C-S/*, C-G/*)s from the same MVPN/VPLS. Therefore, an ABR 949 maintains an LFIB state for each of the (C-S/*, C-G/*)s carried over 950 S-PMSIs traversing this ABR (that applies to both the ingress and the 951 egress ABRs). 953 7.1.2. RD of the received Leaf auto-discovery route is all 0s or all 1s 955 When the RD of the received Leaf auto-discovery route is set to all 956 0s or all 1s, then this is the case of inter-area P2MP service LSP 957 being associated with the global table multicast service. The 958 procedures for this are described below. 960 7.1.2.1. Global Table Multicast and S-PMSI Auto-Discovery Routes 962 This section applies only if it is desirable to send a particular 963 global table multicast flow to only those egress PEs that have 964 receivers in a particular (S, G) or a particular (*, G) multicast 965 flow. 967 The egress ABR MUST originate a S-PMSI auto-discovery route. The PMSI 968 Tunnel attribute of the route MUST contain the identity of the intra- 969 area P2MP LSP and an upstream assigned MPLS label. The RD, Multicast 970 Source Length, Multicast Source, Multicast Group Length (1 octet), 971 and Multicast Group fields of the NLRI of this route are the same as 972 of the Leaf auto-discovery route. The egress ABR MUST advertise this 973 route into the egress area. The Route Target of this route is an AS 974 specific route-target with the AS set to the AS of the advertising 975 ABR while the local administrator field is set to 0. 977 7.1.2.2. Global Table Multicast and Wildcard S-PMSI Auto-Discovery 978 Routes 980 It may be desirable for an ingress PE to carry multiple multicast 981 flows associated with the global table multicast routes over the same 982 inter-area P2MP LSP. This can be achieved using wildcard, i.e., (*,*) 983 S-PMSI auto-discovery routes [MVPN-WILDCARD-SPMSI]. An ingress PE 984 MAY advertise a wildcard S-PMSI auto-discovery route as described in 985 section "Ingress PE Procedures". If the ingress PE does indeed 986 originate such a route, the egress ABR would receive this route from 987 the ingress ABR and MUST re-advertise it with the PMSI Tunnel 988 Attribute containing the identifier of the intra-area P2MP LSP in the 989 egress area and an upstream assigned label assigned to the inter-area 990 wildcard S-PMSI. 992 7.1.3. Global Table Multicast and the Expected Upstream Node 994 If the mapping between the inter-area P2MP service LSP for global 995 table multicast service and the intra-area P2MP LSP is many-to-one 996 then an egress PE must be able to determine whether a given multicast 997 packet for a particular (S, G) is received from the "expected" 998 upstream node. The expected node is the node towards which the Leaf 999 auto-discovery route is sent by the egress PE. Packets received from 1000 another upstream node for that (S, G) MUST be dropped. To allow the 1001 egress PE to determine the sender upstream node, the intra-area P2MP 1002 LSP must be signaled with no PHP, when the mapping between the inter- 1003 area P2MP service LSP for global table multicast service and the 1004 intra-area P2MP LSP is many-to-one. 1006 Further the egress ABR MUST first push onto the label stack the 1007 upstream assigned label advertised in the S-PMSI route, if the label 1008 is not an Implicit NULL. 1010 7.1.4. P2MP LDP LSP as the Intra-Area P2MP LSP in the Egress Area 1012 The above procedures are sufficient if P2MP LDP LSPs are used as the 1013 Intra-area P2MP LSP in the Egress area. 1015 7.1.5. P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area 1017 If P2MP RSVP-TE LSP is used as the the intra-area LSP in the egress 1018 area, then the egress ABR can either (a) graft the leaf (whose IP 1019 address is specified in the received Leaf auto-discovery route) into 1020 an existing P2MP LSP rooted at the egress ABR, and use that LSP for 1021 carrying traffic for the inter-area segmented P2MP service LSP, or 1022 (b) originate a new P2MP LSP to be used for carrying (S,G). 1024 When the RD of the received Leaf auto-discovery route is all 0s or 1025 all 1s, then the procedures are as described in section 7.1.2 ("RD 1026 of the received Leaf Auto-Discovery route is all 0s or all 1s"). 1028 Note also that the SESSION object that the egress ABR would use for 1029 the intra-area P2MP LSP need not encode the P2MP FEC from the 1030 received Leaf auto-discovery route. 1032 7.2. Ingress Replication in the Egress Area 1034 When Ingress Replication is used to instantiate the egress area 1035 segment then the Leaf auto-discovery route advertised by the egress 1036 PE MUST carry a downstream assigned label in the P-Tunnel Attribute 1037 where the P-Tunnel type is set to Ingress Replication. We will call 1038 this label the egress PE downstream assigned label. 1040 The egress ABR MUST forward packets received from the backbone area 1041 intra-area segment, for a particular inter-area P2MP LSP, to all the 1042 egress PEs from which the egress ABR has imported a Leaf auto- 1043 discovery route for the inter-area P2MP LSP. A packet to a particular 1044 egress PE is encapsulated, by the egress ABR, using a MPLS label 1045 stack the bottom label of which is the egress PE downstream assigned 1046 label. The top label is the P2P RSVP-TE or the MP2P LDP label to 1047 reach the egress PE. 1049 Note that these procedures ensures that an egress PE always receives 1050 packets only from the expected upstream PE. 1052 8. Ingress ABR Procedures for constructing segmented inter-area P2MP LSP 1054 When an ingress ABR receives a Leaf auto-discovery route and the 1055 Route Target extended community carried by the route contains the IP 1056 address of this ABR, then the following procedures will be executed. 1058 The ingress ABR follows the same procedures as in the section "Egress 1059 ABR Procedures" with egress ABR replaced with ingress ABR, backbone 1060 area replaced with ingress area and backbone area segment replaced 1061 with ingress area segment. 1063 In order to support global table multicast the ingress ABR MUST be 1064 auto-configured with an import Route Target whose global 1065 administrator field is set to the AS of the ABR and the local 1066 administrator field is set to 0. 1068 8.1. P2MP LSP as the Intra-Area LSP in the Backbone Area 1070 The procedures for binding the backbone area segment of an inter-area 1071 P2MP LSP to the intra-area P2MP LSP in the backbone area are the same 1072 as in section "Egress ABR Procedures" and sub-section "P2MP LSP as 1073 the Intra-Area LSP in the Egress Area", with the egress ABR replaced 1074 by the ingress ABR. This applies to the inter-area P2MP LSPs 1075 associated with either MVPN, or VPLS, or global table multicast. 1077 It is to be noted that in the case of global table multicast, if the 1078 backbone area uses wildcard S-PMSI, then the egress area also must 1079 use wildcard S-PMSI for global table multicast, or the ABRs must 1080 merge the wildcard S-PMSI onto the egress area (S, G) or (*, G) S- 1081 PMSI. The procedures for such merge require IP processing on the 1082 ABRs. 1084 8.2. Ingress Replication in the Backbone Area 1086 When Ingress Replication is used to instantiate the backbone area 1087 segment then the Leaf auto-discovery route advertised by the egress 1088 ABR MUST carry a downstream assigned label in the P-Tunnel Attribute 1089 where the P-Tunnel type is set to Ingress Replication. We will call 1090 this the egress ABR downstream assigned label. The egress ABR MUST 1091 assign a distinct MPLS label for each Leaf auto-discovery route 1092 originated by the ABR. 1094 The ingress ABR MUST forward packets received from the ingress area 1095 intra-area segment, for a particular inter-area P2MP LSP, to all the 1096 egress ABRs from which the ingress ABR has imported a Leaf auto- 1097 discovery route for the inter-area P2MP LSP. A packet to a particular 1098 egress ABR is encapsulated, by the inress ABR, using a MPLS label 1099 stack the bottom label of which is the egress ABR downstream assigned 1100 label. The top label is the P2P RSVP-TE or the MP2P LDP label to 1101 reach the egress ABR. 1103 9. Ingress PE/ASBR Procedures 1105 This section describes Ingress PE/ASBR procedures for constructing 1106 segmented inter-area P2MP LSP. 1108 When an ingress PE/ASBR receives a Leaf auto-discovery route and the 1109 Route Target extended community carried by the route contains the IP 1110 address of this PE/ASBR, then the following procedures will be 1111 executed. 1113 If the RD of the received auto-discovery route is not set to all 0s 1114 or all 1s, then the egress ABR MUST find a S-PMSI or I-PMSI route 1115 whose NLRI has the same value as the Route Key field of the received 1116 Leaf auto-discovery route. If such a matching route is found then the 1117 Leaf auto-discovery route MUST be accepted else it MUST be discarded. 1118 If the Leaf auto-discovery route is accepted then it MUST be 1119 processed as per MVPN or VPLS procedures. 1121 If the RD of the received auto-discovery route is set to all 0s or 1122 all 1s then the received Leaf auto-discovery route is for the global 1123 table multicast service. In that case for the following procedure the 1124 Route Prefix is set to all fields of the Route Key minus the Ingress 1125 PE address. If this is the first Leaf auto-discovery route update for 1126 this Route Prefix or the withdrawl of the last Leaf auto-discovery 1127 route for the Route Prefix then the following procedures will be 1128 executed. The information carried in the MCAST-VPN NLRI of the route 1129 MUST be decoded. The PIM implementation should set its upstream 1130 (S/RP,G) state machine in Joined state for the (S/RP, G) received via 1131 a Leaf auto-discovery route update. Likewise, the PIM implementation 1132 should set its upstream (S/RP, G) state machine in Pruned state for 1133 the (S/RP, G) received via a Leaf auto-discovery route withdrawl. 1135 9.1. P2MP LSP as the intra-area LSP in the ingress area 1137 If the RD of the received Leaf auto-discovery route is not all 0s or 1138 all 1s, and P2MP LSP is used as the the intra-area LSP in the ingress 1139 area, then the procedures for binding the ingress area segment of the 1140 inter-area P2MP LSP to the intra-area P2MP LSP in the ingress area, 1141 are the same as in section "Egress ABR Procedures" and sub-section 1142 "P2MP LSP as the Intra-Area LSP in the Egress Area". 1144 When the RD of the received Leaf auto-discovery route is all 0s or 1145 all 1s, as is the case where the inter-area service P2MP LSP is 1146 associated with the global table multicast service, then the ingress 1147 PE may originate a S-PMSI route with the RD, multicast source, 1148 multicast group fields being the same as those in the received Leaf 1149 auto-discovery route. 1151 Further an ingress PE may originate a wildcard S-PMSI route as per 1152 the procedures in [MVPN-WILDCARD-SPMSI] with the RD set to 0. This 1153 route may be originated by the ingress PE based on configuration or 1154 based on the import of a Leaf auto-discovery route with RD set to 0. 1155 If an ingress PE originates such a route, then the ingress PE may 1156 decide not to originate (S, G) or (*, G) S-PMSI routes. 1158 It is to be noted that if ingress area uses wildcard S-PMSI then the 1159 backbone area also must use wildcard S-PMSI for global table 1160 multicast, or the ABRs must merge the wildcard S-PMSI onto the 1161 backbone area (S, G) or (*, G) S-PMSI. The procedures for such merge 1162 require IP processing on the ABRs. 1164 9.2. Ingress Replication in the Ingress Area 1166 When Ingress Replication is used to instantiate the ingress area 1167 segment then the Leaf auto-discovery route advertised by the ingress 1168 ABR MUST carry a downstream assigned label in the P-Tunnel Attribute 1169 where the P-Tunnel type is set to Ingress Replication. We will call 1170 this the ingress ABR downstream assigned label. The ingress ABR MUST 1171 assign a distinct MPLS label for each Leaf auto-discovery route 1172 originated by the ABR. 1174 The ingress PE/ASBR MUST forward packets received from the CE, for a 1175 particular inter-area P2MP LSP, to all the ingress ABRs from which 1176 the ingress PE/ASBR has imported a Leaf auto-discovery route for the 1177 inter-area P2MP LSP. A packet to a particular ingress ABR is 1178 encapsulated, by the ingress PE/ASBR, using a MPLS label stack the 1179 bottom label of which is the ingress ABR downstream assigned label. 1180 The top label is the P2P RSVP-TE or the MP2P LDP label to reach the 1181 ingress ABR. 1183 10. Common Tunnel Type in the Ingress and Egress Areas 1185 For a given inter-area service P2MP LSP, the PE/ASBR that is the root 1186 of that LSP controls the tunnel type of the intra-area P-tunnel that 1187 carries the ingress area segment of that LSP. However, the tunnel 1188 type of the intra-area P-tunnel that carries the backbone area 1189 segment of that LSP may be different from the tunnel type of the 1190 intra-area P-tunnels that carry the ingress area segment and the 1191 egress area segment of that LSP. In that situation if for a given 1192 inter-area P2MP LSP it is desirable/necessary to use the same tunnel 1193 type for the intra-area P-tunnels that carry the ingress area segment 1194 and the egress area segment of that LSP, then the following 1195 procedures on the ingress ABR and egress ABR provide this 1196 functionality. 1198 When an ingress ABR re-advertises into the backbone area a BGP MVPN 1199 I-PMSI, or S-PMSI auto-discovery route, or VPLS auto-discovery route, 1200 the ingress ABR places the PMSI Tunnel attribute of this route into 1201 the ATTR_SET BGP Attribute [L3VPN-IBGP], adds this attribute to the 1202 re-advertised route, and then replaces the original PMSI Tunnel 1203 attribute with a new one (note, that the Tunnel type of the new 1204 attribute may be different from the Tunnel type of the original 1205 attribute). 1207 When an egress ABR re-advertises into the egress area a BGP MVPN I- 1208 PMSI or S-PMSI auto-discovery route, or VPLS auto-discovery route, if 1209 the route carries the ATTR_SET BGP attribute [L3VPN-IBGP], then the 1210 ABR sets the Tunnel type of the PMSI Tunnel attribute in the re- 1211 advertised route to the Tunnel type of the PMSI Tunnel attribute 1212 carried in the ATTR_SET BGP attribute, and removes the ATTR_SET from 1213 the route. 1215 11. Placement of Ingress and Egress PEs 1217 As described in the earlier sections, procedures in this document 1218 allow the placement of ingress and egress PEs in the backbone area. 1219 They also allow the placement of egress PEs in the ingress area or 1220 the placement of ingress PEs in the egress area. 1222 For instance, ABRs in the backbone area may act as ingress and egress 1223 PEs for global table multicast, as per the ingress and egress PE 1224 definition in this document. This may be the case if the service is 1225 global table multicast and relies on global table multicast in the 1226 ingress and egress areas and its desirable to carry global table 1227 multicast over MPLS in the backbone area. This may also be the case 1228 if the service is MVPN and the P-tunnel technology in the ingress and 1229 egress areas uses PIM based IP/GRE P-tunnels. As far as the ABRs are 1230 concerned PIM signaling for such P-Tunnels is handled as per the 1231 ingress/egress PE global table multicast procedures specified in this 1232 document. To facilitate this the ABRs may advertise their loopback 1233 addresses in BGP using multicast-SAFI i.e., SAFI 2, if non-congruence 1234 between unicast and multicast is desired. 1236 12. Data Plane 1238 This section describes the data plane procedures on the ABRs, ingress 1239 PEs, egress PEs and transit routers. 1241 12.1. Data Plane Procedures on an ABR 1243 When procedures in this document are followed to signal inter-area 1244 P2MP Segmented LSPs, then ABRs are required to perform only MPLS 1245 switching. When an ABR receives a MPLS packet from an "incoming" 1246 intra-area segment of the inter-area P2MP Segmented LSP, it forwards 1247 the packet, based on MPLS switching, onto another "outgoing" intra- 1248 area segment of the inter-area P2MP Segmented LSP. 1250 If the outgoing intra-area segment is instantiated using a P2MP LSP, 1251 and if there is a one-to-one mapping between the outgoing intra-area 1252 segment and the P2MP LSP, then the ABR MUST pop the incoming 1253 segment's label stack and push the label stack of the outgoing P2MP 1254 LSP. If there is a many-to-one mapping between outgoing intra-area 1255 segments and the P2MP LSP then the ABR MUST pop the incoming 1256 segment's label stack and first push the upstream assigned label 1257 corresponding to the outgoing intra-area segment, if such a label has 1258 been assigned, and then push the label stack of the outgoing P2MP 1259 LSP. 1261 If the outgoing intra-area segment is instantiated using ingress 1262 replication then the ABR must pop the incoming segment's label stack 1263 and replicate the packet once to each leaf ABR or PE of the outgoing 1264 intra-area segment. The label stack of the packet sent to each such 1265 leaf MUST first include a downstream assigned label assigned by the 1266 leaf to the segment, followed by the label stack of the P2P or MP2P 1267 LSP to the leaf. 1269 12.2. Data Plane Procedures on an Egress PE 1271 An egress PE must first identify the inter-area P2MP segmented LSP 1272 based on the incoming label stack. After this identification the 1273 egress PE must forward the packet using the application that is bound 1274 to the inter-area P2MP segmented LSP. 1276 Note that the application specific forwarding for MVPN service may 1277 require the egress PE to determine whether the packets were received 1278 from the expected sender PE. When the application is MVPN then the 1279 FEC of an inter-area P2MP Segmented LSP is at the granularity of the 1280 sender PE. Note that MVPN intra-AS I-PMSI auto-discovery routes and 1281 S-PMSI auto-discovery routes both carry the Originating Router IP 1282 Address. Thus an egress PE could associate the data arriving on P- 1283 tunnels advertised by these routes with the Originating Router IP 1284 Address carried by these routes which is the same as the ingress PE. 1285 Since a unique label stack is associated with each such FEC, the 1286 egress PE can determine the sender PE from the label stack. 1288 Likewise for VPLS service for the purposes of MAC learning the egress 1289 PE must be able to determine the "VE-ID" from which the packets have 1290 been received. The FEC of the VPLS auto-discovery routes carries the 1291 VE-ID. Thus an egress PE could associate the data arriving on P- 1292 tunnels advertised by these routes with the VE-ID carried by these 1293 routes. Since a unique label stack is associated with each such FEC, 1294 the egress PE can perform MAC learning for packets received from a 1295 given VE-ID. 1297 When the application is global table multicast it is sufficient for 1298 the label stack to include identification of the sender upstream 1299 node. When P2MP LSPs are used this requires that PHP MUST be turned 1300 off. When Ingress Replication is used the egress PE knows the 1301 incoming downstream assigned label to which it has bound a particular 1302 (S/*, G) and must accept packets with only that label for that (S/*, 1303 G). 1305 12.3. Data Plane Procedures on an Ingress PE 1307 The Ingress PE must perform application specific forwarding 1308 procedures to identify the outgoing inta-area segment of an incoming 1309 packet. 1311 If the outgoing intra-area segment is instantiated using a P2MP LSP, 1312 and if there is a one-to-one mapping between the outgoing intra-area 1313 segment and the P2MP LSP, then the ingress PE MUST encapsulate the 1314 packet in the label stack of the outgoing P2MP LSP. If there is a 1315 many-to-one mapping between outgoing intra-area segments and the P2MP 1316 LSP then the PE MUST first push the upstream assigned label 1317 corresponding to the outgoing intra-area segment, if such a label has 1318 been assigned, and then push the label stack of the outgoing P2MP 1319 LSP. 1321 If the outgoing intra-area segment is instantiated using ingress 1322 replication then the PE must replicate the packet once to each leaf 1323 ABR or PE of the outgoing intra-area segment. The label stack of the 1324 packet sent to each such leaf MUST first include a downstream 1325 assigned label assigned by the leaf to the segment, followed by the 1326 label stack of the P2P or MP2P LSP to the leaf. 1328 12.4. Data Plane Procedures on Transit Routers 1330 When procedures in this document are followed to signal inter-area 1331 P2MP Segmented LSPs then tansit routers in each area perform only 1332 MPLS switching. 1334 13. Support for Inter-Area Transport LSPs 1336 This section describes OPTIONAL procedures that allow to aggregate 1337 multiple (inter-area) P2MP service LSPs into a single inter-area P2MP 1338 transport LSPs, and then apply the segmentation procedures, as 1339 specified in this document, to these inter-area P2MP transport LSPs 1340 (rather than applying these procedures directly to the inter-area 1341 P2MP service LSPs). 1343 13.1. Transport Tunnel Tunnel Type 1345 For the PMSI Tunnel Attribute we define a new Tunnel type, called 1346 "Transport Tunnel", whose Tunnel Identifier is a tuple . This Tunnel type is assigned a value of 8. 1348 The Source PE Address is the address of the PE that originates the 1349 (service) auto-discovery route that carries this attribute, and the 1350 Local Number is a number that is unique to the Source PE. The length 1351 of the Local Number part is the same as the length of the Source PE 1352 Address. Thus if the Source PE Address is an IPv4 address, then the 1353 Local Number part is 4 octets, and if the Source PE Address is an 1354 IPv6 address, then the Local Number part is 16 octets. 1356 13.2. Discovering Leaves of the Inter-Area P2MP Service LSP 1358 When aggregating multiple P2MP LSPs using P2MP LSP hierarchy, 1359 determining the leaf nodes of the LSPs being aggregated is essential 1360 for being able to tradeoff the overhead due to the P2MP LSPs vs 1361 suboptimal use of bandwidth due to the partial congruency of the LSPs 1362 being aggregated. 1364 Therefore, if a PE that is a root of a given service P2MP LSP wants 1365 to aggregate this LSP with other (service) P2MP LSPs rooted at the 1366 same PE into an inter-area P2MP transport LSP, the PE should first 1367 determine all the leaf nodes of that service LSP, as well as those of 1368 the other service LSPs being aggregated). 1370 To accomplish this the PE sets the PMSI Tunnel attribute of the 1371 service auto-discovery route associated with that LSP as follows. 1372 The Tunnel Type is set to "No tunnel information present", Leaf 1373 Information Required flag is set to 1, the route MUST NOT carry the 1374 P2MP Segmented Next-Hop extended community. In contrast to the 1375 procedures for the MVPN and VPLS auto-discovery routes described so 1376 far, the Route Reflectors that participate in the distribution of 1377 this route need not be ABRs 1379 13.3. Discovering the P2MP FEC of the Inter-Area P2MP Transport LSP 1381 Once the root PE determines all the leaves of a given P2MP service 1382 LSP, the PE (using some local to the PE criteria) selects a 1383 particular inter-area transport P2MP LSP to be used for carrying the 1384 (inter-area) service P2MP LSP. 1386 Once the PE selects the transport P2MP LSP, the PE (re)originates the 1387 service auto-discovery route. The PMSI Tunnel attribute of this route 1388 now carries the Transport Tunnel ID of the selected transport tunnel, 1389 with the Tunnel Type set to "Transport Tunnel". Just as described 1390 earlier, this service auto-discovery route MUST NOT carry the P2MP 1391 Segmented Next-Hop extended community. Just as described earlier, the 1392 Route Reflectors that participate in the distribution of this route 1393 need not be ABRs. 1395 13.4. Egress PE Procedures for Inter-Area P2MP Transport LSP 1397 When an egress PE receives and accepts an MVPN or VPLS service auto- 1398 discovery route, if the Leaf Information Required flag in the PMSI 1399 Tunnel attribute of the received auto-discovery route is set to 1, 1400 and the route does not carry the P2MP Segmented Next-Hop extended 1401 community, then the egress PE following the "regular" MVPN or VPLS 1402 procedures, as specified in [MVPN-BGP] and [VPLS-P2MP], associated 1403 with the received auto-discovery route originates a Leaf auto- 1404 discovery route. 1406 In addition, if the Tunnel Type in the PMSI Tunnel attribute of the 1407 received service auto-discovery route is set to "Transport Tunnel", 1408 the egress PE originates yet another Leaf auto-discovery route. 1410 The format of the Route Key field of MCAST-VPN NLRI of this 1411 additional Leaf auto-discovery route is the same as defined in 1412 Section "Leaf Auto-Discovery Route for Global Table Multicast". The 1413 Route Key field of MCAST-VPN NLRI of this route is constructed as 1414 follows: 1416 RD (8 octets) - set to 0 1418 Multicast Source Length, Multicast Source - constructed from 1419 the Source PE address part of the Tunnel Identifier carried 1420 in the received S-PMSI auto-discovery route. 1422 Multicast Group Length, Multicast Group - constructed from 1423 Local Number part of the Tunnel Identifier carried in the 1424 received S-PMSI auto-discovery route. 1426 Ingress PE IP Address is set to the Source PE address part 1427 of the Tunnel Identifier carried in the received S-PMSI 1428 auto-discovery route. 1430 The egress PE, when determining the upstream ABR, follows the 1431 procedures specified in Section 6.1 for global table multicast. 1433 From that point on we follow the procedures used for the Leaf auto- 1434 discovery routes for global table multicast, as outlined below. 1436 13.5. Egress ABR, Ingress ABR, Ingress PE procedures for Inter-Area 1438 Transport LSP" 1440 When an egress ABR receives the Leaf auto-discovery route, the egress 1441 ABR will advertise into the egress area an S-PMSI auto-discovery 1442 route whose NLRI is the same as the received Leaf auto-discovery 1443 route, minus the Ingress PE IP address. The PMSI Tunnel attribute of 1444 this route contains the identity of a particular intra-area P2MP LSP 1445 and an upstream-assigned MPLS label. The egress PE(s) will import 1446 this route. 1448 The egress ABR will also propagate, with appropriate modifications, 1449 the received Leaf auto-discovery route into the backbone area. 1451 Likewise, an ingress ABR will advertise into the backbone area an S- 1452 PMSI auto-discovery route whose NLRI is the same as the received Leaf 1453 auto-discovery route, minus the Ingress PE IP address. The egress 1454 ABR(s) will import this route. 1456 The ingress ABR will also propagate, with appropriate modifications, 1457 the received Leaf auto-discovery route into the ingress area. 1459 Finally the ingress PE will advertise into the ingress area an S-PMSI 1460 auto-discovery route whose NLRI is the same as the received Leaf 1461 auto-discovery route, minus the Ingress PE IP address. The ingress 1462 ABR(s) and other PE(s) in the ingress area, if any, will import this 1463 route. The ingress PE will use the (intra-area) P2MP LSP advertised 1464 in this route for carrying traffic associated with the original 1465 service auto-discovery route advertised by the PE. 1467 13.6. Discussion 1469 Use of inter-area transport P2MP LSPs, as described in this section, 1470 creates a level of indirection between (inter-area) P2MP service 1471 LSPs, and intra-area transport LSPs that carry the service LSPs. 1472 Rather than segmenting (inter-area) service P2MP LSPs, and then 1473 aggregating (intra-area) segments of these service LSPs into intra- 1474 area transport LSPs, this approach first aggregates multiple (inter- 1475 area) service P2MP LSPs into a single inter-area transport P2MP LSP, 1476 then segments such inter-area transport P2MP LSPs, and then 1477 aggregates (intra-area) segments of these inter-area transport LSPs 1478 into intra-area transport LSPs. 1480 On one hand this approach could result in reducing the state (and the 1481 overhead associated with maintaining the state) on ABRs. This is 1482 because instead of requiring ABRs to maintain state for individual 1483 P2MP service LSPs, ABRs would need to maintain state only for the 1484 inter-area P2MP transport LSPs. Note however, that this reduction is 1485 possible only if a single inter-area P2MP transport LSP aggregates 1486 more than one (inter-area) service LSP. In the absence of such 1487 aggregation, use of inter-area transport LSPs provides no benefits, 1488 yet results in extra overhead. And while such aggregation does allow 1489 to reduce state on ABRs, it comes at a price, as described below. 1491 As we mentioned before, aggregating multiple P2MP service LSPs into a 1492 single inter-area P2MP transport LSP requires the PE rooted at these 1493 LSPs to determine all the leaf nodes of the service LSPs to be 1494 aggregated. This means that the root PE has to track all the leaf PEs 1495 of these LSPs. In contrast, when one applies segmentation procedures 1496 directly to the P2MP service LSPs, the root PE has to track only the 1497 leaf PEs in its own IGP area, plus the ingress ABR(s). Likewise, an 1498 ingress ABR has to track only the egress ABRs. Finally, an egress ABR 1499 has to track only the leaf PEs in its own area. Therefore, while the 1500 total overhead of leaf tracking due to the P2MP service LSPs is about 1501 the same in both approaches, the distribution of this overhead is 1502 different. Specifically, when one uses inter-area P2MP transport 1503 LSPs, this overhead is concentrated on the ingress PE. When one 1504 applies segmentation procedures directly to the P2MP service LSPs, 1505 this overhead is distributed among ingress PE and ABRs. 1507 Moreover, when one uses inter-area P2MP transport LSPs, ABRs have to 1508 bear the overhead of leaf tracking for inter-area P2MP transport 1509 LSPs. In contrast, when one applies segmentation procedures directly 1510 to the P2MP service LSPs, there is no such overhead (as there are no 1511 inter-area P2MP transport LSPs). 1513 Use of inter-area P2MP transport LSPs may also result in more 1514 bandwidth inefficiency, as compared to applying segmentation 1515 procedures directly to the P2MP service LSPs. This is because with 1516 inter-area P2MP transport LSPs the ABRs aggregate segments of inter- 1517 area P2MP transport LSPs, rather than segments of (inter-area) P2MP 1518 service LSPs. To illustrate this consider the following example. 1520 Assume PE1 in Area 1 is an ingress PE, with two multicast streams, 1521 (C-S1, C-G1) and (C-S2, C-G2), originated by an MVPN site connected 1522 to PE1. Assume that PE2 in Area 2 has an MVPN site with receivers 1523 for (C-S1, C-G1), PE3 and PE4 in Area 3 have an MVPN site with 1524 receivers both for (C-S1, C-G1) and for (C-S2, C-G2). Finally, assume 1525 that PE5 in Area 4 has an MVPN site with receivers for (C-S2, C-G2). 1527 When segmentation applies directly to the P2MP service LSPs then Area 1528 2 would have just one intra-area transport LSP which would carry the 1529 egress area segment of the P2MP service LSP for (C-S1, C-G1); Area 3 1530 would have just one intra-area transport LSP which would carry the 1531 egress area segments of both the P2MP service LSP for (C-S1, C-G1) 1532 and the P2MP service LSP for (C-S2, C-G2); Area 4 would have just one 1533 intra-area transport LSP which would carry the egress area segment of 1534 the P2MP service LSP for (C-S2, C-G2). Note that there is no 1535 bandwidth inefficiency in this case at all. 1537 When using inter-area P2MP transport LSPs, to achieve the same state 1538 overhead on the routers within each of the egress areas (except for 1539 egress ABRs), PE1 would need to aggregate the P2MP service LSP for 1540 (C-S1, C-G1) and the P2MP service LSP for (C-S2, C-G2) into the same 1541 inter-area P2MP transport LSP. While such aggregation would reduce 1542 state on ABRs, it would also result in bandwidth inefficiency, as (C- 1543 S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but also 1544 to PE5, which has no receivers for this stream. Likewise, (C-S2, C- 1545 G2) will be delivered not just to PE3, PE4, and PE5, but also to PE2, 1546 which has no receivers for this stream. 1548 14. IANA Considerations 1550 This document defines a new BGP Extended Community called "Inter-area 1551 P2MP Segmented Next-Hop". This community is IP Address Specific, of 1552 an extended type, and is transitive. A codepoint for this community 1553 should be assigned both from the IPv4 Address Specific Extended 1554 Community registry, and from the IPv6 Address Specific Extended 1555 Community registry. The same code point should be assigned from both 1556 registries. 1558 This document also assigns a new Tunnel Type in the PMSI Tunnel 1559 Attribute, called the "Transport Tunnel". This Tunnel Type is 1560 assigned a value of 8. 1562 15. Security Considerations 1564 These will be spelled out in a future revision. 1566 16. Acknowledgements 1568 We would like to thank Eric Rosen for his comments. 1570 17. References 1572 17.1. Normative References 1574 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332 1576 [RFC2119] "Key words for use in RFCs to Indicate Requirement 1577 Levels.", Bradner, March 1997 1579 [RFC4684] P. Marques et. al., "Constrained Route Distribution for 1580 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 1581 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 1582 November 2006 1584 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 1585 VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, draft-ietf- 1586 l3vpn-2547bis-mcast-bgp 1588 [[VPLS-P2MP] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang, 1589 draft-ietf-l2vpn-vpls-mcast 1591 [L3VPN-IBGP] "Internal BGP as PE-CE protocol", Pedro Marques, et al., 1592 draft-ietf-l3vpn-ibgp, work in progress 1594 [MVPN-WILDCARD-SPMSI] "Wildcards in Multicast VPN Auto-Discovery 1595 Routes", Eric Rosen, et al., draft-ietf-l3vpn-mvpn-wildcards, work in 1596 progress 1598 [BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 1599 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 1601 17.2. Informative References 1603 [SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al., 1604 draft-ietf-mpls-seamless-mpls 1606 18. Author's Address 1608 Yakov Rekhter 1609 Juniper Networks 1610 1194 North Mathilda Ave. 1611 Sunnyvale, CA 94089 1612 Email: yakov@juniper.net 1614 Rahul Aggarwal 1615 Email: raggarwa_1@yahoo.com 1617 Thomas Morin 1618 France Telecom R & D 1619 2, avenue Pierre-Marzin 1620 22307 Lannion Cedex 1621 France 1622 Email: thomas.morin@orange-ftgroup.com 1624 Irene Grosclaude 1625 France Telecom R & D 1626 2, avenue Pierre-Marzin 1627 22307 Lannion Cedex 1628 France 1629 Email: irene.grosclaude@orange-ftgroup.com 1631 Nicolai Leymann 1632 Deutsche Telekom AG 1633 Winterfeldtstrasse 21 1634 Berlin 10781 1635 DE 1636 Email: n.leymann@telekom.de 1638 Samir Saad 1639 AT&T 1640 Email: ss2539@att.com