idnits 2.17.1 draft-ietf-mpls-seamless-mcast-08.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 3 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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: 'RFC 5332' is mentioned on line 999, but not defined == Unused Reference: 'RFC5332' is defined on line 1738, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 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: May 2014 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 November 11 2013 21 Inter-Area P2MP Segmented LSPs 23 draft-ietf-mpls-seamless-mcast-08.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 84 multicast, or global table 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 . 7 92 5 Discovering P2MP FEC of Inter-Area P2MP Service LSP ... 7 93 5.1 BGP MVPN .............................................. 8 94 5.2 BGP VPLS or LDP VPLS with BGP auto-discovery .......... 9 95 5.3 Global Table Multicast over MPLS ...................... 11 96 6 Egress PE/ASBR Procedures ............................. 11 97 6.1 Determining the Upstream ABR/PE/ASBR (Upstream Node) .. 12 98 6.1.1 Upstream Node for MVPN or VPLS ........................ 12 99 6.1.2 Upstream Node for Global Table Multicast .............. 12 100 6.2 Originating a Leaf A-D Route .......................... 13 101 6.2.1 Leaf A-D Route for MVPN and VPLS ...................... 14 102 6.2.2 Leaf A-D Route for Global Table Multicast ............. 14 103 6.2.3 Constructing the Rest of the Leaf A-D Route ........... 16 104 6.3 PIM-SM in ASM mode for Global Table Multicast ......... 16 105 6.3.1 Option 1 .............................................. 17 106 6.3.1.1 Originating Source Active A-D Routes .................. 17 107 6.3.1.2 Receiving BGP Source Active A-D Route by PE ........... 17 108 6.3.1.3 Handling (S, G, RPTbit) state ......................... 18 109 6.3.2 Option 2 .............................................. 18 110 6.3.2.1 Originating Source Active A-D Routes .................. 18 111 6.3.2.2 Receiving BGP Source Active A-D Route ................. 19 112 6.3.2.3 Pruning Sources off the Shared Tree ................... 19 113 6.3.2.4 More on handling (S, G, RPTbit) state ................. 20 114 7 Egress ABR Procedures ................................. 20 115 7.1 Handling Leaf A-D route on Egress ABR ................. 20 116 7.2 P2MP LSP as the Intra-Area LSP in the Egress Area ..... 22 117 7.2.1 Received Leaf A-D route is for MVPN or VPLS ........... 22 118 7.2.2 Received Leaf A-D route is for global table multicast . 23 119 7.2.2.1 Global Table Multicast and S-PMSI A-D Routes .......... 23 120 7.2.2.2 Global Table Multicast and Wildcard S-PMSI A-D Routes . 24 121 7.2.3 Global Table Multicast and the Expected Upstream Node . 25 122 7.2.4 P2MP LDP LSP as the Intra-Area P2MP LSP ............... 25 123 7.2.5 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP ........... 25 124 7.3 Ingress Replication in the Egress Area ................ 26 125 8 Ingress ABR Procedures ................................ 26 126 8.1 P2MP LSP as the Intra-Area LSP in the Backbone Area ... 26 127 8.2 Ingress Replication in the Backbone Area .............. 27 128 9 Ingress PE/ASBR Procedures ............................ 27 129 9.1 P2MP LSP as the Intra-Area LSP in the Ingress Area .... 28 130 9.2 Ingress Replication in the Ingress Area ............... 29 131 10 Common Tunnel Type in the Ingress and Egress Areas .... 29 132 11 Placement of Ingress and Egress PEs ................... 30 133 12 MVPN with Virtual Hub-and-Spoke ....................... 30 134 13 Data Plane ............................................ 31 135 13.1 Data Plane Procedures on ABRs ......................... 31 136 13.2 Data Plane Procedures on Egress PEs ................... 31 137 13.3 Data Plane Procedures on Ingress PEs .................. 32 138 13.4 Data Plane Procedures on Transit Routers .............. 33 139 14 Support for Inter-Area Transport LSPs ................. 33 140 14.1 Transport Tunnel Tunnel Type .......................... 33 141 14.2 Discovering Leaves of the Inter-Area P2MP Service LSP . 33 142 14.3 Discovering P2MP FEC of P2MP Transport LSP ............ 34 143 14.4 Egress PE Procedures for P2MP Transport LSP ........... 34 144 14.5 Egress/Ingress ABR, Ingress PE procedures for P2MP Transport LSP 35 145 14.6 Discussion ............................................ 36 146 15 IANA Considerations ................................... 38 147 16 Security Considerations ............................... 38 148 17 Acknowledgements ...................................... 38 149 18 References ............................................ 38 150 18.1 Normative References .................................. 38 151 18.2 Informative References ................................ 39 152 19 Author's Address ...................................... 40 154 1. Specification of requirements 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 2. Introduction 162 This document describes procedures for building inter-area point-to- 163 multipoint (P2MP) segmented service LSPs by partitioning such LSPs 164 into intra-area segments and using BGP as the inter-area routing and 165 label distribution protocol. Within each IGP area the intra-area 166 segments are either carried over intra-area P2MP LSPs, potentially 167 using P2MP LSP hierarchy, or instantiated using ingress replication. 168 The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP 169 mLDP. If ingress replication is used in an IGP area then MP2P LDP or 170 P2P RSVP-TE LSPs may be used within the IGP area. The 171 applications/services that use such inter-area service LSPs may be 172 BGP MVPN, VPLS multicast, or global table multicast over MPLS. 174 The primary use case of such segmented P2MP service LSPs is when the 175 PEs are in different areas but in the same AS and thousands or more 176 of PEs require P2MP connectivity. For instance this may be the case 177 when MPLS is pushed further to the metro edge and the metros are in 178 different IGP areas. This may also be the case when a Service 179 Provider's network comprises multiple IGP areas in a single 180 Autonomous System, with a large number of PEs. Seamless MPLS is the 181 industry term to address this case [SEAMLESS-MPLS]. Thus one of the 182 applicabilities of this document is that it describes the multicast 183 procedures for seamless MPLS. 185 It is to be noted that [RFC6514], [VPLS-P2MP] already specify 186 procedures for building segmented inter-AS P2MP service LSPs. This 187 document complements those procedures, as it extends the segmented 188 P2MP LSP model such that it is applicable to inter-area P2MP service 189 LSPs as well. Infact an inter-AS deployment could use inter-AS 190 segmented P2MP LSPs as specified in [RFC6514, VPLS-P2MP] where each 191 intra-AS segment is constructed using inter-area segmented P2MP LSPs 192 as specified in this document. 194 3. General Assumptions and Terminology 196 This document allows ABRs, acting as Route Reflectors, to follow the 197 procedures specified in [SEAMLESS-MPLS] when handling BGP Next-Hop of 198 the routes to the PEs. Specifically, when reflecting such routes from 199 the non-backbone areas into the backbone area, the ABRs MUST set BGP 200 Next-Hop to their own loopback addresses (next-hop-self), while when 201 reflecting such routes from the backbone area into the non-backbone 202 areas, the ABRs SHOULD NOT change the BGP Next-Hop addresses (next- 203 hop-unchanged). 205 While this document allows ABRs to follow the procedures specified in 206 [SEAMLESS-MPLS], procedures specified in this document are applicable 207 even when ABRs do not follow the procedures specified in [SEAMLESS- 208 MPLS]. 210 One possible way to support the global table multicast service is by 211 relying on the MVPN procedures, as specified in [RFC6514], in which 212 case the MVPN procedures specified in this document would be used to 213 support the global table multicast service. This document specifies 214 an alternative approach to support the global table multicast 215 service. This document refers to this approach as "global table 216 multicast" (although this by no means imply that this alternative 217 approach is the only way to support the global table multicast 218 service). 220 This document assumes that in the context of global table multicast 221 ABRs do not carry routes to the destinations external to their own 222 AS. Furthermore, in the context of global table multicast this 223 document assumes that an ASBR, when re-advertising into IBGP routes 224 received from an external speaker (received via EBGP) may not change 225 BGP Next-Hop to self. 227 Within an AS a P2MP service LSP is partitioned into 3 segments: 228 ingress area segment, backbone area segment, and egress area segment. 229 Within each area a segment is carried over an intra-area P2MP LSP or 230 instantiated using ingress replication. 232 When intra-area P2MP LSPs are used to instantiate the intra-area 233 segments there could be either 1:1 or n:1 mapping between intra-area 234 segments of the inter-area P2MP service LSP and a given intra-area 235 P2MP LSP. The latter is realized using P2MP LSP hierarchy with 236 upstream-assigned labels [RFC5331]. For simplicity of presentation we 237 assume that P2MP LSP hierarchy is used even with 1:1 mapping, in 238 which case the upstream-assigned label SHOULD be an Implicit NULL. 240 When intra-area segments of the inter-area P2MP service LSP are 241 instantiated using ingress replication, then multiple such segments 242 may be carried in the same P2P RSVP-TE or MP2P LDP LSP. This can be 243 achieved using downstream-assigned labels alone. 245 The ingress area segment of a P2MP service LSP is rooted at a PE (or 246 at an ASBR in the case where the P2MP service LSP spans multiple 247 ASes). The leaves of this segment are other PEs/ASBRs and ABRs in the 248 same area as the root PE. 250 The backbone area segment is rooted at an ABR that is connected to 251 the ingress area (ingress ABR), or at an ASBR if the ASBR is present 252 in the backbone area, or at a PE if the PE is present in the backbone 253 area. The backbone area segment has as its leaves ABRs that are 254 connected to the egress area(s) or PEs in the backbone area, or ASBRs 255 in the backbone area. 257 The egress area segment is rooted at an ABR in the egress area 258 (egress ABR), and has as its leaves PEs and ASBR in that egress area 259 (the latter covers the case where the P2MP service LSP spans multiple 260 ASes). Note that for a given P2MP service LSP there may be more than 261 one backbone segment, each rooted at its own ingress ABR, and more 262 than one egress area segment, each rooted at its own egress ABR. 264 This document uses the term "A-D routes" for "auto-discovery routes". 266 An implementation that supports this document MUST implement the 267 procedures described in the following sections to support inter-area 268 point-to-multipoint (P2MP) segmented service LSPs. 270 4. Inter-area P2MP Segmented Next-Hop Extended Community 272 This document defines a new BGP Extended Community "Inter-area P2MP 273 Next-Hop" Extended Community. This is an IP-address specific Extended 274 Community of an extended type and is transitive across AS boundaries 275 [RFC4360]. 277 A PE or an ABR or an ASBR constructs the Inter-area P2MP Segmented 278 Next-Hop Extended Community as follows: 280 - The Global Administrator field MUST be set to an IP address of 281 the PE or ASBR or ABR that originates or advertises the route, 282 which carries the P2MP Next-Hop Extended Community. For example 283 this address may be the loopback address or the PE, ASBR or ABR 284 that advertises the route. 286 - The Local Administrator field MUST be set to 0. 288 The detailed usage of this Extended Community is described in the 289 following sections. 291 5. Discovering P2MP FEC of Inter-Area P2MP Service LSP 293 Each inter-area P2MP service LSP has associated with it P2MP FEC. 294 The egress PEs need to learn this P2MP FEC in order to initiate the 295 creation of the egress area segment of the P2MP inter-area service 296 LSP. 298 The P2MP FEC of the inter-area P2MP LSP is learned by the egress PEs 299 either by configuration, or based on the application-specific 300 procedures (e.g., MVPN-specific procedures, VPLS-specific 301 procedures). 303 5.1. BGP MVPN 305 Egress PEs and/or ASBRs discover the P2MP FEC of the service LSPs 306 used by BGP MVPN using the I-PMSI or S-PMSI A-D routes that are 307 originated by the ingress PEs or ASBRs following the procedures of 308 [RFC6514], along with modifications as described in this document. 309 The NLRI of such routes encodes the P2MP FEC. 311 The procedures in this document require that at least one ABR in a 312 given IGP area acts as a Route Reflector for MVPN A-D routes. Such a 313 Router Reflector is responsible for re-advertising MVPN A-D routes 314 across area's boundaries. When re-advertising these routes across 315 area's boundaries, this Route Reflector MUST follow the procedures in 316 this document. Note that such a Route Reflector may also re-advertise 317 MVPN A-D routes within the same area, in which case it follows the 318 plain BGP Route Reflector procedures [RFC4456]. 320 The "Leaf Information Required" flag MUST be set in the P-Tunnel 321 attribute carried in such routes, when originated by the ingress PEs 322 or ASBRs, except for the case where (a) as a matter of policy 323 (provisioned on the ingress PEs or ASBRs) there is no aggregation of 324 ingress area segments of the service LSPs, and (b) mLDP is used as 325 the protocol to establish intra-area transport LSPs in the ingress 326 area. Before any Leaf A-D route is advertised by a PE or ABR in the 327 same area, as described in the following sections, an I-PMSI/S-PMSI 328 A-D route is advertised either with an explicit Tunnel Type and 329 Tunnel Identifier in the PMSI Tunnel Attribute, if the Tunnel 330 Identifier has already been assigned, or with a special Tunnel Type 331 of "No tunnel information present" otherwise. 333 When the I-PMSI/S-PMSI A-D routes are re-advertised by an ingress 334 ABR, the "Leaf Information Required" flag MUST be set in the P-Tunnel 335 attribute present in the routes, except for the case where (a) as a 336 matter of policy (provisioned on the ingress ABR) there is no 337 aggregation of backbone area segments of the service LSPs, and (b) 338 mLDP is used as the protocol to establish intra-area transport LSPs 339 in the backbone area. Likewise, when the I-PMSI/S-PMSI A-D routes are 340 re-advertised by an egress ABR, the "Leaf Information Required" flag 341 MUST be set in the P-Tunnel attribute present in the routes, except 342 for the case where (a) as a matter of policy (provisioned on the 343 egress ABR) there is no aggregation of egress area segments of the 344 service LSPs, and (b) mLDP is used as the protocol to establish 345 intra-area transport LSPs in the egress area. 347 Note that the procedures in the above paragraph apply when intra-area 348 segments are realized by either intra-area P2MP LSPs or by ingress 349 replication. 351 When BGP MVPN I-PMSI or S-PMSI A-D routes are advertised or 352 propagated to signal Inter-area P2MP service LSPs, to indicate that 353 these LSPs should be segmented using the procedures specified in this 354 document, these routes MUST carry the Inter-area P2MP Segmented Next- 355 Hop Extended Community. This Extended Community MUST be included in 356 the I-PMSI/S-PMSI A-D route by the PE that originates such a route, 357 or an ASBR that re-advertises such a route into its own AS. The 358 Global Administrator field in this Extended Community MUST be set to 359 the advertising PE or ASBR's IP address. This Extended Community MUST 360 also be included by ABRs as they re-advertise such routes. An ABR 361 MUST set the Global Administrator field of the P2MP Segmented Next- 362 Hop Extended Community to its own IP address. Presence of this 363 community in the I-PMSI/S-PMSI A-D routes indicates to ABRs and 364 PEs/ASBRs that they have to follow the procedures in this document 365 when these procedures differ from those in [RFC6514]. 367 If an ASBR receives from an IBGP peer an I-PMSI or S-PMSI A-D route 368 that carries the Inter-area P2MP Segmented Next-Hop Extended 369 Community, then before re-advertising this route to an EBGP peer the 370 ASBR SHOULD remove this Community from the route. 372 If an ASBR receives an I-PMSI/S-PMSI A-D route from an EBGP peer, and 373 this route does carry the Inter-area P2MP Segmented Next- Hop 374 Extended Community, if the inter-area P2MP service LSP signalled by 375 this route should not be segmented, then before re-advertising this 376 route to its IBGP peers the ASBR MUST remove this community from the 377 route. 379 To avoid requiring ABRs to participate in the propagation of C- 380 multicast routes, this document requires ABRs NOT to modify BGP Next 381 Hop when re-advertising Inter-AS I-PMSI A-D routes. For consistency 382 this document requires ABRs to NOT modify BGP Next-Hop when re- 383 advertising both Intra-AS and Inter-AS I-PMSI/S-PMSI A-D routes. The 384 egress PEs may advertise the C-multicast routes to RRs that are 385 different than the ABRs. However ABRs still can be configured to be 386 the Route Reflectors for C-multicast routes, in which case they will 387 participate in the propagation of C-multicast routes. 389 5.2. BGP VPLS or LDP VPLS with BGP auto-discovery 391 Egress PEs discover the P2MP FEC of the service LSPs used by VPLS, 392 using the VPLS A-D routes that are originated by the ingress PEs 393 [RFC4761, RFC6074], or VPLS S-PMSI A-D routes that are originated by 394 the ingress PEs [VPLS-P2MP]. The NLRI of such routes encodes the P2MP 395 FEC. 397 The "Leaf Information Required" flag MUST be set in the P-Tunnel 398 attribute carried in such routes, when originated by the ingress PEs 399 or ASBRs, except for the case where (a) as a matter of policy 400 (provisioned on the ingress PEs or ASBRs) there is no aggregation of 401 ingress area segments of the service LSPs, and (b) mLDP is used as 402 the protocol to establish intra-area transport LSPs in the ingress 403 area. Before any Leaf A-D route is advertised by a PE or ABR in the 404 same area, as described in the following sections, an VPLS/S-PMSI A-D 405 route is advertised either with an explicit Tunnel Type and Tunnel 406 Identifier in the PMSI Tunnel Attribute, if the Tunnel Identifier has 407 already been assigned, or with a special Tunnel Type of "No tunnel 408 information present" otherwise. 410 When the VPLS/S-PMSI A-D routes are re-advertised by an ingress ABR, 411 the "Leaf Information Required" flag MUST be set in the P-Tunnel 412 attribute present in the routes, except for the case where (a) as a 413 matter of policy (provisioned on the ingress ABR) there is no 414 aggregation of backbone area segments of the service LSPs, and (b) 415 mLDP is used as the protocol to establish intra-area transport LSPs 416 in the backbone area. Likewise, when the VPLS/S-PMSI A-D routes are 417 re-advertised by an egress ABR, the "Leaf Information Required" flag 418 MUST be set in the P-Tunnel attribute present in the routes, except 419 for the case where (a) as a matter of policy (provisioned on the 420 egress ABR) there is no aggregation of egress area segments of the 421 service LSPs, and (b) mLDP is used as the protocol to establish 422 intra-area transport LSPs in the egress area. 424 When VPLS A-D routes or S-PMSI A-D routes are advertised or 425 propagated to signal Inter-area P2MP service LSPs, to indicate that 426 these LSPs should be segmented using the procedures specified in this 427 document, these routes MUST carry the Inter-area P2MP Segmented Next- 428 Hop Extended Community. This Extended Community MUST be included in 429 the A-D route by the PE or ASBR that originates such a route and the 430 Global Administrator field MUST be set to the advertising PE or 431 ASBR's IP address. This Extended Community MUST also be included by 432 ABRs as they re-advertise such routes. An ABR MUST set the Global 433 Administrator field of the P2MP Segmented Next-Hop Extended Community 434 to its own IP address. Presence of this community in the I-PMSI/S- 435 PMSI A-D routes indicates to ABRs and PEs/ASBRs that they have to 436 follow the procedures in this document when these procedures differ 437 from those in [VPLS-P2MP]. 439 Note that the procedures in the above paragraph apply when intra-area 440 segments are realized by either intra-area P2MP LSPs or by ingress 441 replication. 443 The procedures in this document require that at least one ABR in a 444 given area acts as a Route Reflector for VPLS A-D routes. Such a 445 Router Reflector is responsible for re-advertising VPLS A-D routes 446 across area's boundaries. When re-advertising these routes across 447 area's boundaries, this Route Reflector MUST follow the procedures in 448 this document. Note that such a Route Reflector may also re-advertise 449 VPLS A-D routes within the same area, in which case it follows plain 450 BGP Route Reflector procedures [RFC4456]. 452 When re-advertising VPLS A-D routes a Route Reflector MUST NOT modify 453 BGP Next Hop of these routes. 455 5.3. Global Table Multicast over MPLS 457 This section describes how the egress PEs discover the P2MP FEC when 458 the application is global table multicast over an MPLS-capable 459 infrastructure. In the rest of the document we will refer to this 460 application as "global table multicast". 462 When PIM-SM is used for non-bidirectional ASM ("Any Source 463 Multicast") group addresses, this document refers to this as "PIM-SM 464 in ASM mode". 466 In the case where global table multicast uses PIM-SM in ASM mode the 467 following assumes that an inter-area P2MP service LSP could be used 468 to either carry traffic on a shared (*,G), or a source (S,G) tree. 470 An egress PE learns the (S/*, G) of a multicast stream as a result of 471 receiving IGMP or PIM messages on one of its IP multicast interfaces. 472 This (S/*, G) forms the P2MP FEC of the inter-area P2MP service LSP. 473 For each such P2MP FEC there MAY exist a distinct inter-area P2MP 474 service LSP, or multiple such FECs MAY be carried over a single P2MP 475 service LSP using a wildcard (*, *) S-PMSI [RFC6625]. 477 Note that this document does not require the use of (*, G) Inter-area 478 P2MP service LSPs when global table multicast uses PIM-SM in ASM 479 mode. In fact, PIM-SM in ASM mode may be supported entirely by using 480 only (S, G) inter-area P2MP service LSPs. 482 6. Egress PE/ASBR Procedures 484 This section describes egress PE/ASBR procedures for constructing 485 segmented inter-area P2MP LSP. The procedures in this section apply 486 irrespective of whether the egress PE/ASBR is in a leaf IGP area, or 487 the backbone area, or even in the same IGP area as the ingress 488 PE/ASBR. 490 An egress PE/ASBR applies procedures specified in this section to 491 MVPN I-PMSI or S-PMSI A-D routes only if these routes carry the 492 Inter-area P2MP Segmented Next-Hop Extended Community. An egress PE 493 applies procedures specified in this section to VPLS A-D routes or 494 VPLS S-PMSI A-D routes only if these routes carry the Inter-area P2MP 495 Segmented Next-Hop Extended Community. 497 In order to support global table multicast an egress PE MUST auto- 498 configure an import AS-specific Route Target Extended Community 499 ([RFC4360]) with the Global Administrator field set to the AS of the 500 PE and the Local Administrator field set to 0. 502 Once an egress PE/ASBR discovers the P2MP FEC of an inter-area 503 segmented P2MP service LSP, it MUST propagate this P2MP FEC in BGP in 504 order to construct the segmented inter-area P2MP service LSP. This 505 propagation uses BGP Leaf A-D routes. 507 6.1. Determining the Upstream ABR/PE/ASBR (Upstream Node) 509 An egress PE/ASBR discovers the P2MP FEC of an inter-area P2MP 510 Segmented Service LSP as described in section 5 ("Discovering P2MP 511 FEC of the Inter-Area P2MP Service LSP"). Once the egress PE/ASBR 512 discovers this P2MP FEC, it MUST determine the upstream node to reach 513 such a FEC. If the egress PE/ASBR and the ingress PE/ASBR are not in 514 the same area, and the egress PE/ASBR is not in the backbone IGP 515 area, then this upstream node would be an egress ABR. If the egress 516 PE/ASBR is in the backbone area and the ingress PE/ASBR is not in the 517 backbone area, then this upstream node would be an ingress ABR. If 518 the egress PE/ASBR is in the same area as the ingress PE/ASBR, then 519 this upstream node would be the ingress PE/ASBR. 521 6.1.1. Upstream Node for MVPN or VPLS 523 If the application is MVPN or VPLS, then the upstream node's IP 524 address is the IP address determined from the Global Administrator 525 field of the Inter-area P2MP Segmented Next-hop Extended Community. 526 As described in section 5 ("Discovering P2MP FEC of the Inter-Area 527 P2MP Service LSP"), this Extended Community MUST be carried in the 528 MVPN or VPLS A-D route from which the P2MP FEC of the inter-area P2MP 529 Segmented Service LSP is determined. 531 6.1.2. Upstream Node for Global Table Multicast 533 If the application is global table multicast, then the unicast routes 534 to multicast sources/RPs SHOULD carry the VRF Route Import Extended 535 Community [RFC6514] where the IP address in the Global Administrator 536 field is set to the IP address of the PE or ASBR advertising the 537 unicast route. The Local Administrator field of this community MUST 538 be set to 0 (note, that this is in contrast to the case of MVPN, 539 where the Global Administrator field carries a non-zero value that 540 identifies a particular VRF on a PE that originates VPN-IP routes). 541 If it is not desirable to advertise the VRF Route Import Extended 542 Community in unicast routes, then unicast routes to multicast 543 sources/RPs MUST be advertised using the multicast SAFI i.e. SAFI 2, 544 and such routes MUST carry the VRF Route Import Extended Community. 546 Further, if the application is global table multicast, then the BGP 547 unicast routes that advertise the routes to the IP addresses of 548 PEs/ASBRs/ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop 549 Extended Community. The IP address in the Global Administrator field 550 of this community MUST be set to the IP address of the PE or ASBR or 551 ABR advertising the unicast route. The Local Administrator field of 552 this community MUST be set to 0. If it is not desirable to advertise 553 the P2MP Segmented Next-Hop Extended Community in BGP unicast routes, 554 then the BGP unicast routes to the IP addresses of PEs/ASBRs/ABRs 555 MUST be advertised using the multicast SAFI i.e. SAFI 2, and such 556 routes MUST carry the Inter-area P2MP Segmented Next-hop Extended 557 Community. The procedures for handling the BGP Next-Hop attribute of 558 SAFI 2 routes are the same as those of handling regular Unicast 559 routes and MAY follow [SEAMLESS-MPLS]. 561 If the application is global table multicast, then in order to 562 determine the upstream node address the egress PE first determines 563 the ingress PE. In order to determine the ingress PE, the egress PE 564 determines the best route to reach S/RP. The ingress PE address is 565 the IP address determined from the Global Administrator field of the 566 VRF Route Import Extended Community that is carried in this route. 567 The egress PE then finds the best unicast route to reach the ingress 568 PE. The upstream node address is the IP address determined from the 569 Global Administrator field of the Inter-area P2MP Segmented Next-Hop 570 Extended Community that is carried in this route. 572 6.2. Originating a Leaf A-D Route 574 If the P2MP FEC was derived from a MVPN or VPLS A-D route then the 575 egress PE MUST originate a Leaf A-D route if the MVPN or VPLS A-D 576 route carries a P-Tunnel Attribute with the "Leaf Information 577 Required" flag set. 579 If the P2MP FEC was derived from a global table multicast (S/*, G), 580 and the upstream node's address is not the same as the egress PE, 581 then the egress PE MUST originate a Leaf A-D route. 583 6.2.1. Leaf A-D Route for MVPN and VPLS 585 If the P2MP FEC was derived from MVPN or VPLS A-D routes then the 586 Route Key field of the Leaf A-D route contains the NLRI of the A-D 587 route from which the P2MP FEC was derived. This follows procedures 588 for constructing Leaf A-D routes described in [RFC6514, VPLS-P2MP]. 590 6.2.2. Leaf A-D Route for Global Table Multicast 592 If the application is global table multicast, then the MCAST-VPN NLRI 593 of the Leaf A-D route is constructed as follows: 595 The Route Key field of MCAST-VPN NLRI has the following format: 597 +-----------------------------------+ 598 | RD (8 octets) | 599 +-----------------------------------+ 600 | Multicast Source Length (1 octet) | 601 +-----------------------------------+ 602 | Multicast Source (Variable) | 603 +-----------------------------------+ 604 | Multicast Group Length (1 octet) | 605 +-----------------------------------+ 606 | Multicast Group (Variable) | 607 +-----------------------------------+ 608 | Ingress PE's IP address | 609 +-----------------------------------+ 611 RD is set to 0 for (S,G) state and all 1s for (*,G) state, Multicast 612 Source is set to S for (S,G) state or RP for (*,G) state, Multicast 613 Group is set to G, Multicast Source Length and Multicast Group Length 614 is set to either 4 or 16 (depending on whether S/RP and G are IPv4 or 615 IPv6 addresses). 617 The Ingress PE's IP address is determined as described in the section 618 6.1 ("Determining the Upstream ABR/PE/ASBR (Upstream Node)"). 620 The Originating Router's IP address field of MCAST-VPN NLRI is set to 621 the address of the local PE (PE that originates the route). 623 Thus the entire MCAST-VPN NLRI of the route has the following format: 625 +-----------------------------------+ 626 | Route Type = 4 (1 octet) | 627 +-----------------------------------+ 628 | Length (1 octet) | 629 +-----------------------------------+ 630 | RD (8 octets) | 631 +-----------------------------------+ 632 | Multicast Source Length (1 octet) | 633 +-----------------------------------+ 634 | Multicast Source (Variable) | 635 +-----------------------------------+ 636 | Multicast Group Length (1 octet) | 637 +-----------------------------------+ 638 | Multicast Group (Variable) | 639 +-----------------------------------+ 640 | Ingress PE's IP address | 641 +-----------------------------------+ 642 | Originating Router's IP address | 643 +-----------------------------------+ 645 Note that the encoding of MCAST-VPN NLRI for the Leaf A-D routes used 646 for global table multicast is different from the encoding used by the 647 Leaf A-D routes originated in response to S-PMSI or I-PMSI A-D 648 routes. A router that receives a Leaf A-D route can distinguish 649 between these two cases by examining the third octet of the MCAST-VPN 650 NLRI of the route. If the value of this octet is 0x01 or 0x02, or 651 0x03 then this Leaf A-D route was originated in response to an S-PMSI 652 or I-PMSI A-D route. If the value of this octet is either 0x00 or 653 0xff, and octets 3 through 10 contain either all 0x00, or all 0xff 654 then this is a Leaf A-D route used for global table multicast. 656 When the PE deletes (S,G)/(*,G) state that was created as a result of 657 receiving PIM or IGMP messages on one of its IP multicast interfaces, 658 if the PE previously originated a Leaf A-D route for that state, then 659 the PE SHOULD withdraw that route. 661 An Autonomous System with an IPv4 network may provide global table 662 multicast service for customers that use IPv6, and an Autonomous 663 System with an IPv6 network may provide global table multicast 664 service for customers that use IPv4. Therefore the address family of 665 the Ingress PE's IP address and Originating Router's IP address in 666 the Leaf A-D routes used for global table multicast MUST NOT be 667 inferred from the AFI field of the associated 668 MP_REACH_NLRI/MP_UNREACH_NLRI attribute of these routes. The address 669 family is determined from the length of the address (a length of 4 670 octets for IPv4 addresses, a length of 16 octets for IPv6 addresses). 672 For example if an Autonomous System with an IPv4 network is providing 673 IPv6 multicast service to a customer, the Ingress PE's IP address and 674 Originating Router's IP address in the Leaf A-D routes used for IPv6 675 global table multicast will be a four-octet IPv4 address, even though 676 the AFI of those routes will have the value 2. 678 Note that the Ingress PE's IP address and the Originating Router's IP 679 address must be either both IPv4 or both IPv6 addresses, and thus 680 must be of the same length. Since the two variable length fields 681 (Multicast Source and Multicast Group) in the Leaf A-D routes used 682 for global table multicast have their own length field, from these 683 two length fields, and the Length field of the MCAST-VPN NLRI, one 684 can compute length of the Ingress PE's IP address and the Originating 685 Router's IP address fields. If the computed length of these fields is 686 neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered to 687 be "incorrect", and MUST be handled as specified in section 7 of 688 [RFC4760]. 690 6.2.3. Constructing the Rest of the Leaf A-D Route 692 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 693 be set to the same IP address as the one carried in the Originating 694 Router's IP Address field of the route. 696 When Ingress Replication is used to instantiate the egress area 697 segment then the Leaf A-D route MUST carry a downstream assigned 698 label in the P-Tunnel Attribute where the P-Tunnel type is set to 699 Ingress Replication. A PE MUST assign a distinct MPLS label for each 700 Leaf A-D route originated by the PE. 702 To constrain distribution of this route, the originating PE 703 constructs an IP-based Route Target community by placing the IP 704 address of the upstream node in the Global Administrator field of the 705 community, with the Local Administrator field of this community set 706 to 0. The originating PE then adds this Route Target Extended 707 Community to this Leaf A-D route. The upstream node's address is as 708 determined in section 6.1 ("Determining the Upstream ABR/PE/ASBR 709 (Upstream Node)"). 711 The PE then advertises this route to the upstream node. 713 6.3. PIM-SM in ASM mode for Global Table Multicast 715 This specification allows two options for supporting global table 716 multicast with PIM-SM in ASM mode. The first option does not transit 717 IP multicast shared trees over the MPLS network. The second option 718 does transit shared trees over the MPLS network and relies on shared 719 tree to source tree switchover. 721 6.3.1. Option 1 723 This option does not transit IP multicast shared trees over the MPLS 724 network. Therefore, when an (egress) PE creates (*, G) state (as a 725 result of receiving PIM or IGMP messages on one of its IP multicast 726 interfaces), the PE does not propagate this state using Leaf A-D 727 routes. 729 6.3.1.1. Originating Source Active A-D Routes 731 Whenever as a result of receiving PIM Register or MSDP messages an RP 732 that is co-located with a PE discovers a new multicast source, the 733 RP/PE SHOULD originate a BGP Source Active A-D route. Similarly 734 whenever as a result of receiving MSDP messages a PE, that is not 735 configured as a RP, discovers a new multicast source the PE SHOULD 736 originate a BGP Source Active A-D route. The BGP Source Active A-D 737 route carries a single MCAST-VPN NLRI constructed as follows: 739 + The RD in this NLRI is set to 0. 741 + The Multicast Source field MUST be set to S. The Multicast 742 Source Length field is set appropriately to reflect this. 744 + The Multicast Group field MUST be set to G. The Multicast Group 745 Length field is set appropriately to reflect this. 747 The Route Target of this Source Active A-D route is an AS-specific 748 Route Target Extended Community with the Global Administrator field 749 set to the AS of the advertising RP/PE, and the Local Administrator 750 field is set to 0. 752 To constrain distribution of the Source Active A-D route to the AS of 753 the advertising RP this route SHOULD carry the NO_EXPORT Community 754 ([RFC1997]). 756 Using the normal BGP procedures the Source Active A-D route is 757 propagated to all other PEs within the AS. 759 Whenever the RP/PE discovers that the source is no longer active, the 760 RP MUST withdraw the Source Active A-D route, if such a route was 761 previously advertised by the RP. 763 6.3.1.2. Receiving BGP Source Active A-D Route by PE 765 When as a result of receiving PIM or IGMP messages on one of its IP 766 multicast interfaces an (egress) PE creates in its Tree Information 767 Base (TIB) a new (*, G) entry with a non-empty outgoing interface 768 list that contains one or more IP multicast interfaces, the PE MUST 769 check if it has any Source Active A-D routes for that G. If there is 770 such a route, S of that route is reachable via an MPLS interface, and 771 the PE does not have (S, G) state in its TIB for (S, G) carried in 772 the route, then the PE originates a Leaf A-D route carrying that (S, 773 G), as specified in section 6.2.2 ("Leaf A-D Route for Global Table 774 Multicast"). 776 When an (egress) PE receives a new Source Active A-D route, the PE 777 MUST check if its TIB contains an (*, G) entry with the same G as 778 carried in the Source Active A-D route. If such an entry is found, S 779 is reachable via an MPLS interface, and the PE does not have (S, G) 780 state in its TIB for (S, G) carried in the route, then the PE 781 originates a Leaf A-D route carrying that (S, G), as specified in 782 section 6.2.2 ("Leaf A-D Route for Global Table Multicast"). 784 6.3.1.3. Handling (S, G, RPTbit) state 786 Creation and deletion of (S, G, RPTbit) state on a PE that resulted 787 from receiving PIM messages on one of its IP multicast interfaces 788 does not result in any BGP actions by the PE. 790 6.3.2. Option 2 792 This option does transit IP multicast shared trees over the MPLS 793 network. Therefore, when an (egress) PE creates (*, G) state (as a 794 result of receiving PIM or IGMP messages on one of its IP multicast 795 interfaces), the PE does propagate this state using Leaf A-D routes. 797 6.3.2.1. Originating Source Active A-D Routes 799 Whenever a PE creates an (S, G) state as a result of receiving Leaf 800 A-D routes associated with the global table multicast service, if S 801 is reachable via one of the IP multicast capable interfaces, and the 802 PE determines that G is in the PIM-SM in ASM mode range, the PE MUST 803 originate a BGP Source Active A-D route. The route carries a single 804 MCAST-VPN NLRI constructed as follows: 806 + The RD in this NLRI is set to 0. 808 + The Multicast Source field MUST be set to S. The Multicast 809 Source Length field is set appropriately to reflect this. 811 + The Multicast Group field MUST be set to G. The Multicast Group 812 Length field is set appropriately to reflect this. 814 The Route Target of this Source Active A-D route is an AS-specific 815 Route Target Extended Community with the Global Administrator field 816 set to the AS of the advertising PE, and the Local Administrator 817 field is set to 0. 819 To constrain distribution of the Source Active A-D route to the AS of 820 the advertising PE this route SHOULD carry the NO_EXPORT Community 821 ([RFC1997]). 823 Using the normal BGP procedures the Source Active A-D route is 824 propagated to all other PEs within the AS. 826 Whenever the PE deletes the (S, G) state that was previously created 827 as a result of receiving a Leaf A-D route for (S, G), the PE that 828 deletes the state MUST also withdraw the Source Active A-D route, if 829 such a route was advertised when the state was created. 831 6.3.2.2. Receiving BGP Source Active A-D Route 833 Procedures for receiving BGP Source Active A-D routes are the same as 834 with Option 1. 836 6.3.2.3. Pruning Sources off the Shared Tree 838 If after receiving a new Source Active A-D route for (S,G) a PE 839 determines that (a) it has the (*, G) entry in its TIB, (b) the 840 incoming interface list (iif) for that entry contains one of the IP 841 interfaces, (c) a MPLS LSP is in the outgoing interface list (oif) 842 for that entry, and (d) the PE does not originate a Leaf A-D route 843 for (S,G), then the PE MUST transition the (S,G,rpt) downstream state 844 to the Prune state. [Conceptually the PIM state machine on the PE 845 will act "as if" it had received Prune(S,G,Rpt) from some other PE, 846 without actually having received one.] Depending on the (S,G,rpt) 847 state on the iifs, this may result in the PE using PIM procedures to 848 prune S off the Shared (*,G) tree. 850 Transitioning the state machine to the Prune state SHOULD be done 851 after a delay that is controlled by a timer. The value of the timer 852 MUST be configurable. The purpose of this timer is to ensure that S 853 is not pruned off the shared tree until all PEs have had time to 854 receive the Source Active A-D route for (S,G). 856 The PE MUST keep the (S,G,rpt) downstream state machine in the Prune 857 state for as long as (a) the outgoing interface list (oif) for (*, G) 858 contains a MPLS LSP, and (b) the PE has at least one Source Active A- 859 D route for (S,G), and (c) the PE does not originate the Leaf A-D 860 route for (S,G). Once either of these conditions become no longer 861 valid, the PE MUST transition the (S,G,rpt) downstream state machine 862 to the NoInfo state. 864 Note that except for the scenario described in the first paragraph of 865 this section, in all other scenarios relying solely on PIM procedures 866 on the PE is sufficient to ensure the correct behavior when pruning 867 sources off the shared tree. 869 6.3.2.4. More on handling (S, G, RPTbit) state 871 Creation and deletion of (S, G, RPTbit) state on a PE that resulted 872 from receiving PIM messages on one of its IP multicast interfaces 873 does not result in any BGP actions by the PE. 875 7. Egress ABR Procedures 877 This section describes Egress ABR Procedures for constructing 878 segmented inter-area P2MP LSP. 880 7.1. Handling Leaf A-D route on Egress ABR 882 When an egress ABR receives a Leaf A-D route and the Route Target 883 Extended Community carried by the route contains the IP address of 884 this ABR, then the following procedures will be executed. 886 If the value of the third octet of the MCAST-VPN NLRI of the received 887 Leaf A-D route is either 0x01, or 0x02, or 0x03, this indicates that 888 the Leaf A-D route was originated in response to an S-PMSI or I-PMSI 889 A-D route (see section "Leaf A-D Route for Global Table Multicast"). 890 In this case the egress ABR MUST find a S-PMSI or I-PMSI route whose 891 NLRI has the same value as the Route Key field of the received Leaf 892 A-D route. If such a matching route is found then the Leaf A-D route 893 MUST be accepted, else it MUST be discarded. If the Leaf A-D route 894 is accepted and if it is the first Leaf A-D route update for the 895 Route Key field in the route, or the withdrawl of the last Leaf A-D 896 route for the Route Key field then the following procedures will be 897 executed. 899 If the RD of the received Leaf A-D route is set to all 0s or all 1s 900 then the received Leaf A-D route is for the global table multicast 901 service. 903 If the received Leaf A-D route is the first Leaf A-D route update for 904 the Route Key field carried in the route, then the egress ABR 905 originates a Leaf A-D route, whose MCAST-VPN NLRI is constructed as 906 follows. 908 The Route Key field of MCAST-VPN NLRI is the same as the Route Key 909 field of MCAST-VPN NLRI of the received Leaf A-D route. The 910 Originating Router's IP address field of MCAST-VPN NLRI is set to the 911 address of the local ABR (the ABR that originates the route). 913 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 914 be set to the same IP address as the one carried in the Originating 915 Router's IP Address field of the route. 917 To constrain distribution of this route the originating egress ABR 918 constructs an IP-based Route Target Extended Community by placing the 919 IP address of the upstream node in the Global Administrator field of 920 the community, with the Local Administrator field of this community 921 set to 0, and sets the Extended Communities attribute of this Leaf A- 922 D route to that community. 924 The upstream node's IP address is the IP address determined from the 925 Global Administrator field of the Inter-area P2MP Segmented Next-hop 926 Extended Community, where this Extended Community is obtained as 927 follows. When the Leaf A-D route is for MVPN or VPLS, then this 928 Extended Community is the one carried in the I-PMSI/S-PMSI A-D route 929 that matches the Leaf A-D route. When the Leaf A-D route is for 930 global table multicast, then this Extended Community is the one 931 carried in the best unicast route to the Ingress PE. The Ingress PE 932 address is determined from the received Leaf A-D route. The best 933 unicast route MUST first be determined from multicast SAFI i.e., SAFI 934 2 routes, if present. 936 The ABR then advertises this Leaf A-D route to the upstream node in 937 the backbone area. 939 Mechanisms specific in [RFC4684] for constrained BGP route 940 distribution can be used along with this specification to ensure that 941 only the needed PE/ABR will have to process a said Leaf A-D route. 943 When Ingress Replication is used to instantiate the backbone area 944 segment then the Leaf A-D route originated by the egress ABR MUST 945 carry a downstream assigned label in the P-Tunnel Attribute where the 946 P-Tunnel type is set to Ingress Replication. The ABR MUST assign a 947 distinct MPLS label for each Leaf A-D route that it originates. 949 In order to support global table multicast an egress ABR MUST auto- 950 configure an import AS-based Route Target Extended Community with the 951 Global Administrator field set to the AS of the ABR and the Local 952 Administrator field set to 0. 954 If the received Leaf A-D route is the withdrawl of the last Leaf A-D 955 route for the Route Key carried in the route, then the egress ABR 956 must withdraw the Leaf A-D route associated with that Route Key that 957 has been previously advertised by the egress ABR in the backbone 958 area. 960 7.2. P2MP LSP as the Intra-Area LSP in the Egress Area 962 This section describes procedures for using intra-area P2MP LSPs in 963 the egress area. The procedures that are common to both P2MP RSVP-TE 964 and P2MP LDP are described first, followed by procedures that are 965 specific to the signaling protocol. 967 When P2MP LSPs are used as the intra-area LSPs, note that an existing 968 intra-area P2MP LSP may be used solely for a particular inter-area 969 P2MP service LSP, or for other inter-area P2MP service LSPs as well. 970 The choice between the two options is purely local to the egress ABR. 971 The first option provides one-to-one mapping between inter-area P2MP 972 service LSPs and intra-area P2MP LSPs; the second option provides 973 many-to-one mapping, thus allowing to aggregate forwarding state. 975 7.2.1. Received Leaf A-D route is for MVPN or VPLS 977 If the value of the third octet of the MCAST-VPN NLRI of the received 978 Leaf A-D route is either 0x01, or 0x02, or 0x03, this indicates that 979 the Leaf A-D route was originated in response to an MVPN or VPLS S- 980 PMSI or I-PMSI A-D route (see section "Leaf A-D Route for Global 981 Table Multicast"). In this case the ABR MUST re-advertise in the 982 egress area the MVPN/VPLS A-D route that matches the Leaf A-D route 983 to signal the binding of the intra-area P2MP LSP to the inter-area 984 P2MP service LSP. This must be done ONLY if (a) such a binding hasn't 985 already been advertised, or (b) the binding has changed. The re- 986 advertised route MUST carry the Inter-area P2MP Segmented Next-Hop 987 Extended Community. 989 The PMSI Tunnel attribute of the re-advertised route specifies either 990 an intra-area P2MP RSVP-TE LSP or an intra-area P2MP LDP LSP rooted 991 at the ABR and MUST also carry an upstream assigned MPLS label. The 992 upstream-assigned MPLS label MUST be set to implicit NULL if the 993 mapping between the inter-area P2MP service LSP and the intra-area 994 P2MP LSP is one-to-one. If the mapping is many-to-one the intra-area 995 segment of the inter-area P2MP service LSP (referred to as the 996 "inner" P2MP LSP) is constructed by nesting the inter-area P2MP 997 service LSP in an intra-area P2MP LSP (referred to as the "outer" 998 intra-area P2MP LSP), by using P2MP LSP hierarchy based on upstream- 999 assigned MPLS labels [RFC 5332]. 1001 If segments of multiple MVPN or VPLS S-PMSI service LSPs are carried 1002 over a given intra-area P2MP LSP, each of these segments MUST carry a 1003 distinct upstream-assigned label, even if all these service LSPs are 1004 for (C-S/*, C-G/*)s from the same MVPN/VPLS. Therefore, an ABR 1005 maintains an LFIB state for each of the (C-S/*, C-G/*)s carried over 1006 S-PMSIs traversing this ABR (that applies to both the ingress and the 1007 egress ABRs). 1009 7.2.2. Received Leaf A-D route is for global table multicast 1011 When the RD of the received Leaf A-D route is set to all 0s or all 1012 1s, then this is the case of inter-area P2MP service LSP being 1013 associated with the global table multicast service. The procedures 1014 for this are described below. 1016 7.2.2.1. Global Table Multicast and S-PMSI A-D Routes 1018 This section applies only if it is desirable to send a particular (S, 1019 G) or (*, G) global table multicast flow only to those egress PEs 1020 that have receivers for that multicast flow. 1022 If the egress ABR have not previousely received (and re-advertised) 1023 an S-PMSI A-D route for (S, G) or (*, G) that has been originated by 1024 an ingress PE/ASBR (see section "P2MP LSP as the Intra-Area LSP in 1025 the Ingress Area"), then the egress ABR MUST originate a S-PMSI A-D 1026 route. The PMSI Tunnel attribute of the route MUST contain the 1027 identity of the intra-area P2MP LSP and an upstream assigned MPLS 1028 label (although this label may be an Implicit NULL - see section 1029 "General Assumptions and Terminology"). The RD, Multicast Source 1030 Length, Multicast Source, Multicast Group Length (1 octet), and 1031 Multicast Group fields of the NLRI of this route are the same as of 1032 the received Leaf A-D route. The Originating Router's IP address 1033 field in the S-PMSI A-D route is the same as the Ingress PE's IP 1034 address field in the received Leaf A-D route. The Route Target of 1035 this route is an AS-specific Route Target Extended Community with the 1036 Global Administrator field set to the AS of the advertising ABR, and 1037 the Local Administrator field is set to 0. The route MUST carry the 1038 Inter-area P2MP Segmented Next-Hop Extended Community. This 1039 community is constructed following the procedures in section 4 1040 ("Inter-area P2MP Segmented Next-Hop Extended Community"). 1042 The egress ABR MUST advertise this route into the egress area. PEs in 1043 the egress area that participate in the global table multicast will 1044 import this route. 1046 A PE in the egress area that originated the Leaf A-D route SHOULD 1047 join the P2MP LSP advertised in the PMSI Tunnel attribute of the S- 1048 PMSI A-D route. 1050 7.2.2.2. Global Table Multicast and Wildcard S-PMSI A-D Routes 1052 It may be desirable for an ingress PE to carry multiple multicast 1053 flows associated with the global table multicast over the same inter- 1054 area P2MP service LSP. This can be achieved using wildcard, i.e., 1055 (*,*) S-PMSI A-D routes [RFC6625]. An ingress PE MAY advertise a 1056 wildcard S-PMSI A-D route as described in section 9 ("Ingress PE/ASBR 1057 Procedures"). 1059 If the ingress PE originates a wildcard S-PMSI A-D route, and the 1060 egress ABR receives this route from the ingress ABR, then the egress 1061 ABR either (a) MUST re-advertise this route into the egress area with 1062 the PMSI Tunnel Attribute containing the identifier of the intra-area 1063 P2MP LSP in the egress area and an upstream assigned label (note that 1064 this label may be an Implicit NULL - see section "General Assumptions 1065 and Terminology") assigned to the inter-area wildcard S-PMSI, or (b) 1066 MUST be able to disaggregate traffic carried over the wildcard S-PMSI 1067 onto the egress area (S, G) or (*, G) S-PMSIs. The procedures for 1068 such disaggregation require IP processing on the egress ABRs. 1070 If the egress ABR advertises a wildcard S-PMSI A-D route into the 1071 egress area, this route MUST carry AS-specific Route Target Extended 1072 Community with the Global Administrator field set to the AS of the 1073 advertising ABR, and the Local Administrator field set to 0. PEs in 1074 the egress area that participate in the global table multicast will 1075 import this route. 1077 A PE in the egress area SHOULD join the P2MP LSP advertised in the 1078 PMSI Tunnel attribute of the wildcard S-PMSI A-D route if (a) the 1079 Originating Router's IP Address field in the S-PMSI A-D route has the 1080 same value as the Ingress PE's IP address in at least one of the Leaf 1081 A-D routes for global table multicast originated by the PE, and (b) 1082 the upstream ABR for the Ingress PE's IP address in that Leaf A-D 1083 route is the (egress) ABR that advertises the wildcard S-PMSI A-D 1084 route. 1086 7.2.3. Global Table Multicast and the Expected Upstream Node 1088 If the mapping between the inter-area P2MP service LSP for global 1089 table multicast service and the intra-area P2MP LSP is many-to-one 1090 then an egress PE must be able to determine whether a given multicast 1091 packet for a particular (S, G) is received from the "expected" 1092 upstream node. The expected node is the node towards which the Leaf 1093 A-D route is sent by the egress PE. Packets received from another 1094 upstream node for that (S, G) MUST be dropped. To allow the egress PE 1095 to determine the sender upstream node, the intra-area P2MP LSP must 1096 be signaled with no PHP, when the mapping between the inter-area P2MP 1097 service LSP for global table multicast service and the intra-area 1098 P2MP LSP is many-to-one. 1100 Further the egress ABR MUST first push onto the label stack the 1101 upstream assigned label advertised in the S-PMSI A-D route, if the 1102 label is not the Implicit NULL. 1104 7.2.4. P2MP LDP LSP as the Intra-Area P2MP LSP 1106 The above procedures are sufficient if P2MP LDP LSPs are used as the 1107 Intra-area P2MP LSP in the Egress area. 1109 7.2.5. P2MP RSVP-TE LSP as the Intra-Area P2MP LSP 1111 If P2MP RSVP-TE LSP is used as the the intra-area LSP in the egress 1112 area, then the egress ABR can either (a) graft the leaf (whose IP 1113 address is specified in the received Leaf A-D route) into an existing 1114 P2MP LSP rooted at the egress ABR, and use that LSP for carrying 1115 traffic for the inter-area segmented P2MP service LSP, or (b) 1116 originate a new P2MP LSP to be used for carrying (S,G). 1118 When the RD of the received Leaf A-D route is all 0s or all 1s, then 1119 the procedures are as described in section "Received Leaf A-D route 1120 is for global table multicast". 1122 Note also that the SESSION object that the egress ABR would use for 1123 the intra-area P2MP LSP need not encode the P2MP FEC from the 1124 received Leaf A-D route. 1126 7.3. Ingress Replication in the Egress Area 1128 When Ingress Replication is used to instantiate the egress area 1129 segment then the Leaf A-D route advertised by the egress PE MUST 1130 carry a downstream assigned label in the P-Tunnel Attribute where the 1131 P-Tunnel type is set to Ingress Replication. We will call this label 1132 the egress PE downstream assigned label. 1134 The egress ABR MUST forward packets received from the backbone area 1135 intra-area segment, for a particular inter-area P2MP LSP, to all the 1136 egress PEs from which the egress ABR has imported a Leaf A-D route 1137 for the inter-area P2MP LSP. A packet to a particular egress PE is 1138 encapsulated, by the egress ABR, using a MPLS label stack the bottom 1139 label of which is the egress PE downstream assigned label. The top 1140 label is the P2P RSVP-TE or the MP2P LDP label to reach the egress 1141 PE. 1143 Note that these procedures ensures that an egress PE always receives 1144 packets only from the upstream node expected by the egress PE. 1146 8. Ingress ABR Procedures 1148 When an ingress ABR receives a Leaf A-D route and the Route Target 1149 Extended Community carried by the route contains the IP address of 1150 this ABR, then the ingress ABR follows the same procedures as in 1151 section 7 ("Egress ABR Procedures"), with egress ABR replaced by 1152 ingress ABR, backbone area replaced by ingress area, and backbone 1153 area segment replaced by ingress area segment. 1155 In order to support global table multicast the ingress ABR MUST be 1156 auto-configured with an import AS-based Route Target Extended 1157 Community whose Global Administrator field is set to the AS of the 1158 ABR and the Local Administrator field is set to 0. 1160 8.1. P2MP LSP as the Intra-Area LSP in the Backbone Area 1162 The procedures for binding the backbone area segment of an inter-area 1163 P2MP LSP to the intra-area P2MP LSP in the backbone area are the same 1164 as in section "Egress ABR Procedures" and sub-section "P2MP LSP as 1165 the Intra-Area LSP in the Egress Area", with egress PE being replace 1166 by egress ABR, egress ABR being replaced by ingress ABR, and egress 1167 area being replaced by backbone area. This applies to the inter-area 1168 P2MP LSPs associated with either MVPN, or VPLS, or global table 1169 multicast. 1171 It is to be noted that in the case of global table multicast, if the 1172 backbone area uses wildcard S-PMSI, then the egress area also SHOULD 1173 use wildcard S-PMSI for global table multicast, or the egress ABRs 1174 MUST be able to disaggregate traffic carried over the wildcard S-PMSI 1175 onto the egress area (S, G) or (*, G) S-PMSIs. The procedures for 1176 such disaggregation require IP processing on the egress ABRs. 1178 8.2. Ingress Replication in the Backbone Area 1180 When Ingress Replication is used to instantiate the backbone area 1181 segment then the Leaf A-D route advertised by the egress ABR MUST 1182 carry a downstream assigned label in the P-Tunnel Attribute where the 1183 P-Tunnel type is set to Ingress Replication. We will call this the 1184 egress ABR downstream assigned label. The egress ABR MUST assign a 1185 distinct MPLS label for each Leaf A-D route originated by the ABR. 1187 The ingress ABR MUST forward packets received from the ingress area 1188 intra-area segment, for a particular inter-area P2MP LSP, to all the 1189 egress ABRs from which the ingress ABR has imported a Leaf A-D route 1190 for the inter-area P2MP LSP. A packet to a particular egress ABR is 1191 encapsulated, by the ingress ABR, using a MPLS label stack the bottom 1192 label of which is the egress ABR downstream assigned label. The top 1193 label is the P2P RSVP-TE or the MP2P LDP label to reach the egress 1194 ABR. 1196 9. Ingress PE/ASBR Procedures 1198 This section describes Ingress PE/ASBR procedures for constructing 1199 segmented inter-area P2MP LSP. 1201 When an ingress PE/ASBR receives a Leaf A-D route and the Route 1202 Target Extended Community carried by the route contains the IP 1203 address of this PE/ASBR, then the following procedures will be 1204 executed. 1206 If the value of the third octet of the MCAST-VPN NLRI of the received 1207 Leaf A-D route is either 0x01, or 0x02, or 0x03, this indicates that 1208 the Leaf A-D route was originated in response to an S-PMSI or I-PMSI 1209 A-D route (see section "Leaf A-D Route for Global Table Multicast"). 1210 In this case the ingress PE/ASBR MUST find a S-PMSI or I-PMSI route 1211 whose NLRI has the same value as the Route Key field of the received 1212 Leaf A-D route. If such a matching route is found then the Leaf A-D 1213 route MUST be accepted else it MUST be discarded. If the Leaf A-D 1214 route is accepted then it MUST be processed as per MVPN or VPLS 1215 procedures. 1217 If the RD of the received A-D route is set to all 0s or all 1s, then 1218 the received Leaf A-D route is for the global table multicast 1219 service. If this is the first Leaf A-D route for the Route Key 1220 carried in the route, the PIM implementation MUST set its upstream 1221 (S/RP,G) state machine to Joined state for the (S/RP, G) received via 1222 a Leaf A-D route update. Likewise, if this is the withdrawal of the 1223 last Leaf A-D route whose Route Key matches a particular (S/RP, G) 1224 state, the PIM implementation MUST set its upstream (S/RP, G) state 1225 machine to Pruned state for the (S/RP, G). 1227 9.1. P2MP LSP as the Intra-Area LSP in the Ingress Area 1229 If the value of the third octet of the MCAST-VPN NLRI of the received 1230 Leaf A-D route is either 0x01, or 0x02, or 0x03 (which indicates that 1231 the Leaf A-D route was originated in response to an S-PMSI or I-PMSI 1232 A-D route), and P2MP LSP is used as the the intra-area LSP in the 1233 ingress area, then the procedures for binding the ingress area 1234 segment of the inter-area P2MP LSP to the intra-area P2MP LSP in the 1235 ingress area, are the same as in section "Egress ABR Procedures" and 1236 sub-section "P2MP LSP as the Intra-Area LSP in the Egress Area". 1238 When the RD of the received Leaf A-D route is all 0s or all 1s, as is 1239 the case where the inter-area service P2MP LSP is associated with the 1240 global table multicast service, then the ingress PE MAY originate a 1241 S-PMSI A-D route with the RD, multicast source, multicast group 1242 fields being the same as those in the received Leaf A-D route. 1244 Further in the case of global table multicast an ingress PE MAY 1245 originate a wildcard S-PMSI A-D route as per the procedures in 1246 [RFC6625] with the RD set to 0. This route may be originated by the 1247 ingress PE based on configuration or based on the import of a Leaf A- 1248 D route with RD set to 0. If an ingress PE originates such a route, 1249 then the ingress PE MAY decide not to originate (S, G) or (*, G) S- 1250 PMSI A-D routes. 1252 The wildcard S-PMSI A-D route MUST carry the Inter-area P2MP 1253 Segmented Next-Hop Extended Community. This community is constructed 1254 following the procedures in section 4 ("Inter-area P2MP Segmented 1255 Next-Hop Extended Community"). 1257 It is to be noted that in the case of global table multicast, if the 1258 ingress area uses wildcard S-PMSI, then the backbone area also SHOULD 1259 use wildcard S-PMSI for global table multicast, or the ingress ABRs 1260 MUST be able to disaggregate traffic carried over the wildcard S-PMSI 1261 onto the backbone area (S, G) or (*, G) S-PMSIs. The procedures for 1262 such disaggregation require IP processing on the ingress ABRs. 1264 9.2. Ingress Replication in the Ingress Area 1266 When Ingress Replication is used to instantiate the ingress area 1267 segment then the Leaf A-D route advertised by the ingress ABR MUST 1268 carry a downstream assigned label in the P-Tunnel Attribute where the 1269 P-Tunnel type is set to Ingress Replication. We will call this the 1270 ingress ABR downstream assigned label. The ingress ABR MUST assign a 1271 distinct MPLS label for each Leaf A-D route originated by the ABR. 1273 The ingress PE/ASBR MUST forward packets received from the CE, for a 1274 particular inter-area P2MP LSP, to all the ingress ABRs from which 1275 the ingress PE/ASBR has imported a Leaf A-D route for the inter-area 1276 P2MP LSP. A packet to a particular ingress ABR is encapsulated, by 1277 the ingress PE/ASBR, using a MPLS label stack the bottom label of 1278 which is the ingress ABR downstream assigned label. The top label is 1279 the P2P RSVP-TE or the MP2P LDP label to reach the ingress ABR. 1281 10. Common Tunnel Type in the Ingress and Egress Areas 1283 For a given inter-area service P2MP LSP, the PE/ASBR that is the root 1284 of that LSP controls the tunnel type of the intra-area P-tunnel that 1285 carries the ingress area segment of that LSP. However, the tunnel 1286 type of the intra-area P-tunnel that carries the backbone area 1287 segment of that LSP may be different from the tunnel type of the 1288 intra-area P-tunnels that carry the ingress area segment and the 1289 egress area segment of that LSP. In that situation if for a given 1290 inter-area P2MP LSP it is desirable/necessary to use the same tunnel 1291 type for the intra-area P-tunnels that carry the ingress area segment 1292 and the egress area segment of that LSP, then the following 1293 procedures on the ingress ABR and egress ABR provide this 1294 functionality. 1296 When an ingress ABR re-advertises into the backbone area a BGP MVPN 1297 I-PMSI, or S-PMSI A-D route, or VPLS A-D route, the ingress ABR 1298 places the PMSI Tunnel attribute of this route into the ATTR_SET BGP 1299 Attribute [RFC6368], adds this attribute to the re-advertised route, 1300 and then replaces the original PMSI Tunnel attribute with a new one 1301 (note, that the Tunnel type of the new attribute may be different 1302 from the Tunnel type of the original attribute). 1304 When an egress ABR re-advertises into the egress area a BGP MVPN I- 1305 PMSI or S-PMSI A-D route, or VPLS A-D route, if the route carries the 1306 ATTR_SET BGP attribute [RFC6368], then the ABR sets the Tunnel type 1307 of the PMSI Tunnel attribute in the re-advertised route to the Tunnel 1308 type of the PMSI Tunnel attribute carried in the ATTR_SET BGP 1309 attribute, and removes the ATTR_SET from the route. 1311 11. Placement of Ingress and Egress PEs 1313 As described in the earlier sections, procedures in this document 1314 allow the placement of ingress and egress PEs in the backbone area. 1315 They also allow the placement of egress PEs in the ingress area or 1316 the placement of ingress PEs in the egress area. 1318 For instance, ABRs in the backbone area may act as ingress and egress 1319 PEs for global table multicast, as per the ingress and egress PE 1320 definition in this document. This may be the case if the service is 1321 global table multicast and relies on global table multicast in the 1322 ingress and egress areas and its desirable to carry global table 1323 multicast over MPLS in the backbone area. This may also be the case 1324 if the service is MVPN and the P-tunnel technology in the ingress and 1325 egress areas uses PIM based IP/GRE P-tunnels. As far as the ABRs are 1326 concerned PIM signaling for such P-Tunnels is handled as per the 1327 ingress/egress PE global table multicast procedures specified in this 1328 document. To facilitate this the ABRs may advertise their loopback 1329 addresses in BGP using multicast-SAFI i.e., SAFI 2, if non-congruence 1330 between unicast and multicast is desired. 1332 12. MVPN with Virtual Hub-and-Spoke 1334 Procedures described in this document could be used in conjunction 1335 with the Virtual Hub-and-Spoke procedures [virtual-hub-and-spoke]. 1337 This document does not place any restrictions on the placement of 1338 Virtual Hubs and Virtual Spokes. 1340 In addition to I-PMSI/S-PMSI A-D routes, the procedures described in 1341 this document are applicable to Associated-V-spoke-only I-PMSI A-D 1342 routes. 1344 In the scenario where a V-hub, as a result of importing an S-PMSI A-D 1345 route in its VRF, originates an S-PMSI A-D route targeted to its V- 1346 spokes (as specified in section "Case 2" of [virtual-hub-and-spoke]), 1347 the V-hub SHOULD be able to control via configuration whether the 1348 Inter-area P2MP Segmented Next-Hop Extended Community, if present in 1349 the received S-PMSI A-D route, be also carried in the originated S- 1350 PMSI A-D route. By default if the received S-PMSI A-D route carries 1351 the Inter-area P2MP Segmented Next-Hop Extended Community, then the 1352 originated S-PMSI A-D route SHOULD also carry this community. 1354 13. Data Plane 1356 This section describes the data plane procedures on the ABRs, ingress 1357 PEs, egress PEs and transit routers. 1359 13.1. Data Plane Procedures on ABRs 1361 When procedures in this document are followed to signal inter-area 1362 P2MP Segmented LSPs, then ABRs are required to perform only MPLS 1363 switching. When an ABR receives a MPLS packet from an "incoming" 1364 intra-area segment of the inter-area P2MP Segmented LSP, it forwards 1365 the packet, based on MPLS switching, onto another "outgoing" intra- 1366 area segment of the inter-area P2MP Segmented LSP. 1368 If the outgoing intra-area segment is instantiated using a P2MP LSP, 1369 and if there is a one-to-one mapping between the outgoing intra-area 1370 segment and the P2MP LSP, then the ABR MUST pop the incoming 1371 segment's label stack and push the label stack of the outgoing P2MP 1372 LSP. If there is a many-to-one mapping between outgoing intra-area 1373 segments and the P2MP LSP then the ABR MUST pop the incoming 1374 segment's label stack and first push the upstream assigned label 1375 corresponding to the outgoing intra-area segment, if such a label has 1376 been assigned, and then push the label stack of the outgoing P2MP 1377 LSP. 1379 If the outgoing intra-area segment is instantiated using ingress 1380 replication then the ABR must pop the incoming segment's label stack 1381 and replicate the packet once to each leaf ABR or PE of the outgoing 1382 intra-area segment. The label stack of the packet sent to each such 1383 leaf MUST first include a downstream assigned label assigned by the 1384 leaf to the segment, followed by the label stack of the P2P or MP2P 1385 LSP to the leaf. 1387 13.2. Data Plane Procedures on Egress PEs 1389 An egress PE must first identify the inter-area P2MP segmented LSP 1390 based on the incoming label stack. After this identification the 1391 egress PE must forward the packet using the application that is bound 1392 to the inter-area P2MP segmented LSP. 1394 Note that the application specific forwarding for MVPN service may 1395 require the egress PE to determine whether the packets were received 1396 from the expected sender PE. When the application is MVPN then the 1397 FEC of an inter-area P2MP Segmented LSP is at the granularity of the 1398 sender PE. Note that MVPN intra-AS I-PMSI A-D routes and S-PMSI A-D 1399 routes both carry the Originating Router IP Address. Thus an egress 1400 PE could associate the data arriving on P-tunnels advertised by these 1401 routes with the Originating Router IP Address carried by these routes 1402 which is the same as the ingress PE. Since a unique label stack is 1403 associated with each such FEC, the egress PE can determine the sender 1404 PE from the label stack. 1406 Likewise for VPLS service for the purposes of MAC learning the egress 1407 PE must be able to determine the "VE-ID" from which the packets have 1408 been received. The FEC of the VPLS A-D routes carries the VE-ID. Thus 1409 an egress PE could associate the data arriving on P-tunnels 1410 advertised by these routes with the VE-ID carried by these routes. 1411 Since a unique label stack is associated with each such FEC, the 1412 egress PE can perform MAC learning for packets received from a given 1413 VE-ID. 1415 When the application is global table multicast it is sufficient for 1416 the label stack to include identification of the sender upstream 1417 node. When P2MP LSPs are used this requires that PHP MUST be turned 1418 off. When Ingress Replication is used the egress PE knows the 1419 incoming downstream assigned label to which it has bound a particular 1420 (S/*, G) and must accept packets with only that label for that (S/*, 1421 G). 1423 13.3. Data Plane Procedures on Ingress PEs 1425 An Ingress PE must perform application specific forwarding procedures 1426 to identify the outgoing inta-area segment of an incoming packet. 1428 If the outgoing intra-area segment is instantiated using a P2MP LSP, 1429 and if there is a one-to-one mapping between the outgoing intra-area 1430 segment and the P2MP LSP, then the ingress PE MUST encapsulate the 1431 packet in the label stack of the outgoing P2MP LSP. If there is a 1432 many-to-one mapping between outgoing intra-area segments and the P2MP 1433 LSP then the PE MUST first push the upstream assigned label 1434 corresponding to the outgoing intra-area segment, if such a label has 1435 been assigned, and then push the label stack of the outgoing P2MP 1436 LSP. 1438 If the outgoing intra-area segment is instantiated using ingress 1439 replication then the PE must replicate the packet once to each leaf 1440 ABR or PE of the outgoing intra-area segment. The label stack of the 1441 packet sent to each such leaf MUST first include a downstream 1442 assigned label assigned by the leaf to the segment, followed by the 1443 label stack of the P2P or MP2P LSP to the leaf. 1445 13.4. Data Plane Procedures on Transit Routers 1447 When procedures in this document are followed to signal inter-area 1448 P2MP Segmented LSPs then transit routers in each area perform only 1449 MPLS switching. 1451 14. Support for Inter-Area Transport LSPs 1453 This section describes OPTIONAL procedures that allow to aggregate 1454 multiple (inter-area) P2MP service LSPs into a single inter-area P2MP 1455 transport LSP, and then apply the segmentation procedures, as 1456 specified in this document, to these inter-area P2MP transport LSPs 1457 (rather than applying these procedures directly to the inter-area 1458 P2MP service LSPs). 1460 14.1. Transport Tunnel Tunnel Type 1462 For the PMSI Tunnel Attribute we define a new Tunnel type, called 1463 "Transport Tunnel", whose Tunnel Identifier is a tuple . This Tunnel type is assigned a value of 8. 1465 The Source PE Address is the address of the PE that originates the 1466 (service) A-D route that carries this attribute, and the Local Number 1467 is a number that is unique to the Source PE. The length of the Local 1468 Number part is the same as the length of the Source PE Address. Thus 1469 if the Source PE Address is an IPv4 address, then the Local Number 1470 part is 4 octets, and if the Source PE Address is an IPv6 address, 1471 then the Local Number part is 16 octets. 1473 14.2. Discovering Leaves of the Inter-Area P2MP Service LSP 1475 When aggregating multiple P2MP LSPs using P2MP LSP hierarchy, 1476 determining the leaf nodes of the LSPs being aggregated is essential 1477 for being able to tradeoff the overhead due to the P2MP LSPs vs 1478 suboptimal use of bandwidth due to the partial congruency of the LSPs 1479 being aggregated. 1481 Therefore, if a PE that is a root of a given service P2MP LSP wants 1482 to aggregate this LSP with other (service) P2MP LSPs rooted at the 1483 same PE into an inter-area P2MP transport LSP, the PE should first 1484 determine all the leaf nodes of that service LSP, as well as those of 1485 the other service LSPs being aggregated). 1487 To accomplish this the PE sets the PMSI Tunnel attribute of the 1488 service A-D route (an I-PMSI or S-PMSI A-D route for MVPN or VPLS 1489 service) associated with that LSP as follows. The Tunnel Type is set 1490 to "No tunnel information present", Leaf Information Required flag is 1491 set to 1, the route MUST NOT carry the P2MP Segmented Next-Hop 1492 Extended Community. In contrast to the procedures for the MVPN and 1493 VPLS A-D routes described so far, the Route Reflectors that 1494 participate in the distribution of this route need not be ABRs. 1496 14.3. Discovering P2MP FEC of P2MP Transport LSP 1498 Once the ingress PE determines all the leaves of a given P2MP service 1499 LSP, the PE (using some local to the PE criteria) selects a 1500 particular inter-area transport P2MP LSP to be used for carrying the 1501 (inter-area) service P2MP LSP. 1503 Once the PE selects the transport P2MP LSP, the PE (re)originates the 1504 service A-D route. The PMSI Tunnel attribute of this route now 1505 carries the Tunnel Identifier of the selected transport LSP, with the 1506 Tunnel Type set to "Transport Tunnel". If the transport LSP carries 1507 multiple P2MP service LSPs, then the MPLS Label field in the 1508 attribute carries an upstream-assigned label assigned by the PE that 1509 is bound to the P2MP FEC of the inter-area P2MP service LSP. 1510 Otherwise, this field is set to Implicit NULL. 1512 Just as described earlier, this service A-D route MUST NOT carry the 1513 P2MP Segmented Next-Hop Extended Community. Just as described 1514 earlier, the Route Reflectors that participate in the distribution of 1515 this route need not be ABRs. 1517 14.4. Egress PE Procedures for P2MP Transport LSP 1519 When an egress PE receives and accepts an MVPN or VPLS service A-D 1520 route, if the Leaf Information Required flag in the PMSI Tunnel 1521 attribute of the received A-D route is set to 1, and the route does 1522 not carry the P2MP Segmented Next-Hop Extended Community, then the 1523 egress PE, following the "regular" MVPN or VPLS procedures associated 1524 with the received A-D route (as specified in [RFC6514] and [VPLS- 1525 P2MP]), originates a Leaf A-D route. 1527 In addition, if the Tunnel Type in the PMSI Tunnel attribute of the 1528 received service A-D route is set to "Transport Tunnel", the egress 1529 PE originates yet another Leaf A-D route. 1531 The format of the Route Key field of MCAST-VPN NLRI of this 1532 additional Leaf A-D route is the same as defined in section 6.2.2 1533 ("Leaf A-D Route for Global Table Multicast"). The Route Key field of 1534 MCAST-VPN NLRI of this route is constructed as follows: 1536 RD (8 octets) - set to 0 1538 Multicast Source Length, Multicast Source - constructed from 1539 the Source PE address part of the Tunnel Identifier carried 1540 in the PMSI Tunnel attribute of the received service S-PMSI 1541 A-D route. 1543 Multicast Group Length, Multicast Group - constructed from 1544 Local Number part of the Tunnel Identifier carried in the 1545 PMSI Tunnel attribute of the received service S-PMSI A-D 1546 route. 1548 Ingress PE IP Address is set to the Source PE address part 1549 of the Tunnel Identifier carried in the PMSI Tunnel attribute 1550 of the received service S-PMSI A-D route. 1552 The egress PE, when determining the upstream ABR, follows the 1553 procedures specified in section 6.1 ("Determining the Upstream 1554 ABR/PE/ASBR (Upstream Node)") for global table multicast. 1556 The egress PE constructs the rest of the Leaf A-D route following the 1557 procedures specified in section 6.2.3 ("Constructing the Rest of the 1558 Leaf A-D Route"). 1560 From that point on we follow the procedures used for the Leaf A-D 1561 routes for global table multicast, as outlined below. 1563 14.5. Egress/Ingress ABR, Ingress PE procedures for P2MP Transport LSP 1565 When an egress ABR receives the Leaf A-D route, and P2MP LSP is used 1566 to instantiate the egress area segment of the inter-area transport 1567 LSP, the egress ABR will advertise into the egress area an S-PMSI A-D 1568 route. This route is constructed following the procedures in section 1569 "Global Table Multicast and S-PMSI A-D Routes". The egress PE(s) will 1570 import this route. 1572 The egress ABR will also propagate, with appropriate modifications, 1573 the received Leaf A-D route into the backbone area. This is 1574 irrespective of whether the egress area segment is instantiated using 1575 P2MP LSP or ingress replication. 1577 If P2MP LSP is used to instantiate the backbone area segment of the 1578 inter-area transport LSP, then an ingress ABR will advertise into the 1579 backbone area an S-PMSI A-D route. This route is constructed 1580 following the procedures in section 7.1.2.1 ("Global Table Multicast 1581 and S-PMSI A-D Routes"). The egress ABR(s) will import this route. 1583 The ingress ABR will also propagate, with appropriate modifications, 1584 the received Leaf A-D route into the ingress area towards the 1585 ingress/root PE. This is irrespective of whether the backbone area 1586 segment is instantiated using P2MP LSP or ingress replication. 1588 Finally, if P2MP LSP is used to instantiate the ingress area segment, 1589 the ingress PE will advertise into the ingress area an S-PMSI A-D 1590 route with the RD, multicast source, and multicast group fields being 1591 the same as those in the received Leaf A-D route. The PMSI Tunnel 1592 attribute of this route contains the identity of the intra-area P2MP 1593 LSP used to instantiate the ingress area segment, and an upstream- 1594 assigned MPLS label. The ingress ABR(s) and other PE(s) in the 1595 ingress area, if any, will import this route. The ingress PE will use 1596 the (intra-area) P2MP LSP advertised in this route for carrying 1597 traffic associated with the original service A-D route advertised by 1598 the PE. 1600 14.6. Discussion 1602 Use of inter-area transport P2MP LSPs, as described in this section, 1603 creates a level of indirection between (inter-area) P2MP service 1604 LSPs, and intra-area transport LSPs that carry the service LSPs. 1605 Rather than segmenting (inter-area) service P2MP LSPs, and then 1606 aggregating (intra-area) segments of these service LSPs into intra- 1607 area transport LSPs, this approach first aggregates multiple (inter- 1608 area) service P2MP LSPs into a single inter-area transport P2MP LSP, 1609 then segments such inter-area transport P2MP LSPs, and then 1610 aggregates (intra-area) segments of these inter-area transport LSPs 1611 into intra-area transport LSPs. 1613 On one hand this approach could result in reducing the state (and the 1614 overhead associated with maintaining the state) on ABRs. This is 1615 because instead of requiring ABRs to maintain state for individual 1616 P2MP service LSPs, ABRs would need to maintain state only for the 1617 inter-area P2MP transport LSPs. Note however, that this reduction is 1618 possible only if a single inter-area P2MP transport LSP aggregates 1619 more than one (inter-area) service LSP. In the absence of such 1620 aggregation, use of inter-area transport LSPs provides no benefits, 1621 yet results in extra overhead. And while such aggregation does allow 1622 to reduce state on ABRs, it comes at a price, as described below. 1624 As we mentioned before, aggregating multiple P2MP service LSPs into a 1625 single inter-area P2MP transport LSP requires the PE rooted at these 1626 LSPs to determine all the leaf nodes of the service LSPs to be 1627 aggregated. This means that the root PE has to track all the leaf PEs 1628 of these LSPs. In contrast, when one applies segmentation procedures 1629 directly to the P2MP service LSPs, the root PE has to track only the 1630 leaf PEs in its own IGP area, plus the ingress ABR(s). Likewise, an 1631 ingress ABR has to track only the egress ABRs. Finally, an egress ABR 1632 has to track only the leaf PEs in its own area. Therefore, while the 1633 total overhead of leaf tracking due to the P2MP service LSPs is about 1634 the same in both approaches, the distribution of this overhead is 1635 different. Specifically, when one uses inter-area P2MP transport 1636 LSPs, this overhead is concentrated on the ingress PE. When one 1637 applies segmentation procedures directly to the P2MP service LSPs, 1638 this overhead is distributed among ingress PE and ABRs. 1640 Moreover, when one uses inter-area P2MP transport LSPs, ABRs have to 1641 bear the overhead of leaf tracking for inter-area P2MP transport 1642 LSPs. In contrast, when one applies segmentation procedures directly 1643 to the P2MP service LSPs, there is no such overhead (as there are no 1644 inter-area P2MP transport LSPs). 1646 Use of inter-area P2MP transport LSPs may also result in more 1647 bandwidth inefficiency, as compared to applying segmentation 1648 procedures directly to the P2MP service LSPs. This is because with 1649 inter-area P2MP transport LSPs the ABRs aggregate segments of inter- 1650 area P2MP transport LSPs, rather than segments of (inter-area) P2MP 1651 service LSPs. To illustrate this consider the following example. 1653 Assume PE1 in Area 1 is an ingress PE, with two multicast streams, 1654 (C-S1, C-G1) and (C-S2, C-G2), originated by an MVPN site connected 1655 to PE1. Assume that PE2 in Area 2 has an MVPN site with receivers for 1656 (C-S1, C-G1), PE3 and PE4 in Area 3 have an MVPN site with receivers 1657 both for (C-S1, C-G1) and for (C-S2, C-G2). Finally, assume that PE5 1658 in Area 4 has an MVPN site with receivers for (C-S2, C-G2). 1660 When segmentation applies directly to the P2MP service LSPs then Area 1661 2 would have just one intra-area transport LSP which would carry the 1662 egress area segment of the P2MP service LSP for (C-S1, C-G1); Area 3 1663 would have just one intra-area transport LSP which would carry the 1664 egress area segments of both the P2MP service LSP for (C-S1, C-G1) 1665 and the P2MP service LSP for (C-S2, C-G2); Area 4 would have just one 1666 intra-area transport LSP which would carry the egress area segment of 1667 the P2MP service LSP for (C-S2, C-G2). Note that there is no 1668 bandwidth inefficiency in this case at all. 1670 When using inter-area P2MP transport LSPs, to achieve the same state 1671 overhead on the routers within each of the egress areas (except for 1672 egress ABRs), PE1 would need to aggregate the P2MP service LSP for 1673 (C-S1, C-G1) and the P2MP service LSP for (C-S2, C-G2) into the same 1674 inter-area P2MP transport LSP. While such aggregation would reduce 1675 state on ABRs, it would also result in bandwidth inefficiency, as (C- 1676 S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but also 1677 to PE5, which has no receivers for this stream. Likewise, (C-S2, C- 1678 G2) will be delivered not just to PE3, PE4, and PE5, but also to PE2, 1679 which has no receivers for this stream. 1681 15. IANA Considerations 1683 This document defines a new BGP Extended Community called "Inter-area 1684 P2MP Segmented Next-Hop" (see section "Inter-area P2MP Segmented 1685 Next-Hop Extended Community"). This community is IP Address Specific, 1686 of an extended type, and is transitive. A codepoint for this 1687 community should be assigned both from the IPv4 Address Specific 1688 Extended Community registry, and from the IPv6 Address Specific 1689 Extended Community registry. The same code point should be assigned 1690 from both registries. 1692 This document also assigns a new Tunnel Type in the PMSI Tunnel 1693 Attribute, called the "Transport Tunnel" (see section "Transport 1694 Tunnel Type"). This Tunnel Type is assigned a value of 8. 1696 16. Security Considerations 1698 These will be spelled out in a future revision. 1700 17. Acknowledgements 1702 We would like to thank Eric Rosen for his comments. 1704 18. References 1706 18.1. Normative References 1708 [RFC1997] "BGP Communities Attribute", Ravi Chandra, et al., RFC1997, 1709 August 1996 1711 [RFC2119] "Key words for use in RFCs to Indicate Requirement 1712 Levels.", Bradner, March 1997 1714 [RFC4360] S. Sangle et. al., "BGP Extended Communities Attribute", 1715 RFC4360, February 2006 1717 [RFC4456] T. Bates et. al., "BGP Route Reflection: An Alternative to 1718 Full Mesh Internal BGP (IBGP)", RFC4456, April 2006 1720 [RFC4684] P. Marques et. al., "Constrained Route Distribution for 1721 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 1722 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 1723 November 2006 1725 [RFC4760] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 1726 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 1728 [RFC4761] Kompella, K., Rekhter, Y., "Virtual Private LAN Service 1729 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 1730 2007 1732 [RFC6368] "Internal BGP as PE-CE protocol", Pedro Marques, et al., 1733 RFC6368, September 2011 1735 [RFC5331] "MPLS Upstream Label Assignment and Context-Specific Label 1736 Space", Rahul Aggarwal, et al., RFC5331, August 2008 1738 [RFC5332] "MPLS Multicast Encapsulations", T. Eckert, E. Rosen, R. 1739 Aggarwal, Y. Rekhter, RFC5332, August 2008 1741 [RFC6514] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 1742 VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, RFC6514, February 1743 2012 1745 [RFC6074] "Provisioning, Auto-Discovery, and Signaling in Layer 2 1746 Virtual Private Networks (L2VPNs)", E. Rosen, B. Davie, V. Radoaca, 1747 W. Luo, RFC6074, January 2011 1749 [RFC6625] "Wildcards in Multicast VPN Auto-Discovery Routes", Eric 1750 Rosen, et al., RFC6625, May 2012 1752 [VPLS-P2MP] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang, 1753 draft-ietf-l2vpn-vpls-mcast, work in progress 1755 18.2. Informative References 1757 [SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al., 1758 draft-ietf-mpls-seamless-mpls, work in progress 1760 [virtual-hub-and-spoke] "Virtual Hub-and-Spoke in BGP/MPLS VPNs", 1761 Huajin Jeng et. al., draft-ietf-l3vpn-virtual-hub, work in progress 1763 19. Author's Address 1765 Yakov Rekhter 1766 Juniper Networks 1767 1194 North Mathilda Ave. 1768 Sunnyvale, CA 94089 1769 Email: yakov@juniper.net 1771 Rahul Aggarwal 1772 Email: raggarwa_1@yahoo.com 1774 Thomas Morin 1775 France Telecom R & D 1776 2, avenue Pierre-Marzin 1777 22307 Lannion Cedex 1778 France 1779 Email: thomas.morin@orange-ftgroup.com 1781 Irene Grosclaude 1782 France Telecom R & D 1783 2, avenue Pierre-Marzin 1784 22307 Lannion Cedex 1785 France 1786 Email: irene.grosclaude@orange-ftgroup.com 1788 Nicolai Leymann 1789 Deutsche Telekom AG 1790 Winterfeldtstrasse 21 1791 Berlin 10781 1792 DE 1793 Email: n.leymann@telekom.de 1795 Samir Saad 1796 AT&T 1797 Email: ss2539@att.com