idnits 2.17.1 draft-ietf-l2vpn-vpls-mcast-16.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC4761], [RFC4762]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Aggarwal (Editor) 3 Internet Draft Juniper Networks 4 Category: Proposed Standard 5 Expiration Date: May 2014 Y. Kamite 6 NTT Communications 8 L. Fang 9 Cisco Systems, Inc 11 November 22 2013 13 Multicast in VPLS 15 draft-ietf-l2vpn-vpls-mcast-16.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright and License Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Abstract 66 [RFC4761] and [RFC4762] describe a solution for Virtual Private LAN 67 Service (VPLS) multicast that relies on the use of point-to-point or 68 multipoint-to-point unicast Label Switched Paths (LSPs) for carrying 69 multicast traffic. This solution has certain limitations for certain 70 VPLS multicast traffic profiles. For example, it may result in highly 71 non-optimal bandwidth utilization when large amount of multicast 72 traffic is to be transported. 74 This document describes solutions for overcoming a subset of the 75 limitations of existing VPLS multicast solution. It describes 76 procedures for VPLS multicast that utilize multicast trees in the 77 service provider (SP) network. The solution described in this 78 document allows sharing of one such multicast tree among multiple 79 VPLS instances. Furthermore, the solution described in this document 80 allows a single multicast tree in the SP network to carry traffic 81 belonging only to a specified set of one or more IP multicast streams 82 from one or more VPLS instances. 84 Table of Contents 86 1 Specification of requirements ......................... 4 87 2 Contributors .......................................... 4 88 3 Terminology ........................................... 5 89 4 Introduction .......................................... 5 90 5 Overview .............................................. 6 91 5.1 Inclusive and Selective Multicast Trees ............... 7 92 5.2 BGP-Based VPLS Membership Auto-Discovery .............. 8 93 5.3 IP Multicast Group Membership Discovery ............... 9 94 5.4 Advertising P-Multicast Tree to VPLS/C-Multicast Binding 10 95 5.5 Aggregation ........................................... 11 96 5.6 Inter-AS VPLS Multicast ............................... 12 97 6 Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding 12 98 6.1 Originating intra-AS VPLS A-D routes .................. 13 99 6.2 Receiving intra-AS VPLS A-D routes .................... 14 100 7 Demultiplexing P-Multicast Tree Traffic ............... 15 101 7.1 One P-Multicast Tree - One VPLS Mapping ............... 15 102 7.2 One P-Multicast Tree - Many VPLS Mapping .............. 15 103 8 Establishing P-Multicast Trees ........................ 16 104 8.1 Common Procedures ..................................... 16 105 8.2 RSVP-TE P2MP LSPs ..................................... 17 106 8.2.1 P2MP TE LSP - VPLS Mapping ............................ 17 107 8.3 Receiver Initiated P2MP LSP ........................... 18 108 8.3.1 P2MP LSP - VPLS Mapping ............................... 18 109 8.4 Encapsulation of Aggregate P-Multicast Trees .......... 19 110 9 Inter-AS Inclusive P-Multicast Tree A-D/Binding ....... 19 111 9.1 VSIs on the ASBRs ..................................... 19 112 9.1.1 Option (a): VSIs on the ASBRs ......................... 20 113 9.1.2 Option (e): VSIs on the ASBRs ......................... 20 114 9.2 Option (b) - Segmented Inter-AS Trees ................. 20 115 9.2.1 Segmented Inter-AS Trees VPLS Inter-AS A-D/Binding .... 21 116 9.2.2 Propagating BGP VPLS A-D routes to other ASes: Overview 22 117 9.2.2.1 Propagating Intra-AS VPLS A-D routes in EBGP .......... 23 118 9.2.2.2 Inter-AS A-D route received via EBGP .................. 24 119 9.2.2.3 Leaf A-D Route received via EBGP ...................... 26 120 9.2.2.4 Inter-AS A-D Route received via IBGP .................. 26 121 9.3 Option (c): Non-Segmented Tunnels ..................... 27 122 10 Optimizing Multicast Distribution via Selective Trees . 28 123 10.1 Protocol for Switching to Selective Trees ............. 29 124 10.2 Advertising (C-S, C-G) Binding to a Selective Tree .... 31 125 10.3 Receiving S-PMSI A-D routes by PEs .................... 33 126 10.4 Inter-AS Selective Tree ............................... 35 127 10.4.1 VSIs on the ASBRs ..................................... 35 128 10.4.1.1 VPLS Inter-AS Selective Tree A-D Binding .............. 36 129 10.4.2 Inter-AS Segmented Selective Trees .................... 36 130 10.4.2.1 Handling S-PMSI A-D routes by ASBRs ................... 36 131 10.4.2.1.1 Merging Selective Tree into an Inclusive Tree ......... 37 132 10.4.3 Inter-AS Non-Segmented Selective trees ................ 38 133 11 BGP Extensions ........................................ 39 134 11.1 Inclusive Tree/Selective Tree Identifier .............. 39 135 11.2 MCAST-VPLS NLRI ....................................... 39 136 11.2.1 S-PMSI A-D route ...................................... 40 137 11.2.2 Leaf A-D route ........................................ 41 138 12 Aggregation Considerations ............................ 42 139 13 Data Forwarding ....................................... 43 140 13.1 MPLS Tree Encapsulation ............................... 43 141 13.1.1 Mapping multiple VPLS instances to a P2MP LSP ......... 43 142 13.1.2 Mapping one VPLS instance to a P2MP LSP ............... 44 143 14 VPLS Data Packet Treatment ............................ 45 144 15 Security Considerations ............................... 46 145 16 IANA Considerations ................................... 47 146 17 Acknowledgments ....................................... 48 147 18 Normative References .................................. 48 148 19 Informative References ................................ 49 149 20 Author's Address ...................................... 50 151 1. Specification of requirements 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 2. Contributors 159 Yakov Rekhter 160 Juniper Networks 161 Chaitanya Kodeboniya 163 3. Terminology 165 This document uses terminology described in [RFC4761] and [RFC4762]. 167 In this document we refer to various auto-discovery routes, as "A-D 168 routes". 170 This document uses the prefix 'C' to refer to the customer control or 171 data packets and 'P' to refer to the provider control or data 172 packets. An IP (multicast source, multicast group) tuple is 173 abbreviated to (S, G). 175 An "Inclusive tree" is a single multicast distribution tree in the 176 Service Provider network that carries all the multicast traffic from 177 one VPLS instance on a given PE. 179 An "Aggregate Inclusive tree" is a single multicast distribution tree 180 in the Service Provider network that carries all the multicast 181 traffic from more than one VPLS instance on a given PE. 183 A "Selective tree" is a single multicast distribution tree in the 184 Service Provider network that carries multicast traffic belonging 185 only to a specified set of IP multicast streams, and all these 186 streams belong to the same VPLS instance on a given PE. 188 An "Aggregate Selective tree" is a single multicast distribution tree 189 in the Service Provider network that carries multicast traffic 190 belonging only to a specified set of IP multicast streams, and all 191 these streams belong to more than one VPLS instance on a given PE. 193 4. Introduction 195 [RFC4761] and [RFC4762] describe a solution for VPLS 196 multicast/broadcast that relies on the use of pseudowires transported 197 over unicast point-to-point (P2P) RSVP-TE or multipoint-to-point 198 (MP2P) LDP Label Switched Paths (LSPs) ([RFC3209], [RFC5036]). In 199 this document we refer to this solution as "ingress replication". 201 With ingress replication when an ingress PE of a given VPLS instance 202 receives a multicast/broadcast packet from one of the CEs that belong 203 to that instance, the ingress PE replicates the packet for each 204 egress PE that belong to that instance, and sends the packet to each 205 such egress PE using unicast tunnels. 207 The solution based on ingress replication has certain limitations for 208 certain VPLS multicast/broadcast traffic profiles. For example, it 209 may result in highly non-optimal bandwidth utilization in the MPLS 210 network when a large amount of multicast/broadcast traffic is to be 211 transported (for more see [RFC5501]). 213 Ingress replication may be an acceptable model when the bandwidth of 214 the multicast/broadcast traffic is low and/or there is a small number 215 of replications performed on each outgoing interface for a particular 216 VPLS customer multicast stream. If this is not the case, it is 217 desirable to utilize multicast trees in the SP network to transmit 218 VPLS multicast and/or broadcast packets [RFC5501]. 220 This document describes procedures for overcoming the limitations of 221 existing VPLS multicast solutions. It describes procedures for using 222 MPLS point-to-multipoint (P2MP) LSPs in the Service Provider (SP) 223 network to transport VPLS multicast and/or broadcast packets, where 224 these LSPs are signaled by either P2MP RSVP-TE [RFC4875] or mLDP 225 [RFC6388]. 227 The procedures described in this document are applicable to both 228 [RFC4761] and [RFC4762]. 230 5. Overview 232 Procedures described in this document provide mechanisms that allow a 233 single multicast distribution tree in the Service Provider (SP) 234 network to carry all the multicast traffic from one or more VPLS 235 sites connected to a given PE, irrespective of whether these sites 236 belong to the same or different VPLS instances. We refer to such a 237 tree as an "Inclusive tree" if it carries multicast traffic from one 238 VPLS instance on a given PE. We refer to such a tree as an "Aggregate 239 Inclusive tree" if it carries multicast traffic from more than one 240 VPLS instance on a given PE. See section "Inclusive and Selective 241 Multicast Trees" for further discussion on Inclusive trees. 243 To further improve bandwidth utilization for IP multicast streams, 244 this document also provides procedures by which a single multicast 245 distribution tree in the SP network can be used to carry traffic 246 belonging only to a specified set of IP multicast streams, originated 247 in one or more VPLS sites connected to a given PE, irrespective of 248 whether these sites belong to the same or different VPLS instances. 249 We refer to such a tree as a "Selective tree" if it carries the IP 250 multicast stream(s) that belong to the same VPLS instance on a given 251 PE. We refer to such a tree as as an "Aggregate Selective tree" if it 252 carries the IP multicast streams that belong to different VPLS 253 instances on a given PE. Use of Selective and/or Aggregate Selective 254 trees allows multicast traffic, by default, to be carried on an 255 Inclusive tree, while traffic from some specific IP multicast 256 streams, e.g., high bandwidth streams, could be carried on one of the 257 Selective trees. See section "Inclusive and Selective Multicast 258 Trees" for further discussion on Selective trees. 260 Note that this document covers the use of Selective trees only for 261 carrying IP multicast streams. Any other use of such trees is outside 262 the scope of this document. 264 Unicast packets destined to unknown MAC addresses (i.e., not learned 265 yet at the ingress PE) in a given VPLS instance are flooded to remote 266 PEs participating in the same VPLS instance. This flooding MAY still 267 use ingress replication (as specified in [RFC4761], [RFC4762]), or 268 MAY use the procedures defined in this document to optimize flooding 269 across the SP core. 271 While the use of multicast trees in the SP network can be beneficial 272 when the bandwidth of the multicast traffic is high, or when it is 273 desirable to optimize the number of copies of a multicast packet 274 transmitted on a given link, this benefit comes at a cost of state in 275 the SP network to build multicast trees and overhead to maintain this 276 state. 278 5.1. Inclusive and Selective Multicast Trees 280 Multicast trees used for VPLS can be of two types: 282 + Inclusive trees. This option supports the use of a single 283 multicast distribution tree, referred to as an Inclusive P- 284 Multicast tree, in the SP network to carry all the multicast 285 traffic from a specified set of VPLS sites connected to a given 286 PE. There is no assumption made with respect to whether this 287 traffic is IP encapsulated or not. A particular P-Multicast tree 288 can be set up to carry the traffic originated by sites belonging 289 to a single VPLS instance, or to carry the traffic originated by 290 sites belonging to different VPLS instances. The ability to 291 carry the traffic of more than one VPLS instance on the same tree 292 is termed Aggregation. The tree needs to include every PE that is 293 a member of any of the VPLS instances that are using the tree. 294 This implies that a PE may receive multicast traffic for a 295 multicast stream even if it doesn't have any receivers that are 296 interested in receiving traffic for that stream. 298 An Inclusive P-Multicast tree as defined in this document is a 299 P2MP tree. Thus, a P2MP tree is used to carry traffic only from 300 VPLS sites that are connected to the PE that is the root of the 301 tree. 303 + Selective trees. A Selective P-Multicast tree is used by a PE to 304 send IP multicast traffic for one or more specific IP multicast 305 streams, received by the PE over PE-CE interfaces that belong to 306 the same or different VPLS instances, to a subset of the PEs that 307 belong to those VPLS instances. Each of the PEs in the subset 308 should be on the path to a receiver of one or more multicast 309 streams that are mapped onto the tree. The ability to use the 310 same tree for multicast streams that belong to different VPLS 311 instances is termed Aggregation. The reason for having Selective 312 P-Multicast trees is to provide a PE the ability to create 313 separate SP multicast trees for specific multicast streams, e.g. 314 high bandwidth multicast streams. This allows traffic for these 315 multicast streams to reach only those PE routers that have 316 receivers for these streams. This avoids flooding other PE 317 routers in the VPLS instance. 319 A SP can use both Inclusive P-Multicast trees and Selective P- 320 Multicast trees or either of them for a given VPLS on a PE, based on 321 local configuration. Inclusive P-Multicast trees can be used for both 322 IP and non-IP data multicast traffic, while Selective P-Multicast 323 trees, as previousely state, must be used only for IP multicast data 324 traffic. The use of Selective P-Multicast trees for non-IP multicast 325 traffic is outside the scope of this document. 327 P-Multicast trees in the SP network can be realized via a variety of 328 technologies. For both inclusive and selective P-Multicast trees, 329 these technologies include P2MP LSPs created by RSVP-TE or mLDP. 330 This document also describes the data plane encapsulations for 331 supporting these technologies. Other technologies for realizing P- 332 Multicast trees are outside the scope of this document. 334 5.2. BGP-Based VPLS Membership Auto-Discovery 336 In order to establish Inclusive P-Multicast trees for one or more 337 VPLS instances, when aggregation is performed (with either mLDP or 338 P2MP RSVP-TE as the tunneling technology), or when the tunneling 339 technology is P2MP RSVP-TE, the PE acting as a root of a P2MP LSP 340 must be able to discover the other PEs that have membership of these 341 VPLS instances. Once the root PE discovers these other PEs, it 342 includes them as leaves in the P-multicast tree (i.e., P2MP LSP) This 343 document uses the BGP-based procedures described in [RFC4761] and 344 [RFC6074] for discovering the VPLS membership of all PEs. For more on 345 aggregation see section "Aggregation Considerations". When no 346 aggregation is performed and the tunneling technology is mLDP, then 347 the root of the P2MP LSP need not discover the other PEs that are the 348 leaves of that LSP. 350 The leaves of the Inclusive P-Multicast tree must also be able to 351 auto-discover the identifier of the tree (note that this applies when 352 the tree is established by either mLDP or P2MP RSVP-TE). Procedures 353 to accomplish this are described in section "Advertising P-Multicast 354 Tree to VPLS/C-Multicast Binding". 356 5.3. IP Multicast Group Membership Discovery 358 The setup of a Selective P-Multicast tree for one or more IP 359 multicast (C-S, C-G)s, requires the ingress PE to learn the PEs that 360 have receivers in one or more of these (C-S, C-G)s, in the following 361 cases: 363 + When aggregation is used (with either mLDP or P2MP RSVP-TE as the 364 tunneling technology), OR 366 + When the tunneling technology is P2MP RSVP-TE 368 + If ingress replication is used and the ingress PE wants to send 369 traffic for (C-S, C-G)s to only those PEs that are on the path to 370 receivers for the (C-S,C-G)s. 372 For more on aggregation see section "Aggregation Considerations". 374 For discovering the IP multicast group membership, this document 375 describes procedures that allow an ingress PE to enable explicit 376 tracking of IP multicast membership. Thus, an ingress PE can request 377 the IP multicast membership from egress PEs for one or more C- 378 multicast streams. These procedures are described in section 379 "Optimizing Multicast Distribution via Selective Trees". 381 These procedures are applicable when IGMP ([RFC2236], [RFC3376]) or 382 MLD ([RFC2710], [RFC3810]) is used as the multicast signaling 383 protocol between the VPLS CEs. They are also applicable when PIM 384 ([RFC4601]) in either the ASM (Any-Source Multicast) or the SSM 385 (Source-Specific Multicast) service model is used as the multicast 386 routing protocol between the VPLS CEs, and PIM join suppression is 387 disabled on all the CEs. 389 However these procedures do not apply when PIM is used as the 390 multicast routing protocol between the VPLS CEs and PIM join 391 suppression is not disabled on all the CEs. This is because when PIM 392 join suppression is not disabled on all the CEs, PEs connected to 393 these CEs can not rely on PIM to determine IP multicast membership of 394 the receivers behind these CEs. Procedures for this case are outside 395 the scope of this document. 397 The leaves of the Selective P-Multicast trees must also be able to 398 discover the identifier of these trees. Procedures to accomplish this 399 are described in section "Advertising P-Multicast Tree to VPLS/C- 400 Multicast Binding". 402 5.4. Advertising P-Multicast Tree to VPLS/C-Multicast Binding 404 This document describes procedures based on BGP VPLS Auto-Discovery 405 (A-D) routes ([RFC4761],[RFC6074]) that are used by the root of an 406 Aggregate P-Multicast tree to advertise the Inclusive or Selective P- 407 Multicast tree binding and the de-multiplexing information to the 408 leaves of the tree. This document uses the Provider Multicast Service 409 Interface (PMSI) Tunnel attribute defined [RFC6514] for this purpose. 411 Once an ingress PE decides to bind a set of VPLS instances or 412 customer multicast groups to an Inclusive P-Multicast tree or a 413 Selective P-Multicast tree, the PE needs to announce this binding to 414 other PEs in the network. This procedure is referred to as Inclusive 415 P-Multicast tree or Selective P-Multicast tree binding distribution 416 and is performed using BGP. The decision to bind a set of VPLS 417 instances or customer multicast group is a local matter to the 418 ingress, and is controlled via provisioning/configuration on that PE. 420 When an Aggregated Inclusive P-Multicast tree is used by an ingress 421 PE, this binding distribution implies that (a) an ingress PE MUST 422 announce the binding of all VPLS instances bound to the Inclusive P- 423 Multicast tree, and (b) other PEs that have these instances receive 424 these announcements. The inner label assigned by the ingress PE for 425 each VPLS MUST be included if more than one VPLS is bound to the same 426 P-Multicast tree. The Inclusive P-Multicast tree Identifier MUST be 427 included. 429 For a Selective P-Multicast tree this binding distribution implies 430 announcing all the specific entries bound to this P- 431 Multicast tree along with the Selective P-Multicast tree Identifier. 432 The inner label assigned for each MUST be included if s from different VPLS instances are bound to the same P- 434 Multicast tree. The labels MUST be distinct on a per VPLS basis and 435 MAY be distinct on a per basis. The Selective P-Multicast 436 tree Identifier MUST be included. 438 5.5. Aggregation 440 As described earlier in this document, the ability to carry the 441 traffic of more than one VPLS on the same P-Multicast tree is termed 442 aggregation. 444 Aggregation enables the SP to place a bound on the amount of 445 multicast tree forwarding and control plane state which the P routers 446 must have. Let us call the number of VPLS instances aggregated onto a 447 single P-Multicast tree as the "Aggregation Factor". When Inclusive 448 source P-Multicast trees are used the number of trees that a PE is 449 the root of is proportional to Number of VPLS instances on the PE 450 divided by the Aggregation Factor. 452 In this case the state maintained by a P router, is proportional to: 454 AveVPLS NPE 455 ------- X -------- 456 Aggr AvePTree 458 Where: 460 AveVPLS is the average number of VPLS instances on a PE 462 Aggr is the aggregation factor 464 NPE is the number of PEs 466 AvePTree is the average number of P-multicast that transit 467 a given P-router 469 Thus, the state does not grow linearly with the number of VPLS 470 instances. 472 Aggregation requires a mechanism for the egresses of the P-Multicast 473 tree to demultiplex the multicast traffic received over the P- 474 Multicast tree. To enable the egress nodes to perform this 475 demultiplexing, upstream-assigned labels [RFC5331] MUST be assigned 476 and distributed by the root of the aggregate P-multicast tree. 478 Aggregation procedures would require two MPLS labels in the label 479 stack. This does not introduce any new implications on MTU, as even 480 VPLS multicast supported by ingress replication requires two MPLS 481 labels in the label stack. 483 5.6. Inter-AS VPLS Multicast 485 This document defines four models of inter-AS VPLS service, referred 486 here as option (a), (b), (c), and (e). Options (a), (b), and (c) 487 defined in this document are very similar to the three methods, 488 method (a), method (b), and method (c), described in section "Multi- 489 AS VPLS" [RFC4761], which in turn extends the concepts of [RFC4364] 490 to inter-AS VPLS. 492 For option (a) and option (b) support, this document specifies a 493 model where Inter-AS VPLS service can be offered without requiring a 494 single P-Multicast tree to span multiple ASes. There are two variants 495 of this model and they are described in section "Inter-AS Inclusive 496 P-Multicast Tree A-D/Binding". 498 For option (c) support this document specifies a model where Inter-AS 499 VPLS service is offered by requiring a single P-Multicast tree to 500 span multiple ASes. This is because in the case of option (c) the 501 ASBRs do not exchange BGP-VPLS NLRIs or A-D routes. 503 In addition to options (a), (b), and (c), this document also 504 specifies option (e), which one may think of as a variant of option 505 (a). 507 For more on these inter-AS options see section "Inter-AS Inclusive P- 508 Multicast Tree A-D/Binding". 510 6. Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding 512 This section specifies procedures for the intra-AS auto-discovery of 513 VPLS membership and the distribution of information used to 514 instantiate P-Multicast Tunnels. 516 VPLS auto-discovery/binding consists of two components: intra-AS and 517 inter-AS. The former provides VPLS auto-discovery/binding within a 518 single AS. The latter provides VPLS auto-discovery/binding across 519 multiple ASes. Inter-AS auto-discovery/binding is described in 520 section "Inter-AS Inclusive P-Multicast Tree A-D/Binding". 522 VPLS auto-discovery using BGP as described in [RFC4761, RFC6074] 523 enables a PE to learn the VPLS instance membership of other PEs. A PE 524 that belongs to a particular VPLS instance announces a BGP Network 525 Layer Reachability Information (NLRI) that identifies the Virtual 526 Switch Instance (VSI). This NLRI is constructed from the tuple. The 528 NLRI defined in [RFC4761] comprises the tuple and label 529 blocks for pseudo-wire (PW) signaling. The VE-ID in this case is a 530 two octet number. The NLRI defined in [RFC6074] comprises only the 531 where the VE-ID is a four octet number. 533 The procedures for constructing Inclusive intra-AS and inter-AS trees 534 as specified in this document require the BGP A-D NLRI to carry only 535 the . Hence these procedures can be used for both BGP-VPLS 536 and LDP-VPLS with BGP A-D. 538 It is to be noted that BGP A-D is an inherent feature of BGP-VPLS. 539 However it is not an inherent feature of LDP-VPLS. In fact there are 540 deployments and/or implementations of LDP-VPLS that require 541 configuration to enable a PE in a particular VPLS to determine other 542 PEs in the VPLS and exchange PW labels using FEC 128 (PWid FEC) 543 [RFC4447]. The use of BGP A-D for LDP-VPLS [RFC6074], to enable 544 automatic setup of PWs, requires FEC 129 (Generalized PWid FEC) 545 [RFC4447]. However FEC 129 is not required in order to use procedures 546 in this document for LDP-VPLS. An LDP-VPLS implementation that 547 supports this document MUST support the BGP A-D procedures to setup 548 P-Multicast trees, as described here, and it MAY support FEC 129 to 549 automate the signaling of PWs. 551 6.1. Originating intra-AS VPLS A-D routes 553 To participate in the VPLS auto-discovery/binding a PE router that 554 has a given VSI of a given VPLS instance originates a BGP VPLS intra- 555 AS A-D route and advertises this route in Multi-Protocol (MP) IBGP. 556 The route is constructed as described in [RFC4761] and [RFC6074]. 558 The route carries a single L2VPN NLRI with the RD set to the RD of 559 the VSI, and the VE-ID set to the VE-ID of the VSI. The route also 560 carries one or more Route Targets (RTs) as specified in [RFC4761] and 561 [RFC6074]. 563 If an Inclusive P-Multicast tree is used to instantiate the provider 564 tunnel for VPLS multicast on the PE, the advertising PE MUST 565 advertise the type and the identity of the P-Multicast tree in the 566 PMSI Tunnel attribute. This attribute is described in section 567 "Inclusive Tree/Selective Tree Identifier". 569 A PE that uses an Inclusive P-Multicast tree to instantiate the 570 provider tunnel MAY aggregate two or more VPLS instances present on 571 the PE onto the same tree. If the PE decides to perform aggregation 572 after it has already advertised the intra-AS VPLS A-D routes for 573 these VPLS instances, then aggregation requires the PE to re- 574 advertise these routes. The re-advertised routes MUST be the same as 575 the original ones, except for the PMSI Tunnel attribute (the re- 576 advertised route will replace of the previously advertised route). If 577 the PE has not previously advertised intra-AS A-D routes for these 578 VPLS instances, then the aggregation requires the PE to advertise 579 (new) intra-AS A-D routes for these VPLS instances. The PMSI 580 attribute in the newly advertised/re-advertised routes MUST carry the 581 identity of the P-Multicast tree that aggregates the VPLS instances, 582 as well as an MPLS upstream-assigned label [RFC5331]. Each re- 583 advertised or newly advertised route MUST have a label that is 584 distinct within the scope of the PE that advertises the route. 586 Discovery of PE capabilities in terms of what tunnels types they 587 support is outside the scope of this document. Within a given AS PEs 588 participating in a VPLS are expected to advertise tunnel bindings 589 whose tunnel types are supported by all other PEs that are 590 participating in this VPLS and are part of the same AS. 592 6.2. Receiving intra-AS VPLS A-D routes 594 When a PE receives a BGP Update message that carries an intra-AS A-D 595 route such that (a) the route was originated by some other PE within 596 the same AS as the local PE, (b) at least one of the Route Targets of 597 the route matches one of the import Route Targets configured for a 598 particular VSI on the local PE, (c) the BGP route selection 599 determines that this is the best route with respect to the NLRI 600 carried by the route, and (d) the route carries the PMSI Tunnel 601 attribute, the PE performs the following: 603 + If the Tunnel Type in the PMSI Tunnel attribute is set to LDP 604 P2MP LSP, the PE SHOULD join the P-Multicast tree whose identity 605 is carried in the PMSI Tunnel attribute. 607 + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE 608 P2MP LSP, the receiving PE has to establish the appropriate state 609 to properly handle the traffic received over that LSP. The PE 610 that originated the route MUST establish an RSVP-TE P2MP LSP with 611 the local PE as a leaf. This LSP MAY have been established before 612 the local PE receives the route. 614 + If the PMSI Tunnel attribute does not carry a label, then all 615 packets that are received on the P-Multicast tree, as identified 616 by the PMSI Tunnel attribute, are forwarded using the VSIs that 617 have at least one of its import Route Targets that matches one of 618 the Route Targets of the received A-D route. 620 + If the PMSI Tunnel attribute has the Tunnel Type set to LDP P2MP 621 LSP or RSVP-TE P2MP LSP, and the attribute also carries an MPLS 622 label, then the egress PE MUST treat this as an upstream-assigned 623 label, and all packets that are received on the P-Multicast tree, 624 as identified by the PMSI Tunnel attribute, with that upstream 625 label are forwarded using the VSIs that have at least one of its 626 import Route Target that matches one of the Route Targets of the 627 received intra-AS A-D route. 629 Furthermore, if the local PE uses RSVP-TE P2MP LSP for sending 630 (multicast) traffic, originated by VPLS sites connected to the PE, to 631 the sites attached to other PEs then the local PE MUST use the 632 Originating Router's IP address information carried in the intra-AS 633 A-D route to add the PE, that originated the route, as a leaf node to 634 the LSP. This MUST be done irrespective of whether the received 635 Intra-AS A-D route carries the PMSI Tunnel attribute or not. 637 7. Demultiplexing P-Multicast Tree Traffic 639 Demultiplexing received VPLS traffic requires the receiving PE to 640 determine the VPLS instance the packet belongs to. The egress PE can 641 then perform a VPLS lookup to further forward the packet. It also 642 requires the egress PE to determine the identity of the ingress PE 643 for MAC learning, as described in section "VPLS Data Packet 644 Treatment". 646 7.1. One P-Multicast Tree - One VPLS Mapping 648 When a P-Multicast tree is mapped to only one VPLS, determining the 649 tree on which the packet is received is sufficient to determine the 650 VPLS instance on which the packet is received. The tree is determined 651 based on the tree encapsulation. If MPLS encapsulation is used, 652 e.g.,: RSVP-TE P2MP LSPs, the outer MPLS label is used to determine 653 the tree. Penultimate-hop-popping MUST be disabled on the MPLS LSP 654 (RSVP-TE P2MP LSP or mLDP P2MP LSP). 656 7.2. One P-Multicast Tree - Many VPLS Mapping 658 As traffic belonging to multiple VPLS instances can be carried over 659 the same tree, there is a need to identify the VPLS the packet 660 belongs to. This is done by using an inner label that determines the 661 VPLS for which the packet is intended. The ingress PE uses this label 662 as the inner label while encapsulating a customer multicast data 663 packet. Each of the egress PEs must be able to associate this inner 664 label with the same VPLS and use it to demultiplex the traffic 665 received over the Aggregate Inclusive tree or the Aggregate Selective 666 tree. 668 If traffic from multiple VPLS instances is carried on a single tree, 669 upstream-assigned labels [RFC5331] MUST be used. Hence the inner 670 label is assigned by the ingress PE. When the egress PE receives a 671 packet over an Aggregate tree, the outer encapsulation (in the case 672 of MPLS P2MP LSPs, the outer MPLS label) specifies the label space to 673 perform the inner label lookup. The same label space MUST be used by 674 the egress PE for all P-Multicast trees that have the same root 675 [RFC5331]. 677 If the tree uses MPLS encapsulation, as in RSVP-TE P2MP LSPs, the 678 outer MPLS label and optionally the incoming interface provides the 679 label space of the label beneath it. This assumes that penultimate- 680 hop-popping is disabled. The egress PE MUST NOT advertise IMPLICIT 681 NULL or EXPLICIT NULL for that tree once it is known to the egress PE 682 that the tree is bound to one or more VPLS instances. Once the label 683 representing the tree is popped off the MPLS label stack, the next 684 label is the demultiplexing information that allows the proper VPLS 685 instance to be determined. 687 The ingress PE informs the egress PEs about the inner label as part 688 of the tree binding procedures described in section "BGP Extensions". 690 8. Establishing P-Multicast Trees 692 This document supports only P2MP P-Multicast trees wherein it is 693 possible for egress PEs to identify the ingress PE to perform MAC 694 learning. Specific procedures are specified only for RSVP-TE P2MP 695 LSPs and mLDP P2MP LSPs. An implementation that supports this 696 document MUST support RSVP-TE P2MP LSPs and mLDP P2MP LSPs. 698 8.1. Common Procedures 700 The following procedures apply to both RSVP-TE P2MP and mLDP P2MP 701 LSPs. 703 Demultiplexing the C-multicast data packets at the egress PE requires 704 that the PE must be able to determine the P2MP LSP that the packets 705 are received on. This enables the egress PE to determine the VPLS 706 instances that the packet belongs to. To achieve this the LSP MUST be 707 signaled with penultimate-hop-popping (PHP) off and a non special 708 purpose MPLS label off as described in section "Demultiplexing P- 709 Multicast Tree Traffic". In other words an egress PE MUST NOT 710 advertise IMPLICIT NULL or EXPLICIT NULL for a P2MP LSP that is 711 carrying traffic for one or more VPLS instances. This is because the 712 egress PE needs to rely on the MPLS label, that it advertises to its 713 upstream neighbor, to determine the P2MP LSP that a C-multicast data 714 packet is received on. 716 The egress PE also needs to identify the ingress PE to perform MAC 717 learning. When P2MP LSPs are used as P2MP trees, determining the P2MP 718 LSP that the packets are received on, is sufficient to determine the 719 ingress PE. This is because the ingress PE is the root of the P2MP 720 LSP. 722 The egress PE relies on receiving the PMSI Tunnel attribute in BGP to 723 determine the VPLS instance to P2MP LSP mapping. 725 8.2. RSVP-TE P2MP LSPs 727 This section describes procedures that are specific to the usage of 728 RSVP-TE P2MP LSPs for instantiating a P-Multicast tree. Procedures in 729 [RFC4875] are used to signal the P2MP LSP. The LSP is signaled as the 730 root of the P2MP LSP discovers the leaves. The egress PEs are 731 discovered using the procedures described in section "Intra-AS 732 Inclusive P-Multicast Tree Auto-discovery/Binding". Aggregation as 733 described in this document is supported. 735 8.2.1. P2MP TE LSP - VPLS Mapping 737 P2MP TE LSP to VPLS mapping is learned at the egress PEs using BGP 738 based advertisements of the P2MP TE LSP - VPLS mapping. They require 739 that the root of the tree include the P2MP TE LSP identifier as the 740 tunnel identifier in the BGP advertisements. This identifier contains 741 the following information elements: 743 - The type of the tunnel is set to RSVP-TE P2MP LSP 744 - RSVP-TE P2MP LSP's SESSION Object 746 This Tunnel Identifier is described in section "Inclusive 747 Tree/Selective Tree Identifier". 749 Once the egress PE receives the P2MP TE LSP to VPLS mapping: 751 + If the egress PE already has RSVP-TE state for the P2MP TE LSP, 752 it MUST begin to assign an MPLS label from the non special 753 purpose label range, for the P2MP TE LSP and signal this to the 754 previous hop of the P2MP TE LSP. Further it MUST create 755 forwarding state to forward packets received on the P2MP LSP. 757 + If the egress PE does not have RSVP-TE state for the P2MP TE LSP, 758 it MUST retain this mapping. Subsequently when the egress PE 759 receives the RSVP-TE P2MP signaling message, it creates the RSVP- 760 TE P2MP LSP state. It MUST then assign an MPLS label from the 761 non-reserved label range, for the P2MP TE LSP, and signal this to 762 the previous hop of the P2MP TE LSP. 764 Note that if the signaling to set up an RSVP-TE P2MP LSP is 765 completed before a given egress PE learns, via a PMSI Tunnel 766 attribute, of the VPLS or set of VPLS instances to which the LSP 767 is bound, the PE MUST discard any traffic received on that LSP 768 until the binding is received. In order for the egress PE to be 769 able to discard such traffic it needs to know that the LSP is 770 associated with one or more VPLS instances and that the VPLS A-D 771 route that binds the LSP to a VPLS has not yet been received. 772 This is provided by extending [RFC4875] with [RFC6511]. 774 8.3. Receiver Initiated P2MP LSP 776 Receiver initiated P2MP LSPs can also be used. The mLDP procedures 777 ([RFC6388]) MUST be used to signal such LSPs. The LSP is signaled 778 once the leaves receive the LDP FEC for the tree from the root, as 779 described in section "Intra-AS Inclusive P-Multicast Tree Auto- 780 discovery/Binding". When aggregation is used, an ingress PE is 781 required to discover the egress PEs (see section "Aggregation 782 Considerations" for the rationale), and this is achieved using the 783 procedures in section "Intra-AS Inclusive P-Multicast Tree Auto- 784 discovery/Binding". 786 8.3.1. P2MP LSP - VPLS Mapping 788 P2MP LSP to VPLS mapping is learned at the egress PEs using BGP based 789 advertisements of the P2MP LSP - VPLS mapping. They require that the 790 root of the tree include the P2MP LSP identifier as the tunnel 791 identifier in the BGP advertisements. This identifier contains the 792 following information elements: 794 - The type of the tunnel is set to LDP P2MP LSP 795 - LDP P2MP FEC which includes an identifier generated by the root. 797 Each egress PE SHOULD "join" the P2MP MPLS tree by sending LDP label 798 mapping messages for the LDP P2MP FEC, that was learned in the BGP 799 advertisement, using procedures described in [RFC6388]. 801 8.4. Encapsulation of Aggregate P-Multicast Trees 803 An Aggregate Inclusive P-Multicast tree or an Aggregate Selective P- 804 Multicast tree MUST use MPLS encapsulation. The protocol type in the 805 data link header is as described in [RFC5332]. 807 9. Inter-AS Inclusive P-Multicast Tree A-D/Binding 809 As stated earlier, this document defines four models of inter-AS VPLS 810 service, referred here as option (a), (b), (c) and (e). This section 811 contains procedures to support these models. 813 For supporting option (a), (b) and (e) this section specifies a model 814 where inter-AS VPLS service can be offered without requiring a single 815 P-Multicast tree to span multiple ASes. This allows individual ASes 816 to potentially use different P-tunneling technologies. There are two 817 variants of this model. One that requires MAC lookup on the ASBRs, 818 and applies to option (a) and (e). The other is one that does not 819 require MAC lookup on the ASBRs, and instead builds segmented inter- 820 AS Inclusive or Selective trees. This applies only to option (b). 822 For supporting option (c) this section specifies a model where Inter- 823 AS VPLS service is offered by requiring a single Inclusive P- 824 Multicast tree to span multiple ASes. This is referred to as a non- 825 segmented P-Multicast tree. This is because in the case of option (c) 826 the ASBRs do not exchange BGP-VPLS NLRIs or VPLS A-D routes. 827 Selective inter-AS trees for option (c) support may be segmented or 828 non-segmented. 830 An implementation MUST support options (a), (b), and (c), and MAY 831 support option(e). When there are multiple ways for implementing one 832 of these options, this section specifies which one is mandatory. 834 9.1. VSIs on the ASBRs 836 When VSIs are configured on ASBRs, the ASBRs MUST perform a MAC 837 lookup, in addition to any MPLS lookups, to determine the forwarding 838 decision on a VPLS packet. The P-Multicast trees are confined to an 839 AS. An ASBR on receiving a VPLS packet from another ASBR is required 840 to perform a MAC lookup to determine how to forward the packet. Thus 841 an ASBR is required to keep a VSI for the VPLS instance and MUST be 842 configured with its own VE ID for the VPLS instance. The BGP VPLS A- 843 D routes generated by PEs in an AS MUST NOT be propagated outside the 844 AS. 846 9.1.1. Option (a): VSIs on the ASBRs 848 In option (a) an ASBR acts as a PE for the VPLSs that span the AS of 849 the ASBR and an AS to which the ASBR is connected. The local ASBR 850 views the ASBR in the neighboring AS as a CE connected to it by a 851 link with separate VLAN sub-interfaces for each such VPLS. Similarly, 852 the ASBR in the neighboring AS acts as a PE for such VPLS from the 853 neighboring AS's point of view, and views the local ASBR as a CE. 855 The local ASBR uses a combination of the incoming link and a 856 particular VLAN sub-interface on that link to detemine the VSI for 857 the packets it receives from the ASBR in the neighboring AS. 859 In option (a) the ASBRs do not exchange VPLS A-D routes. 861 An implementation MUST support option (a). 863 9.1.2. Option (e): VSIs on the ASBRs 865 The VSIs on the ASBRs scheme can be used such that the interconnect 866 between the ASBRs is a PW and MPLS encapsulation is used between the 867 ASBRs. An ASBR in one AS determines the VSI for packets received 868 from an adjoining ASBR in another AS based on the incoming MPLS PW 869 label. This is referred to as option (e). The only VPLS A-D routes 870 that are propagated outside the AS are the ones originated by ASBRs. 871 This MPLS PW connects the VSIs on the ASBRs and MUST be signaled 872 using the procedures defined in [RFC4761] or [RFC4762]. 874 The P-Multicast trees for a VPLS are confined to each AS and the VPLS 875 auto-discovery/binding MUST follow the intra-AS procedures described 876 in section "Demultiplexing Multicast Tree Traffic". 878 An implementation MAY support option (e). 880 9.2. Option (b) - Segmented Inter-AS Trees 882 In this model, an inter-AS P-Multicast tree, rooted at a particular 883 PE for a particular VPLS instance, consists of a number of 884 "segments", one per AS, which are stitched together at ASBRs. These 885 are known as "segmented inter-AS trees". Each segment of a segmented 886 inter-AS tree may use a different multicast transport technology. In 887 this model, an ASBR is not required to keep a VSI for the VPLS 888 instance, and is not required to perform a MAC lookup in order to 889 forward the VPLS packet. This implies that an ASBR is not required to 890 be configured with a VE ID for the VPLS. 892 An implementation MUST support option (b) using this model. 894 The construction of segmented Inter-AS trees requires the BGP-VPLS A- 895 D NLRI described in [RFC4761, RFC6074]. A BGP VPLS A-D route for a 896 tuple advertised outside the AS, to which the originating 897 PE belongs, will be referred to as an inter-AS VPLS A-D route (though 898 this route is originated by a PE as an intra-AS route, and is 899 referred to as an inter-AS route outside the AS). 901 In addition to this, segmented inter-AS trees require support for the 902 PMSI Tunnel attribute described in section "Inclusive Tree/Selective 903 Tree Identifier". They also require additional procedures in BGP to 904 signal leaf A-D routes between ASBRs as explained in subsequent 905 sections. 907 9.2.1. Segmented Inter-AS Trees VPLS Inter-AS A-D/Binding 909 This section specifies the procedures for inter-AS VPLS A-D/binding 910 for segmented inter-AS trees. 912 An ASBR must be configured to support a particular VPLS as follows: 914 + An ASBR MUST be configured with a set of (import) Route Targets 915 (RTs) that specify the set of VPLS instances supported by the 916 ASBR. These Route Targets control acceptance of BGP VPLS auto- 917 discovery routes by the ASBR. Note that instead of being 918 configured, the ASBR MAY obtain this set of (import) Route 919 Targets (RTs) by using Route Target Constrain [RFC4684]. 921 + The ASBR MUST be configured with the tunnel types for the intra- 922 AS segments of the VPLS instances supported by the ASBR, as well 923 as (depending on the tunnel type) the information needed to 924 create the PMSI Tunnel attribute for these tunnel types. Note 925 that instead of being configured, the ASBR MAY derive the tunnel 926 types from the intra-AS A-D routes received by the ASBR from the 927 PEs in its own AS. 929 If an ASBR is configured to support a particular VPLS instance, the 930 ASBR MUST participate in the intra-AS VPLS auto-discovery/binding 931 procedures for that VPLS instance within the ASBR's own AS, as 932 defined in this document. 934 Moreover, in addition to the above the ASBR performs procedures 935 specified in section "Propagating BGP VPLS A-D routes to other ASes: 936 Overview". 938 9.2.2. Propagating BGP VPLS A-D routes to other ASes: Overview 940 A BGP VPLS A-D route for a given VPLS, originated by a PE within a 941 given AS, is propagated via BGP to other ASes. The precise rules for 942 distributing and processing the inter-AS A-D routes are given in 943 subsequent sections. 945 Suppose that an ASBR A receives and installs a BGP VPLS A-D route for 946 VPLS "X" and VE ID "V" that originated at a particular PE, PE1, that 947 is in the same AS as A. The BGP next hop of that received route 948 becomes A's "upstream neighbor" on a multicast distribution tree for 949 (X, V) that is rooted at PE1. Likewise, when A re-advertises this 950 route to ASBRs in A's neighboring ASes, from the perspective of these 951 ASBRs A becomes their "upstream neighbor" on the multicast 952 distribution tree for (X, V) that is rooted at PE1. 954 When the BGP VPLS A-D routes have been distributed to all the 955 necessary ASes, they define a "reverse path" from any AS that 956 supports VPLS X and VE ID V back to PE1. For instance, if AS2 957 supports VPLS X, then there will be a reverse path for VPLS X and VE 958 ID V from AS2 to AS1. This path is a sequence of ASBRs, the first of 959 which is in AS2, and the last of which is in AS1. Each ASBR in the 960 sequence is the BGP next hop of the previous ASBR in the sequence. 962 This reverse path information can be used to construct a 963 unidirectional multicast distribution tree for VPLS X and VE ID V, 964 containing all the ASes that support X, and having PE1 at the root. 965 We call such a tree an "inter-AS tree". Multicast data originating in 966 VPLS sites for VPLS X connected to PE1 will travel downstream along 967 the tree which is rooted at PE1. 969 The path along an inter-AS tree is a sequence of ASBRs. It is still 970 necessary to specify how the multicast data gets from a given ASBR to 971 the set of ASBRs which are immediately downstream of the given ASBR 972 along the tree. This is done by creating "segments": ASBRs in 973 adjacent ASes will be connected by inter-AS segments, ASBRs in the 974 same AS will be connected by "intra-AS segments". 976 For a given inter-AS tree and a given AS there MUST be only one ASBR 977 within that AS that accepts traffic flowing on that tree. Further 978 for a given inter-AS tree and a given AS there MUST be only one ASBR 979 in that AS that sends the traffic flowing on that tree to a 980 particular adjacent AS. The precise rules for accomplishing this are 981 given in subsequent sections. 983 An ASBR initiates creation of an intra-AS segment when the ASBR 984 receives an inter-AS A-D route from an EBGP neighbor. Creation of the 985 segment is completed as a result of distributing, via IBGP, this 986 route within the ASBR's own AS. 988 For a given inter-AS tunnel each of its intra-AS segments could be 989 constructed by its own independent mechanism. Moreover, by using 990 upstream-assigned labels within a given AS multiple intra-AS segments 991 of different inter-AS tunnels of either the same or different VPLS 992 instances may share the same P-Multicast tree. 994 If the P-Multicast tree instantiating a particular segment of an 995 inter-AS tunnel is created by a multicast control protocol that uses 996 receiver-initiated joins (e.g, mLDP), and this P-Multicast tree does 997 not aggregate multiple segments, then all the information needed to 998 create that segment will be present in the inter-AS A-D routes 999 received by the ASBR from the neighboring ASBR. But if the P- 1000 Multicast tree instantiating the segment is created by a protocol 1001 that does not use receiver-initiated joins (e.g., RSVP-TE, ingress 1002 unicast replication), or if this P-Multicast tree aggregates multiple 1003 segments (irrespective of the multicast control protocol used to 1004 create the tree), then the ASBR needs to learn the leaves of the 1005 segment. These leaves are learned from A-D routes received from other 1006 PEs in the AS, for the same VPLS as the one that the segment belongs 1007 to. 1009 The following sections specify procedures for propagation of inter-AS 1010 A-D routes across ASes in order to construct inter-AS segmented 1011 trees. 1013 9.2.2.1. Propagating Intra-AS VPLS A-D routes in EBGP 1015 For a given VPLS configured on an ASBR when the ASBR receives intra- 1016 AS A-D routes originated by PEs in its own AS, the ASBR MUST 1017 propagate each of these route in EBGP. This procedure MUST be 1018 performed for each of the VPLS instances configured on the ASBR. 1019 Each of these routes is constructed as follows: 1021 + The route carries a single BGP VPLS A-D NLRI with the RD and VE 1022 ID being the same as the NLRI in the received intra-AS A-D route. 1024 + The Next Hop field of the MP_REACH_NLRI attribute is set to a 1025 routable IP address of the ASBR. 1027 + The route carries the PMSI Tunnel attribute with the Tunnel Type 1028 set to Ingress Replication; the attribute carries no MPLS labels. 1030 + The route MUST carry the export Route Target used by the VPLS. 1032 9.2.2.2. Inter-AS A-D route received via EBGP 1034 When an ASBR receives from one of its EBGP neighbors a BGP Update 1035 message that carries an inter-AS A-D route, if (a) at least one of 1036 the Route Targets carried in the message matches one of the import 1037 Route Targets configured on the ASBR, and (b) the ASBR determines 1038 that the received route is the best route to the destination carried 1039 in the NLRI of the route, the ASBR re-advertises this inter-AS A-D 1040 route to other PEs and ASBRs within its own AS. The best route 1041 selection procedures MUST ensure that for the same destination, all 1042 ASBRs in an AS pick the same route as the best route. The best route 1043 selection procedures are specified in [RFC4761] and clarified in 1044 [MULTI-HOMING]. The best route procedures ensure that if multiple 1045 ASBRs, in an AS, receive the same inter-AS A-D route from their EBGP 1046 neighbors, only one of these ASBRs propagates this route in IBGP. 1047 This ASBR becomes the root of the intra-AS segment of the inter-AS 1048 tree and ensures that this is the only ASBR that accepts traffic into 1049 this AS from the inter-AS tree. 1051 When re-advertising an inter-AS A-D route the ASBR MUST set the Next 1052 Hop field of the MP_REACH_NLRI attribute to a routable IP address of 1053 the ASBR. 1055 Depending on the type of a P-Multicast tunnel used to instantiate the 1056 intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute of 1057 the re-advertised inter-AS A-D route is constructed as follows: 1059 + If the ASBR uses ingress replication to instantiate the intra-AS 1060 segment of the inter-AS tunnel, the re-advertised route MUST NOT 1061 carry the PMSI Tunnel attribute. 1063 + If the ASBR uses a P-Multicast tree to instantiate the intra-AS 1064 segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST 1065 contain the identity of the tree that is used to instantiate the 1066 segment (note that the ASBR could create the identity of the tree 1067 prior to the actual instantiation of the segment). If in order to 1068 instantiate the segment the ASBR needs to know the leaves of the 1069 tree, then the ASBR obtains this information from the A-D routes 1070 received from other PEs/ASBRs in ASBR's own AS. 1072 + An ASBR that uses a P-Multicast tree to instantiate the intra-AS 1073 segment of the inter-AS tunnel MAY aggregate two or more VPLS 1074 instances present on the ASBR onto the same tree. If the ASBR 1075 already advertises inter-AS A-D routes for these VPLS instances, 1076 then aggregation requires the ASBR to re-advertise these routes. 1078 The re-advertised routes MUST be the same as the original ones, 1079 except for the PMSI Tunnel attribute. If the ASBR has not 1080 previously advertised inter-AS A-D routes for these VPLS 1081 instances, then the aggregation requires the ASBR to advertise 1082 (new) inter-AS A-D routes for these VPLS instances. The PMSI 1083 Tunnel attribute in the newly advertised/re-advertised routes 1084 MUST carry the identity of the P-Multicast tree that aggregates 1085 the VPLS instances, as well as an MPLS upstream-assigned label 1086 [RFC5331]. Each newly advertised or re-advertised route MUST have 1087 a label that is distinct within the scope of the ASBR. 1089 In addition the ASBR MUST send to the EBGP neighbor, from whom it 1090 receives the inter-AS A-D route, a BGP Update message that carries a 1091 leaf A-D route. The exact encoding of this route is described in 1092 section "BGP Extensions". This route contains the following 1093 information elements: 1095 + The route carries a single NLRI with the Route Key field set to 1096 the tuple of the BGP VPLS A-D NLRI of the inter-AS A- 1097 D route received from the EBGP neighbor. The NLRI also carries 1098 the IP address of the ASBR (this MUST be a routable IP address). 1100 + The leaf A-D route MUST include the PMSI Tunnel attribute with 1101 the Tunnel Type set to Ingress Replication, and the Tunnel 1102 Identifier set to a routable address of the advertising router. 1103 The PMSI Tunnel attribute MUST carry a downstream assigned MPLS 1104 label that is used to demultiplex the VPLS traffic received over 1105 a unicast tunnel by the advertising router. 1107 + The Next Hop field of the MP_REACH_NLRI attribute of the route 1108 SHOULD be set to the same IP address as the one carried in the 1109 Originating Router's IP Address field of the route. 1111 + To constrain the distribution scope of this route the route MUST 1112 carry the NO_ADVERTISE BGP community ([RFC1997]). 1114 + The ASBR constructs an IP-based Route Target extended community 1115 by placing the IP address carried in the next hop of the received 1116 Inter-AS VPLS A-D route in the Global Administrator field of the 1117 community, with the Local Administrator field of this community 1118 set to 0, and sets the Extended Communities attribute of the leaf 1119 A-D route to that community. Note that this Route Target is the 1120 same as the ASBR Import RT of the EBGP neighbor from which the 1121 ASBR received the inter-AS VPLS A-D route. 1123 9.2.2.3. Leaf A-D Route received via EBGP 1125 When an ASBR receives via EBGP a leaf A-D route, the ASBR accepts the 1126 route only if (a) at least one of the Route Targets carried in the 1127 message matches one of the import Route Targets configured on the 1128 ASBR, and (b) the ASBR determines that the received route is the best 1129 route to the destination carried in the NLRI of the route. 1131 If the ASBR accepts the leaf A-D route, the ASBR looks for an 1132 existing A-D route whose BGP-VPLS A-D NLRI has the same value as the 1133 field of the leaf A-D route just accepted. If such an A-D 1134 route is found, then the MPLS label carried in the PMSI Tunnel 1135 attribute of the leaf A-D route is used to stitch a one hop ASBR-ASBR 1136 LSP to the tail of the intra-AS tunnel segment associated with the 1137 found A-D route. 1139 9.2.2.4. Inter-AS A-D Route received via IBGP 1141 In the context of this section we use the term "PE/ASBR router" to 1142 denote either a PE or an ASBR router. 1144 Note that a given inter-AS A-D route is advertised within a given AS 1145 by only one ASBR as described above. 1147 When a PE/ASBR router receives from one of its IBGP neighbors a BGP 1148 Update message that carries an inter-AS A-D route, if (a) at least 1149 one of the Route Targets carried in the message matches one of the 1150 import Route Targets configured on the PE/ASBR, and (b) the PE/ASBR 1151 determines that the received route is the best route to the 1152 destination carried in the NLRI of the route, the PE/ASBR performs 1153 the following operations. The best route determination is based as 1154 described in [RFC4761] and clarified in [MULTI-HOMING]. 1156 If the router is an ASBR then the ASBR propagates the route to its 1157 EBGP neighbors. When propagating the route to the EBGP neighbors the 1158 ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a 1159 routable IP address of the ASBR. 1161 If the received inter-AS A-D route carries the PMSI Tunnel attribute 1162 with the Tunnel Type set to LDP P2MP LSP, the PE/ASBR SHOULD join the 1163 P-Multicast tree whose identity is carried in the PMSI Tunnel 1164 attribute. 1166 If the received inter-AS A-D route carries the PMSI Tunnel attribute 1167 with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR 1168 that originated the route MUST establish an RSVP-TE P2MP LSP with the 1169 local PE/ASBR as a leaf. This LSP MAY have been established before 1170 the local PE/ASBR receives the route, or MAY be established after the 1171 local PE receives the route. 1173 If the received inter-AS A-D route carries the PMSI Tunnel attribute 1174 with the Tunnel Type set to LDP P2MP LSP, or RSVP-TE P2MP LSP, but 1175 the attribute does not carry a label, then the P-Multicast tree, as 1176 identified by the PMSI Tunnel attribute, is an intra-AS LSP segment 1177 that is part of the inter-AS Tunnel for the advertised 1178 by the inter-AS A-D route and rooted at the PE that originated the A- 1179 D route. If the PMSI Tunnel attribute carries a (upstream-assigned) 1180 label, then a combination of this tree and the label identifies the 1181 intra-AS segment. If the receiving router is an ASBR, this intra-AS 1182 segment may further be stitched to ASBR-ASBR inter-AS segment of the 1183 inter-AS tunnel. If the PE/ASBR has local receivers in the VPLS, 1184 packets received over the intra-AS segment must be forwarded to the 1185 local receivers using the local VSI. 1187 9.3. Option (c): Non-Segmented Tunnels 1189 In this model, there is a multi-hop EBGP peering between the PEs (or 1190 BGP Route Reflector) in one AS and the PEs (or BGP Route Reflector) 1191 in another AS. The PEs exchange BGP-VPLS NLRI or BGP-VPLS A-D NLRI, 1192 along with PMSI Tunnel attribute, as in the intra-AS case described 1193 in section "Demultiplexing P-Multicast Tree Traffic". 1195 The PEs in different ASes use a non-segmented inter-AS P2MP tunnel 1196 for VPLS multicast. A non-segmented inter-AS tunnel is a single 1197 tunnel which spans AS boundaries. The tunnel technology cannot change 1198 from one point in the tunnel to the next, so all ASes through which 1199 the tunnel passes must support that technology. In essence, AS 1200 boundaries are of no significance to a non-segmented inter-AS P2MP 1201 tunnel. 1203 This model requires no VPLS A-D routes in the control plane or VPLS 1204 MAC address learning in the data plane on the ASBRs. The ASBRs only 1205 need to participate in the non-segmented P2MP tunnel setup in the 1206 control plane, and do MPLS label forwarding in the data plane. 1208 When the tunneling technology is P2MP LSP signaled with mLDP, and one 1209 does not use [RFC6512], the setup of non-segmented inter-AS P2MP 1210 tunnels requires the P-routers in one AS to have IP reachability to 1211 the loopback addresses of the PE routers in another AS. That is, the 1212 reachability to the loopback addresses of PE routers in one AS MUST 1213 be present in the IGP in another AS. 1215 The data forwarding in this model is the same as in the intra-AS case 1216 described in section "Demultiplexing P-Multicast Tree Traffic". 1218 An implementation MUST support this model. 1220 10. Optimizing Multicast Distribution via Selective Trees 1222 Whenever a particular multicast stream is being sent on an Inclusive 1223 P-Multicast tree, it is likely that the data of that stream is being 1224 sent to PEs that do not require it as the sites connected to these 1225 PEs may have no receivers for the stream. If a particular stream has 1226 a significant amount of traffic, it may be beneficial to move it to a 1227 Selective P-Multicast tree which has at its leaves only those PEs, 1228 connected to sites that have receivers for the multicast stream (or 1229 at least includes fewer PEs that are attached to sites with no 1230 receivers compared to an Inclusive tree). 1232 A PE connected to the multicast source of a particular multicast 1233 stream may be performing explicit tracking - i.e., it may know the 1234 PEs that have receivers in the multicast stream. Section "Receiving 1235 S-PMSI A-D routes by PEs" describes procedures that enable explicit 1236 tracking. If this is the case Selective P-Multicast trees can also be 1237 triggered on other criteria. For instance there could be a "pseudo 1238 wasted bandwidth" criteria: switching to a Selective tree would be 1239 done if the bandwidth multiplied by the number of "uninterested" PEs 1240 (PEs that are receiving the stream but have no receivers) is above a 1241 specified threshold. The motivation is that (a) the total bandwidth 1242 wasted by many sparsely subscribed low-bandwidth groups may be large, 1243 and (b) there's no point to moving a high-bandwidth group to a 1244 Selective tree if all the PEs have receivers for it. 1246 Switching a (C-S, C-G) stream to a Selective P-Multicast tree may 1247 require the root of the tree to determine the egress PEs that need to 1248 receive the (C-S, C-G) traffic. This is true in the following cases: 1250 + If the tunnel is a P2MP tree, such as a RSVP-TE P2MP Tunnel, the 1251 PE needs to know the leaves of the tree before it can instantiate 1252 the Selective tree. 1254 + If a PE decides to send traffic for multicast streams, belonging 1255 to different VPLS instances, using one P-Multicast Selective 1256 tree, such a tree is termed an Aggregate tree with a selective 1257 mapping. The setting up of such an Aggregate tree requires the 1258 ingress PE to know all the other PEs that have receivers for 1259 multicast groups that are mapped onto the tree (see section 1260 "Aggregation Considerations" for the rationale). 1262 + If ingress replication is used and the ingress PE wants to send 1263 traffic for (C-S, C-G)s to only those PEs that are on the path to 1264 receivers to the (C-S,C-G)s. 1266 For discovering the IP multicast group membership, for the above 1267 cases, this document describes procedures that allow an ingress PE to 1268 enable explicit tracking. Thus an ingress PE can request the IP 1269 multicast membership from egress PEs for one or more C-multicast 1270 streams. These procedures are described in section "Receiving S-PMSI 1271 A-D routes by PEs". 1273 The root of the Selective P-Multicast tree MAY decide to do explicit 1274 tracking of the IP multicast stream only after it has determined to 1275 move the stream to a Selective tree, or it MAY have been doing 1276 explicit tracking all along. This document also describes explicit 1277 tracking for a wildcard source and/or group in section "Receiving S- 1278 PMSI A-D routes by PEs", which facilitates a Selective P-Multicast 1279 tree only mode in which IP multicast streams are always carried on a 1280 Selective P-Multicast tree. In the description on Selective P- 1281 Multicast trees the notation C-S, is intended to represent either a 1282 specific source address or a wildcard. Similarly C-G is intended to 1283 represent either a specific group address or a wildcard. 1285 The PE at the root of the tree MUST signal the leaves of the tree 1286 that the (C-S, C-G) stream is now bound to the Selective Tree. Note 1287 that the PE could create the identity of the P-Multicast tree prior 1288 to the actual instantiation of the tunnel. 1290 If the Selective tree is instantiated by a RSVP-TE P2MP LSP the PE at 1291 the root of the tree MUST establish the P2MP RSVP-TE LSP to the 1292 leaves. This LSP MAY have been established before the leaves receive 1293 the Selective tree binding, or MAY be established after the leaves 1294 receive the binding. A leaf MUST NOT switch to the Selective tree 1295 until it receives the binding and the RSVP-TE P2MP LSP is setup to 1296 the leaf. 1298 10.1. Protocol for Switching to Selective Trees 1300 Selective trees provide a PE the ability to create separate P- 1301 Multicast trees for certain streams. The source PE, that 1302 originates the Selective tree, and the egress PEs, MUST use the 1303 Selective tree for the streams that are mapped to it. This 1304 may require the source and egress PEs to switch to the Selective tree 1305 from an Inclusive tree if they were already using an Inclusive tree 1306 for the streams mapped to the Selective tree. 1308 Once a source PE decides to setup a Selective tree, it MUST announce 1309 the mapping of the streams (which may be in different VPLS 1310 instances) that are mapped to the tree to the other PEs using BGP. 1311 After the egress PEs receive the announcement they setup their 1312 forwarding path to receive traffic on the Selective tree if they have 1313 one or more receivers interested in the streams mapped to 1314 the tree. Setting up the forwarding path requires setting up the 1315 demultiplexing forwarding entries based on the top MPLS label (if 1316 there is no inner label) or the inner label (if present) as described 1317 in section "Establishing P-Multicast Trees". 1319 When the P2MP LSP is established using mLDP, the egress PEs MAY 1320 perform this switch to the Selective tree once the announcement from 1321 the ingress PE is received, or MAY wait for a preconfigured timer to 1322 do so, after receiving the announcement. 1324 When the P2MP LSP protocol is P2MP RSVP-TE, an egress PE MUST perform 1325 this switch to the Selective tree only after the announcement from 1326 the ingress PE is received and the RSVP-TE P2MP LSP has been setup to 1327 the egress PE. This switch MAY be done after waiting for a 1328 preconfigured timer after these two steps have been accomplished. 1330 A source PE MUST use the following approach to decide when to start 1331 transmitting data on the Selective tree, if it is currently using an 1332 Inclusive tree. After announcing the stream mapping to a 1333 Selective tree, the source PE MUST wait for a "switch-over" delay 1334 before sending stream on the Selective tree. It is 1335 RECOMMENDED to allow this delay to be configurable. Once the "switch- 1336 over" delay has elapsed, the source PE MUST send stream on 1337 the Selective tree. In no case is any packet sent on both 1338 Selective and Inclusive trees. 1340 When a stream is switched from an Inclusive to a Selective 1341 tree, the purpose of running a switch-over timer is to minimize 1342 packet loss without introducing packet duplication. However, jitter 1343 may be introduced due to the difference in transit delays between the 1344 Inclusive and Selective trees. 1346 For best effect, the switch-over timer should be configured to a 1347 value that is "just long enough" (a) to allow all the PEs to learn 1348 about the new binding of to a Selective tree, and (b) to 1349 allow the PEs to construct the P-tunnel associated with the Selective 1350 tree, if it doesn't already exist. 1352 10.2. Advertising (C-S, C-G) Binding to a Selective Tree 1354 The ingress PE informs all the PEs that are on the path to receivers 1355 of the (C-S, C-G) of the binding of the Selective tree to the (C-S, 1356 C-G), using BGP. The BGP announcement is done by sending update for 1357 the MCAST-VPLS address family using what we referred to as an "S-PMSI 1358 A-D route". The format of the NLRI of this route is described in 1359 section "Inclusive Tree/Selective Tree Identifier". The NLRI MUST be 1360 constructed as follows: 1362 + The Route Distinguisher (RD) MUST be set to the RD configured 1363 locally for the VPLS. This is required to uniquely identify the 1364 as the addresses could overlap between different VPLS 1365 instances. This MUST be the same RD value used in the VPLS auto- 1366 discovery process. 1368 + The Multicast Source field MUST contain the source address 1369 associated with the C-multicast stream, and the Multicast Source 1370 Length field is set appropriately to reflect this. If the source 1371 address is a wildcard the source address is set to 0. 1373 + The Multicast Group field MUST contain the group address 1374 associated with the C-multicast stream, and the Multicast Group 1375 Length field is set appropriately to reflect this. If the group 1376 address is a wildcard the group address is set to 0. 1378 + The Originating Router's IP Address field MUST be set to the IP 1379 address that the (local) PE places in the BGP next-hop of the 1380 BGP-VPLS A-D routes. Note that the tuple uniquely identifies a given VPLS instance on a PE. 1383 The PE constructs the rest of the Selective A-D route as follows. 1385 Depending on the type of a P-Multicast tree used for the P-tunnel, 1386 the PMSI tunnel attribute of the S-PMSI A-D route is constructed as 1387 follows: 1389 + The PMSI tunnel attribute MUST contain the identity of the P- 1390 Multicast tree (note that the PE could create the identity of the 1391 tree prior to the actual instantiation of the tree). 1393 + If in order to establish the P-Multicast tree the PE needs to 1394 know the leaves of the tree within its own AS, then the PE 1395 obtains this information from the leaf A-D routes received from 1396 other PEs/ASBRs within its own AS (as other PEs/ASBRs originate 1397 leaf A-D routes in response to receiving the S-PMSI A-D route) by 1398 setting the Leaf Information Required flag in the PMSI Tunnel 1399 attribute to 1. This enables explicit tracking for the multicast 1400 stream(s) advertised by the S-PMSI A-D route. 1402 + If a PE originates S-PMSI A-D routes with the Leaf Information 1403 Required flag in the PMSI Tunnel attribute set to 1, then the PE 1404 MUST be (auto)configured with an import Route Target, which 1405 controls acceptance of leaf A-D routes by the PE. (Procedures for 1406 originating leaf A-D routes by the PEs that receive the S-PMSI A- 1407 D route are described in section "Receiving S-PMSI A-D routes by 1408 PEs.") 1410 This Route Target is IP address specific. The Global 1411 Administrator field of this Route Target MUST be set to the IP 1412 address carried in the Next Hop of all the S-PMSI A-D routes 1413 advertised by this PE (if the PE uses different Next Hops, then 1414 the PE MUST be (auto)configured with multiple import RTs, one per 1415 each such Next Hop). The Local Administrator field of this Route 1416 Target MUST be set to 0. 1418 If the PE supports Route Target Constrain [RFC4684], the PE 1419 SHOULD advertise this import Route Target within its own AS using 1420 Route Target Constrains. To constrain distribution of the Route 1421 Target Constrain routes to the AS of the advertising PE these 1422 routes SHOULD carry the NO_EXPORT Community ([RFC1997]). 1424 + A PE MAY aggregate two or more S-PMSIs originated by the PE onto 1425 the same P-Multicast tree. If the PE already advertises S-PMSI A- 1426 D routes for these S-PMSIs, then aggregation requires the PE to 1427 re-advertise these routes. The re-advertised routes MUST be the 1428 same as the original ones, except for the PMSI tunnel attribute. 1429 If the PE has not previously advertised S-PMSI A-D routes for 1430 these S-PMSIs, then the aggregation requires the PE to advertise 1431 (new) S-PMSI A-D routes for these S-PMSIs. The PMSI Tunnel 1432 attribute in the newly advertised/re-advertised routes MUST carry 1433 the identity of the P-Multicast tree that aggregates the S-PMSIs. 1434 If at least some of the S-PMSIs aggregated onto the same P- 1435 Multicast tree belong to different VPLS instances, then all these 1436 routes MUST carry an MPLS upstream assigned label [RFC5331]. If 1437 all these aggregated S-PMSIs belong to the same VPLS, then the 1438 routes MAY carry an MPLS upstream assigned label [RFC5331]. The 1439 labels MUST be distinct on a per VPLS instance basis, and MAY be 1440 distinct on a per route basis. 1442 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 1443 be set to the same IP address as the one carried in the Originating 1444 Router's IP Address field. 1446 By default the set of Route Targets carried by the route MUST be the 1447 same as the Route Targets carried in the BGP-VPLS A-D route 1448 originated from the VSI. The default could be modified via 1449 configuration. 1451 10.3. Receiving S-PMSI A-D routes by PEs 1453 Consider a PE that receives an S-PMSI A-D route. If one or more of 1454 the VSIs on the PE have their import Route Targets that contain one 1455 or more of the Route Targets carried by the received S-PMSI A-D 1456 route, then for each such VSI the PE performs the following. 1458 Procedures for receiving an S-PMSI A-D route by a PE (both within and 1459 outside of the AS of the PE that originates the route) are the same 1460 as specified in section "Inter-AS A-D route received via IBGP" except 1461 that (a) instead of Inter-AS A-D routes the procedures apply to S- 1462 PMSI A-D routes, and (b) the rules for determining whether the 1463 received S-PMSI A-D route is the best route to the destination 1464 carried in the NLRI of the route, are the same as BGP path selection 1465 rules and may be modified by policy, and (c) a PE performs procedures 1466 specified in that section only if in addition to the criteria 1467 specified in that section the following is true: 1469 + If as a result of multicast state snooping on the PE-CE 1470 interfaces, the PE has snooped state for at least one multicast 1471 join that matches the multicast source and group advertised in 1472 the S-PMSI A-D route. Further if the oifs (outgoing interfaces) 1473 for this state contains one or more interfaces to the locally 1474 attached CEs. When the multicast signaling protocol among the CEs 1475 is IGMP, then snooping and associated procedures are defined in 1476 [RFC4541]. The snooped state is determined using these 1477 procedures. When the multicast signaling protocol among the CEs 1478 is PIM, the procedures in [RFC4541] are not sufficient to 1479 determine the snooped state. The additional details required to 1480 determine the snooped state when CE-CE protocol is PIM are for 1481 further study. When such procedures are defined it is expected 1482 that the procedures in this section will apply to the snooped 1483 state created as a result of PIM as PE-CE protocol. 1485 The snooped state is said to "match" the S-PMSI A-D route if any of 1486 the following is true: 1488 + The S-PMSI A-D route carries (C-S, C-G) and the snooped state is 1489 for (C-S, C-G) or for (C-*, C-G), OR 1491 + The S-PMSI A-D route carries (C-*, C-G) and (a) the snooped 1492 state is for (C-*, C-G) OR (b) the snooped state is for at least 1493 one multicast join with the multicast group address equal to C-G 1494 and there doesn't exist another S-PMSI A-D route that carries (C- 1495 S, C-G) where C-S is the source address of the snooped state. 1497 + The S-PMSI A-D route carries (C-S, C-*) and (a) the snooped 1498 state is for at least one multicast join with the multicast 1499 source address equal to C-S, and (b) there doesn't exist another 1500 S-PMSI A-D route that carries (C-S, C-G) where C-G is the group 1501 address of the snooped state. 1503 + The S-PMSI A-D route carries (C-*, C-*) and there is no other S- 1504 PMSI A-D route that matches the snooped state as per the above 1505 conditions. 1507 Note if the above conditions are true, and if the received S-PMSI A-D 1508 route has a PMSI Tunnel attribute with the Leaf Information Required 1509 flag set to 1, then the PE originates a leaf A-D route, constructed 1510 as follows: 1512 + The route carries a single MCAST-VPLS NLRI with the Route Key 1513 field set to the MCAST-VPLS NLRI of the received S-PMSI A-D 1514 route. 1516 + The Originating Router's IP address set to the IP address of the 1517 PE (this MUST be a routable IP address). 1519 + The PE constructs an IP-based Route Target Extended Community by 1520 placing the IP address carried in the Next Hop of the received S- 1521 PMSI A-D route in the Global Administrator field of the 1522 Community, with the Local Administrator field of this Community 1523 set to 0 and setting the Extended Communities attribute of the 1524 leaf A-D route to that Community. 1526 + The Next Hop field of the MP_REACH_NLRI attribute of the route 1527 MUST be set to the same IP address as the one carried in the 1528 Originating Router's IP Address field of the route. 1530 + To constrain the distribution scope of this route, the route 1531 MUST carry the NO_EXPORT Community [RFC1997], except for the 1532 inter-AS scenario with option (c). 1534 Once the leaf A-D route is constructed, the PE advertises this route 1535 into IBGP. 1537 In addition to the procedures specified in section "Inter-AS A-D 1538 route received via IBGP" the PE MUST set up its forwarding path to 1539 receive traffic, for each multicast stream in the matching snooped 1540 state, from the tunnel advertised by the S-PMSI A-D route (the PE 1541 MUST switch to the Selective tree). 1543 When a new snooped state is created by a PE then the PE MUST first 1544 determine if there is a S-PMSI A-D route that matches the snooped 1545 state as per the conditions described above. If such a S-PMSI A-D 1546 route is found, then the PE MUST follow the procedures described in 1547 this section, for that particular S-PMSI A-D route. If later on the 1548 snooped state ages out and is deleted from the PE, the PE SHOULD 1549 withdraw the leaf A-D route that it had originated in response to the 1550 S-PMSI A-D route. 1552 10.4. Inter-AS Selective Tree 1554 Inter-AS Selective trees support all three options of inter-AS VPLS 1555 service, option (a), (b) and (c), that are supported by Inter-AS 1556 Inclusive trees. They are constructed in a manner that is very 1557 similar to Inter-AS Inclusive trees. 1559 For option (a) and option (b) support inter-AS Selective trees are 1560 constructed without requiring a single P-Multicast tree to span 1561 multiple ASes. This allows individual ASes to potentially use 1562 different P-tunneling technologies. There are two variants of this. 1563 One that requires MAC and IP multicast lookup on the ASBRs and 1564 another that does not require MAC/IP multicast lookup on the ASBRs 1565 and instead builds segmented inter-AS Selective trees. 1567 Segmented Inter-AS Selective trees can also be used with option (c), 1568 unlike Segmented Inter-AS Inclusive trees. This is because the S-PMSI 1569 A-D routes can be exchanged via ASBRs (even though BGP VPLS A-D 1570 routes are not exchanged via ASBRs). 1572 In the case of Option (c) an Inter-AS Selective tree may also be a 1573 non-segmented P-Multicast tree that spans multiple ASes. 1575 10.4.1. VSIs on the ASBRs 1577 The requirements on ASBRs, when VSIs are present on the ABSRs, 1578 include the requirements presented in section "Inter-AS Inclusive P- 1579 Multicast Tree A-D/Binding". The source ASBR (that receives traffic 1580 from another AS) may independently decide whether it wishes to use 1581 Selective trees or not. If it uses Selective trees the source ASBR 1582 MUST perform a MAC lookup to determine the Selective tree to forward 1583 the VPLS packet on. 1585 10.4.1.1. VPLS Inter-AS Selective Tree A-D Binding 1587 The mechanisms for propagating S-PMSI A-D routes are the same as the 1588 intra-AS case described in section "MCAST-VPLS NLRI". The BGP 1589 Selective tree A-D routes generated by PEs in an AS MUST NOT be 1590 propagated outside the AS. 1592 10.4.2. Inter-AS Segmented Selective Trees 1594 Inter-AS Segmented Selective trees MUST be used when option (b) is 1595 used to provide the inter-AS VPLS service. They MAY be used when 1596 option (c) is used to provide the inter-AS VPLS service. 1598 A Segmented inter-AS Selective Tunnel is constructed similar to an 1599 inter-AS Segmented Inclusive Tunnel. Namely, such a tunnel is 1600 constructed as a concatenation of tunnel segments. There are two 1601 types of tunnel segments: an intra-AS tunnel segment (a segment that 1602 spans ASBRs within the same AS), and inter-AS tunnel segment (a 1603 segment that spans adjacent ASBRs in adjacent ASes). ASes that are 1604 spanned by a tunnel are not required to use the same tunneling 1605 mechanism to construct the tunnel - each AS may pick up a tunneling 1606 mechanism to construct the intra-AS tunnel segment of the tunnel, in 1607 its AS. 1609 The PE that decides to set up a Selective tree, advertises the 1610 Selective tree to multicast stream binding using an S-PMSI A-D route 1611 as per procedures in section "Advertising (C-S, C-G) Binding to a 1612 Selective Tree", to the routers in its own AS. 1614 An S-PMSI A-D route advertised outside the AS, to which the 1615 originating PE belongs, will be referred to as an inter-AS Selective 1616 Tree A-D route (although this route is originated by a PE as an 1617 intra-AS route it is referred to as an inter-AS route outside the 1618 AS). 1620 10.4.2.1. Handling S-PMSI A-D routes by ASBRs 1622 Procedures for handling an S-PMSI A-D route by ASBRs (both within and 1623 outside of the AS of the PE that originates the route) are the same 1624 as specified in section "Propagating VPLS BGP A-D routes to other 1625 ASes", except that instead of Inter-AS BGP-VPLS A-D routes and the 1626 BGP-VPLS A-D NLRI these procedures apply to S-PMSI A-D routes and the 1627 S-PMSI A-D NLRI. 1629 In addition to these procedures an ASBR advertises a leaf A-D route 1630 in response to an S-PMSI A-D route only if: 1632 + The S-PMSI A-D route was received via EBGP from another ASBR and 1633 the ASBR merges the S-PMSI A-D route into an Inter-AS BGP VPLS A- 1634 D route as described in the next section. OR 1636 + The ASBR receives a leaf A-D route from a downstream PE or ASBR 1637 in response to the S-PMSI A-D route, received from an upstream PE 1638 or ASBR, that the ASBR propagated inter-AS to downstream ASBRs 1639 and PEs. 1641 + The ASBR has snooped state from local CEs that matches the NLRI 1642 carried in the S-PMSI A-D route as per the following rules: 1644 i) The NLRI encodes (C-S, C-G) which is the same as the snooped 1645 (C-S, C-G) 1647 ii) The NLRI encodes (*, C-G) and there is snooped state for at 1648 least one (C-S, C-G) and there is no other matching S-PMSI A-D 1649 route for (C-S, C-G) OR there is snooped state for (*, C-G) 1651 iii) The NLRI encodes (*, *) and there is snooped state for at 1652 least one (C-S, C-G) or (*, C-G) and there is no other matching 1653 S-PMSI A-D route for that (C-S, C-G) or (*, C-G) respectively. 1655 The C-multicast data traffic is sent on the Selective tree by the 1656 originating PE. When it reaches an ASBR that is on the Inter-AS 1657 segmented tree, it is delivered to local receivers, if any. It is 1658 then forwarded on any inter-AS or intra-AS segments that exist on the 1659 Inter-AS Selective Segmented tree. If the Inter-AS Segmented 1660 Selective Tree is merged onto an Inclusive tree, as described in the 1661 next section, the data traffic is forwarded onto the Inclusive tree. 1663 10.4.2.1.1. Merging Selective Tree into an Inclusive Tree 1665 Consider the situation where: 1667 + An ASBR is receiving (or expecting to receive) inter-AS (C-S, C- 1668 G) data from upstream via a Selective tree. 1670 + The ASBR is sending (or expecting to send) the inter-AS (C-S, C- 1671 G) data downstream via an Inclusive tree. 1673 This situation may arise if the upstream providers have a policy of 1674 using Selective trees but the downstream providers have a policy of 1675 using Inclusive trees. To support this situation, an ASBR MAY, under 1676 certain conditions, merge one or more upstream Selective trees into a 1677 downstream Inclusive tree. Note that this can be the case only for 1678 option (b) and not for option (c) as for option (c) the ASBRs do not 1679 have Inclusive tree state. 1681 A Selective tree (corresponding to a particular S-PMSI A-D route) MAY 1682 be merged by a particular ASBR into an Inclusive tree (corresponding 1683 to a particular Inter-AS BGP VPLS A-D route) if and only if the 1684 following conditions all hold: 1686 + The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route 1687 originate in the same AS. The Inter-AS BGP VPLS A-D route carries 1688 the originating AS in the AS_PATH attribute of the route. The S- 1689 PMSI A-D route carries the originating AS in the AS_PATH 1690 attribute of the route. 1692 + The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route have 1693 exactly the same set of RTs. 1695 An ASBR performs merging by stitching the tail end of the P-tunnel, 1696 as specified in the PMSI Tunnel attribute of the S-PMSI A-D route 1697 received by the ASBR, to the head of the P-tunnel, as specified in 1698 the PMSI Tunnel attribute of the Inter-AS BGP VPLS A-D route re- 1699 advertised by the ASBR. 1701 An ASBR that merges an S-PMSI A-D route into an Inter-AS BGP VPLS A-D 1702 route MUST NOT re-advertise the S-PMSI A-D route. 1704 10.4.3. Inter-AS Non-Segmented Selective trees 1706 Inter-AS Non-segmented Selective trees MAY be used in the case of 1707 option (c). 1709 In this method, there is a multi-hop EBGP peering between the PEs (or 1710 a Route Reflector) in one AS and the PEs (or Route Reflector) in 1711 another AS. The PEs exchange BGP Selective tree A-D routes, along 1712 with PMSI Tunnel attribute, as in the intra-AS case described in 1713 section "Option (c): Non-Segmented Tunnels". 1715 The PEs in different ASes use a non-segmented Selective inter-AS P2MP 1716 tunnel for VPLS multicast. 1718 This method requires no VPLS information (in either the control or 1719 the data plane) on the ASBRs. The ASBRs only need to participate in 1720 the non-segmented P2MP tunnel setup in the control plane, and do MPLS 1721 label forwarding in the data plane. 1723 The data forwarding in this model is the same as in the intra-AS case 1724 described in section "Establishing P-Multicast Trees". 1726 11. BGP Extensions 1728 This section describes the encoding of the BGP extensions required by 1729 this document. 1731 11.1. Inclusive Tree/Selective Tree Identifier 1733 Inclusive P-Multicast tree and Selective P-Multicast tree 1734 advertisements carry the P-Multicast tree identifier. 1736 This document reuses the BGP attribute, called PMSI Tunnel attribute 1737 that is defined in [RFC6514]. 1739 This document supports only the following Tunnel Types when PMSI 1740 Tunnel attribute is carried in VPLS A-D or VPLS S-PMSI A-D routes: 1742 + 0 - No tunnel information present 1743 + 1 - RSVP-TE P2MP LSP 1744 + 2 - LDP P2MP LSP 1745 + 6 - Ingress Replication 1747 11.2. MCAST-VPLS NLRI 1749 This document defines a new BGP NLRI, called the MCAST-VPLS NLRI. 1751 Following is the format of the MCAST-VPLS NLRI: 1753 +-----------------------------------+ 1754 | Route Type (1 octet) | 1755 +-----------------------------------+ 1756 | Length (1 octet) | 1757 +-----------------------------------+ 1758 | Route Type specific (variable) | 1759 +-----------------------------------+ 1761 The Route Type field defines encoding of the rest of MCAST-VPLS NLRI 1762 (Route Type specific MCAST-VPLS NLRI). 1764 The Length field indicates the length in octets of the Route Type 1765 specific field of MCAST-VPLS NLRI. 1767 This document defines the following Route Types for A-D routes: 1768 + 3 - Selective Tree A-D route; 1769 + 4 - Leaf A-D route. 1771 The MCAST-VPLS NLRI is carried in BGP using BGP Multiprotocol 1772 Extensions [RFC4760] with an AFI of 25 (L2VPN AFI), and an SAFI of 1773 MCAST-VPLS. The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI 1774 attribute contains the MCAST-VPLS NLRI (encoded as specified above). 1776 In order for two BGP speakers to exchange labeled MCAST-VPLS NLRI, 1777 they must use BGP Capabilities Advertisement to ensure that they both 1778 are capable of properly processing such NLRI. This is done as 1779 specified in [RFC4760], by using capability code 1 (multiprotocol 1780 BGP) with an AFI of 25 and a SAFI of MCAST-VPLS. 1782 The following describes the format of the Route Type specific MCAST- 1783 VPLS NLRI for various Route Types defined in this document. 1785 11.2.1. S-PMSI A-D route 1787 An S-PMSI A-D route type specific MCAST-VPLS NLRI consists of the 1788 following: 1790 +-----------------------------------+ 1791 | RD (8 octets) | 1792 +-----------------------------------+ 1793 | Multicast Source Length (1 octet) | 1794 +-----------------------------------+ 1795 | Multicast Source (Variable) | 1796 +-----------------------------------+ 1797 | Multicast Group Length (1 octet) | 1798 +-----------------------------------+ 1799 | Multicast Group (Variable) | 1800 +-----------------------------------+ 1801 | Originating Router's IP Addr | 1802 +-----------------------------------+ 1804 The RD is encoded as described in [RFC4364]. 1806 The Multicast Source field contains the C-S address i.e the address 1807 of the multicast source. If the Multicast Source field contains an 1808 IPv4 address, then the value of the Multicast Source Length field is 1809 32. If the Multicast Source field contains an IPv6 address, then the 1810 value of the Multicast Source Length field is 128. The value of the 1811 Multicast Source Length field may be set to 0 to indicate a wildcard. 1813 The Multicast Group field contains the C-G address i.e. the address 1814 of the multicast group. If the Multicast Group field contains an IPv4 1815 address, then the value of the Multicast Group Length field is 32. 1816 If the Multicast Group field contains an IPv6 address, then the value 1817 of the Multicast Group Length field is 128. The Multicast Group 1818 Length field may be set to 0 to indicate a wildcard. 1820 Whether the Originating Router's IP Address field carries an IPv4 or 1821 IPv6 address is determined from the value of the Length field of the 1822 MCAST-VPLS NLRI. If the Multicast Source field contains an IPv4 1823 address and the Multicast Group field contains an IPv4 address, then 1824 the value of the Length field is 22 bytes if the Originating Router's 1825 IP address carries an IPv4 address and 34 bytes if it is an IPv6 1826 address. If the Multicast Source and Multicast Group fields contain 1827 IPv6 addresses, then the value of the Length field is 46 bytes if the 1828 Originating Router's IP address carries an IPv4 address and 58 bytes 1829 if it is an IPv6 address. The following table summarizes the above. 1831 Multicast Multicast Originating Router's Length 1832 Source Group IP Address 1834 IPv4 IPv4 IPv4 22 1835 IPv4 IPv4 IPv6 34 1836 IPv6 IPv6 IPv4 46 1837 IPv6 IPv6 IPv6 58 1839 Usage of Selective Tree A-D routes is described in section 1840 "Optimizing Multicast Distribution via Selective Trees". 1842 11.2.2. Leaf A-D route 1844 A leaf A-D route type specific MCAST-VPLS NLRI consists of the 1845 following: 1847 +-----------------------------------+ 1848 | Route Key (variable) | 1849 +-----------------------------------+ 1850 | Originating Router's IP Addr | 1851 +-----------------------------------+ 1853 Whether the Originating Router's IP Address field carries an IPv4 or 1854 IPv6 address is determined from the Length field of the MCAST-VPLS 1855 NLRI and the length of the Route Key field. From these two length 1856 fields one can compute the length of the Originating Router's IP 1857 Address. If this computed length is 4 then the address is an IPv4 1858 address and if its 16 then the address is an IPv6 address. 1860 Usage of leaf A-D routes is described in sections "Inter-AS Inclusive 1861 P-Multicast tree A-D/Binding" and "Optimizing Multicast Distribution 1862 via Selective trees". 1864 12. Aggregation Considerations 1866 This document does not specify the mandatory implementation of any 1867 particular set of rules for determining whether or not the Inclusive 1868 or Selective trees of two particular VPLS instances are to be 1869 instantiated by the same Aggregate Inclusive/Selective Tree. This 1870 determination can be made by implementation-specific heuristics, by 1871 configuration, or even perhaps by the use of offline tools. 1873 This section discusses potential methodologies with respect to 1874 aggregation. 1876 In general the heuristic used to decide which VPLS instances or (C-S, 1877 C-G) entries to aggregate is implementation dependent. It is also 1878 conceivable that offline tools can be used for this purpose. This 1879 section discusses some tradeoffs with respect to aggregation. 1881 The "congruency" of aggregation is defined by the amount of overlap 1882 in the leaves of the client trees that are aggregated on an SP tree. 1883 For Aggregate Inclusive trees the congruency depends on the overlap 1884 in the membership of the VPLS instances that are aggregated on the 1885 Aggregate Inclusive tree. If there is complete overlap aggregation is 1886 perfectly congruent. As the overlap between the VPLS instances that 1887 are aggregated reduces, the congruency reduces. 1889 From the above definition of "congruency" it follows that in order 1890 for a given PE to determine the congruency of the client trees that 1891 this PE could aggregate, the PE has to know the leaves of these 1892 client trees. This is irrespective of whether the aggregated SP tree 1893 is established using mLDP or RSVP-TE. 1895 If aggregation is done such that it is not perfectly congruent a PE 1896 may receive traffic for VPLS instances to which it doesn't belong. As 1897 the amount of multicast traffic in these unwanted VPLS instantes 1898 increases aggregation becomes less optimal with respect to delivered 1899 traffic. Hence there is a tradeoff between reducing multicast state 1900 in the core and delivering unwanted traffic. 1902 An implementation should provide knobs to control aggregation based 1903 on the congruency of the tree to be aggregated. This will allow an SP 1904 to deploy aggregation depending on the VPLS membership and traffic 1905 profiles in its network. If different PEs are setting up Aggregate 1906 Inclusive trees this will also allow an SP to engineer the maximum 1907 amount of unwanted VPLS instances that a particular PE may receive 1908 traffic for. 1910 The state/bandwidth optimality trade-off can be further improved by 1911 having a versatile many-to-many association between client trees and 1912 provider trees. Thus a VPLS instance can be mapped to multiple 1913 Aggregate trees. The mechanisms for achieving this are for further 1914 study. Also it may be possible to use both ingress replication and an 1915 Aggregate tree for a particular VPLS. Mechanisms for achieving this 1916 are also for further study. 1918 13. Data Forwarding 1920 13.1. MPLS Tree Encapsulation 1922 13.1.1. Mapping multiple VPLS instances to a P2MP LSP 1924 The following diagram shows the progression of the VPLS multicast 1925 packet as it enters and leaves the SP network when MPLS trees are 1926 being used for multiple VPLS instances. RSVP-TE P2MP LSPs are 1927 examples of such trees. 1929 Packets received Packets in transit Packets forwarded 1930 at ingress PE in the service by egress PEs 1931 provider network 1933 +---------------+ 1934 |MPLS Tree Label| 1935 +---------------+ 1936 | VPLS Label | 1937 ++=============++ ++=============++ ++=============++ 1938 ||C-Ether Hdr || || C-Ether Hdr || || C-Ether Hdr || 1939 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1940 || C-IP Header || || C-IP Header || || C-IP Header || 1941 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1942 || C-Payload || || C-Payload || || C-Payload || 1943 ++=============++ ++=============++ ++=============++ 1945 When an ingress PE receives a packet, the ingress PE using the 1946 procedures defined in [RFC4761] [RFC4762] determines the VPLS 1947 instance associated with the packet. If the packet is an IP multicast 1948 packet, and the ingress PE uses an Aggregate Selective tree for the 1949 (C-S, C-G) carried in the packet, then the ingress PE pushes the VPLS 1950 Label associated with the VPLS instance on the ingress PE and the 1951 MPLS Tree Label associate with the Aggregate Selective tree, and 1952 sends the packet over the P2MP LSP associated with the Aggregate 1953 Selective tree. Otherwise, if the ingress PE does not use an 1954 Aggregate Selective tree for the (C-S, C-G), or the packet is either 1955 non-IP multicast or broadcast, the ingress PE pushes the VPLS label 1956 associated with the VPLS instance on the ingress PE and the MPLS Tree 1957 Label associated with the Aggregate Inclusive tree, and sends the 1958 packet over the P2MP LSP associated with the Aggregate Inclusive 1959 tree. 1961 The egress PE does a lookup on the outer MPLS tree label, and 1962 determines the MPLS forwarding table in which to lookup the inner 1963 MPLS label (VPLS label). This table is specific to the tree label 1964 space (as identified by the MPLS Tree label). The inner label (VPLS 1965 label) is unique within the context of the root of the tree (as it is 1966 assigned by the root of the tree, without any coordination with any 1967 other nodes). Thus it is not unique across multiple roots. So, to 1968 unambiguously identify a particular VPLS one has to know the VPLS 1969 label, and the context within which that label is unique. The context 1970 is provided by the outer MPLS label (MPLS Tree label) [RFC5331]. 1972 The outer MPLS label is popped. The lookup of the resulting MPLS 1973 label determines the VSI in which the egress PE needs to do the C- 1974 multicast data packet lookup. It then pops the inner MPLS label and 1975 sends the packet to the VSI for multicast data forwarding. 1977 13.1.2. Mapping one VPLS instance to a P2MP LSP 1979 The following diagram shows the progression of the VPLS multicast 1980 packet as it enters and leaves the SP network when a given MPLS tree 1981 is being used for a single VPLS instance. RSVP-TE P2MP LSPs are 1982 examples of such trees. 1984 Packets received Packets in transit Packets forwarded 1985 at ingress PE in the service by egress PEs 1986 provider network 1988 +---------------+ 1989 |MPLS Tree Label| 1990 ++=============++ ++=============++ ++=============++ 1991 ||C-Ether Hdr || || C-Ether Hdr || || C-Ether Hdr || 1992 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1993 || C-IP Header || || C-IP Header || || C-IP Header || 1994 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1995 || C-Payload || || C-Payload || || C-Payload || 1996 ++=============++ ++=============++ ++=============++ 1998 When an ingress PE receives a packet, the ingress PE using the 1999 procedures defined in [RFC4761] [RFC4762] determines the VPLS 2000 instance associated with the packet. If the packet is an IP multicast 2001 packet, and the ingress PE uses a Selective tree for the (C-S, C-G) 2002 carried in the packet, then the ingress PE pushes the MPLS Tree Label 2003 associate with the Selective tree, and sends the packet over the P2MP 2004 LSP associated with the Selective tree. Otherwise, if the ingress PE 2005 does not use a Selective tree for the (C-S, C-G), or the packet is 2006 either non-IP multicast or broadcast, the ingress PE pushes the MPLS 2007 Tree Label associated with the Inclusive tree, and sends the packet 2008 over the P2MP LSP associated with the Inclusive tree. 2010 The egress PE does a lookup on the MPLS tree label and determines the 2011 VSI in which the receiver PE needs to do the C-multicast data packet 2012 lookup. It then pops the MPLS label and sends the packet to the VSI 2013 for multicast data forwarding. 2015 14. VPLS Data Packet Treatment 2017 If the destination MAC address of a VPLS packet received by an 2018 ingress PE from a VPLS site is a multicast address, a P-Multicast 2019 tree SHOULD be used to transport the packet, if possible. If the 2020 packet is an IP multicast packet and a Selective tree exists for that 2021 multicast stream, the Selective tree MUST be used. Else if a (C-*, 2022 C-*) Selective tree exists for the VPLS it SHOULD be used. Else if an 2023 Inclusive tree exists for the VPLS, it SHOULD be used. 2025 If the destination MAC address of a VPLS packet is a broadcast 2026 address, it is flooded. If a (C-*, C-*) Selective tree exists for the 2027 VPLS the PE SHOULD flood over it. Else if Inclusive tree exists for 2028 the VPLS the PE SHOULD flood over it. Else the PE MUST flood the 2029 packet using the procedures in [RFC4761] or [RFC4762]. 2031 If the destination MAC address of a packet is a unicast address and 2032 it has not been learned, the packet MUST be sent to all PEs in the 2033 VPLS. Inclusive P-Multicast trees or a Selective P-Multicast tree 2034 bound to (C-*, C-*) SHOULD be used for sending unknown unicast MAC 2035 packets to all PEs. When this is the case the receiving PEs MUST 2036 support the ability to perform MAC address learning for packets 2037 received on a multicast tree. In order to perform such learning, the 2038 receiver PE MUST be able to determine the sender PE when a VPLS 2039 packet is received on a P-Multicast tree. This further implies that 2040 the MPLS P-Multicast tree technology MUST allow the egress PE to 2041 determine the sender PE from the received MPLS packet. 2043 When a receiver PE receives a VPLS packet with a source MAC address, 2044 that has not yet been learned, on a P-Multicast tree, the receiver PE 2045 determines the PW to the sender PE. The receiver PE then creates 2046 forwarding state in the VPLS instance with a destination MAC address 2047 being the same as the source MAC address being learned, and the PW 2048 being the PW to the sender PE. 2050 It should be noted that when a sender PE that is sending packets 2051 destined to an unknown unicast MAC address over a P-Multicast tree 2052 learns the PW to use for forwarding packets destined to this unicast 2053 MAC address, it might immediately switch to transport such packets 2054 over this particular PW. Since the packets were initially being 2055 forwarded using a P-Multicast tree, this could lead to packet 2056 reordering. This constraint should be taken into consideration if 2057 unknown unicast frames are forwarded using a P-Multicast tree, 2058 instead of multiple PWs based on [RFC4761] or [RFC4762]. 2060 An implementation SHOULD support the ability to transport unknown 2061 unicast traffic over Inclusive P-Multicast trees. Furthermore, an 2062 implementation MUST support the ability to perform MAC address 2063 learning for packets received on a P-Multicast tree. 2065 15. Security Considerations 2067 Security considerations discussed in [RFC4761] and [RFC4762] apply to 2068 this document. This section describes additional considerations. 2070 As mentioned in [RFC4761], there are two aspects to achieving data 2071 privacy and protect against denial-of-service attacks in a VPLS: 2072 securing the control plane and protecting the forwarding path. 2073 Compromise of the control plane could result in a PE sending 2074 multicast data belonging to some VPLS to another VPLS, or black- 2075 holing VPLS multicast data, or even sending it to an eavesdropper; 2076 none of which are acceptable from a data privacy point of view. In 2077 addition, compromise of the control plane could result in black- 2078 holing VPLS multicast data and could provide opportunities for 2079 unauthorized VPLS multicast usage (e.g., exploiting traffic 2080 replication within a multicast tree to amplify a denial of service 2081 attack based on sending large amounts of traffic). 2083 The mechanisms in this document use BGP for the control plane. Hence 2084 techniques such as in [RFC5925] help authenticate BGP messages, 2085 making it harder to spoof updates (which can be used to divert VPLS 2086 traffic to the wrong VPLS) or withdrawals (denial-of-service 2087 attacks). In the multi-AS methods (b) and (c) described in section 2088 "Inter-AS Inclusive P-Multicast Tree A-D/Binding" this also means 2089 protecting the inter-AS BGP sessions, between the ASBRs, the PEs, or 2090 the Route Reflectors. 2092 Note that [RFC5925] will not help in keeping MPLS labels, associated 2093 with P2MP LSPs or the upstream MPLS labels used for aggregation, 2094 private -- knowing the labels, one can eavesdrop on VPLS traffic. 2095 However, this requires access to the data path within a Service 2096 Provider network, which is assumed to be composed of trusted 2097 nodes/links. 2099 One of the requirements for protecting the data plane is that the 2100 MPLS labels are accepted only from valid interfaces. This applies 2101 both to MPLS labels associated with P2MP LSPs and also applies to the 2102 upstream assigned MPLS labels. For a PE, valid interfaces comprise 2103 links from other routers in PE's own AS. For an ASBR, valid 2104 interfaces comprise links from other routers in ASBR's own AS, and 2105 links from other ASBRs in ASes that have instances of a given VPLS. 2106 It is especially important in the case of multi-AS VPLS instances 2107 that one accept VPLS packets only from valid interfaces. 2109 16. IANA Considerations 2111 This document defines a new NLRI, called MCAST-VPLS, to be carried in 2112 BGP using multiprotocol extensions. It requires assignment of a new 2113 SAFI. This is to be assigned by IANA. 2115 This document defines a BGP optional transitive attribute, called 2116 PMSI attribute. This is the same attribute as the one defined in 2117 [RFC6514] and the code point for this attribute has already been 2118 assigned by IANA as 22 [BGP-IANA]. Hence no further action is 2119 required from IANA regarding this attribute. 2121 17. Acknowledgments 2123 Many thanks to Thomas Morin for his support of this work. 2125 We would also like to thank authors of [RFC6514] and [RFC6513], as 2126 the details of the inter-AS segmented tree procedures in this 2127 document, as well as some text that describes these procedures have 2128 benefited from those in [RFC6514] and [RFC6513]. The same applies to 2129 the notion of Inclusive and Selective trees, as well as the 2130 procedures for switching from Inclusive to Selective trees. 2132 We would also like to thank Nabil Bitar, Stewart Bryant, Wim 2133 Henderickx, and Eric Rosen for their review and comments. 2135 18. Normative References 2137 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 2138 Requirement Levels.", RFC 2119, March 1997 2140 [RFC3209] D. Awduche, et. al., "RSVP-TE: Extensions to RSVP for LSP 2141 Tunnels", RFC 3209, December 2001 2143 [RFC4760] T. Bates, et. al., "Multiprotocol Extensions for BGP-4", 2144 RFC 4760, January 2007. 2146 [RFC4761] K. Kompella, Y. Rekther, "Virtual Private LAN Service using 2147 BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. 2149 [RFC4762] M. Lasserre, V. Kompella, "Virtual Private LAN Services 2150 over MPLS Label Distribution Protocol (LDP) Signaling", RFC 4762, 2151 January 2007. 2153 [RFC5036] L. Andersson, et. al., "LDP Specification", RFC 5036, 2154 October 2007 2156 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 2157 Assignment and Context Specific Label Space", RFC 5331, August 2008. 2159 [RFC6511] Z. Ali, G. Swallow, R. Aggarwal, "Non PHP behavior and 2160 out-of-band mapping for RSVP-TE LSPs", RFC 6511, February 2012. 2162 [RFC6512] IJ. Wijnands, et. al., "Using Multipoint LDP When the 2163 Backbone Has No Route to the Root", RFC6512, February 2012 2165 19. Informative References 2167 [RFC6514] R. Aggarwal, E. Rosen, Y. Rekhter, T. Morin, "BGP Encodings 2168 for Multicast in MPLS/BGP IP VPNs". RFC 6514, February 2012. 2170 [RFC6513] E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 2171 6513, February 2012. 2173 [RFC6388] I. Minei et. al, "Label Distribution Protocol Extensions 2174 for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 2175 Paths", RFC 6388, November 2011. 2177 [RFC6074] E. Rosen et. al., "Provisioning, Autodiscovery, and 2178 Signaling in L2VPNs", RFC 6074, January 2011. 2180 [RFC5925] J. Touch, et. al., "The TCP Authentication Option", 2181 RFC5925, June 2010. 2183 [RFC5501] Y. kamite, et. al., "Requirements for Multicast Support in 2184 Virtual Private LAN Services", RFC 5501, January 2009. 2186 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, "MPLS 2187 Multicast Encapsulations", RFC 5332, August 2008. 2189 [RFC4684] P. Marques et. al., "Constrained Route Distribution for 2190 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 2191 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 2192 November 2006. 2194 [RFC4875] R. Aggarwal et. al, "Extensions to RSVP-TE for Point to 2195 Multipoint TE LSPs", RFC 4857, May 2007. 2197 [RFC4601] B. Fenner, et. al., "PIM-SM Protocol Specification", RFC 2198 4601, August 2006. 2200 [RFC4541] M. Christensen et. al., "Considerations for Internet Group 2201 Management Protocol (IGMP) and Multicast Listener Discovery (MLD) 2202 Snooping Switches", RFC 4541, May 2006. 2204 [RFC4447] L. Martini et. al., "Pseudowire Setup and Maintenance Using 2205 the Label Distribution Protocol (LDP)", RFC 4447, April 2006. 2207 [RFC4364] "BGP MPLS VPNs", E. Rosen, Y.Rekhter, RFC4364, February 2208 2006. 2210 [RFC3810] R. Vida, et. al., "Multicast Listener Discovery Version 2 2211 (MLDv2) for IPv6", RFC 3810, June 2004 2213 [RFC3376] B. Cain, et. al., "Internet Group Management Protocol, 2214 Version 3", RFC3376, October 2002 2216 [RFC2710] S., Deering, et. al., "Multicast Listener Discovery (MLD) 2217 for IPv6", RFC2710, October 1999 2219 [RFC2236] W. Fenner, "Internet Group Management Protocol, Version 2", 2220 RFC2236, November 1997 2222 [RFC1997] R. Chandra, et. al., "BGP Communities Attribute", RFC 1997, 2223 August 1996. 2225 [MULTI-HOMING] K. Kompella et. al., "Multi-homing in BGP-based 2226 Virtual Private LAN Service", draft-ietf-l2vpn-vpls-multihoming Work 2227 in Progress. 2229 [BGP-IANA] http://www.iana.org/assignments/bgp-parameters 2231 20. Author's Address 2233 Rahul Aggarwal 2235 998 Lucky Avenue 2236 Menlo Park, CA 94025 2237 USA 2238 Phone: +1-415-806-5527 2239 Email: raggarwa_1@yahoo.com 2241 Yuji Kamite 2242 NTT Communications Corporation 2243 Tokyo Opera City Tower 2244 3-20-2 Nishi Shinjuku, Shinjuku-ku, 2245 Tokyo 163-1421, 2246 Japan 2248 Email: y.kamite@ntt.com 2250 Luyuan Fang 2251 Cisco Systems 2252 111 Wood Avenue South 2253 Iselin, NJ 08830 2254 USA 2256 Email: lufang@cisco.com 2258 Yakov Rekhter 2259 Juniper Networks 2260 1194 North Mathilda Ave. 2261 Sunnyvale, CA 94089 2262 USA 2264 Email: yakov@juniper.net 2266 Chaitanya Kodeboniya 2267 Cisco Systems 2268 Email: ckodeboy@cisco.com