idnits 2.17.1 draft-ietf-l2vpn-vpls-mcast-13.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. 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: 1 error (**), 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: July 2013 Y. Kamite 6 NTT Communications 8 L. Fang 9 Cisco Systems, Inc 11 January 30 2013 13 Multicast in VPLS 15 draft-ietf-l2vpn-vpls-mcast-13.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 This document describes a solution for overcoming a subset of the 67 limitations of existing VPLS multicast solutions. It describes 68 procedures for VPLS multicast that utilize multicast trees in the 69 sevice provider (SP) network. One such multicast tree can be shared 70 between multiple VPLS instances. Procedures by which a single 71 multicast tree in the SP network can be used to carry traffic 72 belonging only to a specified set of one or more IP multicast streams 73 from one or more VPLSes are also described. 75 Table of Contents 77 1 Specification of requirements ......................... 4 78 2 Contributors .......................................... 4 79 3 Terminology ........................................... 5 80 4 Introduction .......................................... 5 81 5 Existing Limitations of VPLS Multicast ................ 6 82 6 Overview .............................................. 6 83 6.1 Inclusive and Selective Multicast Trees ............... 6 84 6.2 BGP-Based VPLS Membership Auto-Discovery .............. 8 85 6.3 IP Multicast Group Membership Discovery ............... 8 86 6.4 Advertising P-Multicast Tree to VPLS/C-Multicast Binding ..9 87 6.5 Aggregation ........................................... 10 88 6.6 Inter-AS VPLS Multicast ............................... 10 89 7 Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding11 90 7.1 Originating intra-AS VPLS A-D routes .................. 12 91 7.2 Receiving intra-AS VPLS A-D routes .................... 12 92 8 Demultiplexing P-Multicast Tree Traffic ............... 14 93 8.1 One P-Multicast Tree - One VPLS Mapping ............... 14 94 8.2 One P-Multicast Tree - Many VPLS Mapping .............. 14 95 9 Establishing P-Multicast Trees ........................ 15 96 9.1 Common Procedures ..................................... 15 97 9.2 RSVP-TE P2MP LSPs ..................................... 16 98 9.2.1 P2MP TE LSP - VPLS Mapping ............................ 16 99 9.3 Receiver Initiated MPLS Trees ......................... 17 100 9.3.1 P2MP LSP - VPLS Mapping ............................... 17 101 9.4 Encapsulation of Aggregate P-Multicast Trees .......... 17 102 10 Inter-AS Inclusive P-Multicast Tree A-D/Binding ....... 17 103 10.1 VSIs on the ASBRs ..................................... 18 104 10.1.1 Option (a): VSIs on the ASBRs ......................... 18 105 10.1.2 Option (e): VSIs on the ASBRs ......................... 18 106 10.2 Option (b) - Segmented Inter-AS Trees ................. 19 107 10.2.1 Segmented Inter-AS Trees VPLS Inter-AS A-D/Binding .... 19 108 10.2.2 Propagating BGP VPLS A-D routes to other ASes: Overview ..20 109 10.2.2.1 Propagating Intra-AS VPLS A-D routes in EBGP .......... 21 110 10.2.2.2 Inter-AS A-D route received via EBGP .................. 22 111 10.2.2.3 Leaf A-D Route received via EBGP ...................... 24 112 10.2.2.4 Inter-AS A-D Route received via IBGP .................. 24 113 10.3 Option (c): Non-Segmented Tunnels ..................... 25 114 11 Optimizing Multicast Distribution via Selective Trees . 26 115 11.1 Protocol for Switching to Selective Trees ............. 27 116 11.2 Advertising (C-S, C-G) Binding to a Selective Tree .... 28 117 11.3 Receiving S-PMSI A-D routes by PEs .................... 30 118 11.4 Inter-AS Selective Tree ............................... 32 119 11.4.1 VSIs on the ASBRs ..................................... 33 120 11.4.1.1 VPLS Inter-AS Selective Tree A-D Binding .............. 33 121 11.4.2 Inter-AS Segmented Selective Trees .................... 33 122 11.4.2.1 Handling S-PMSI A-D routes by ASBRs ................... 34 123 11.4.2.1.1 Merging Selective Tree into an Inclusive Tree ......... 35 124 11.4.3 Inter-AS Non-Segmented Selective trees ................ 36 125 12 BGP Extensions ........................................ 36 126 12.1 Inclusive Tree/Selective Tree Identifier .............. 36 127 12.2 MCAST-VPLS NLRI ....................................... 37 128 12.2.1 S-PMSI A-D route ...................................... 38 129 12.2.2 Leaf A-D route ........................................ 39 130 13 Aggregation Considerations ............................ 39 131 14 Data Forwarding ....................................... 40 132 14.1 MPLS Tree Encapsulation ............................... 40 133 14.1.1 Mapping multiple VPLS instances to a P2MP LSP ......... 40 134 14.1.2 Mapping one VPLS instance to a P2MP LSP ............... 41 135 15 VPLS Data Packet Treatment ............................ 42 136 16 Security Considerations ............................... 43 137 17 IANA Considerations ................................... 44 138 18 Acknowledgments ....................................... 44 139 19 Normative References .................................. 44 140 20 Informative References ................................ 45 141 21 Author's Address ...................................... 46 143 1. Specification of requirements 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2. Contributors 151 Rahul Aggarwal 152 Yakov Rekhter 153 Juniper Networks 154 Yuji Kamite 155 NTT Communications 156 Luyuan Fang 157 AT&T 158 Chaitanya Kodeboniya 160 3. Terminology 162 This document uses terminology described in [RFC4761] and [RFC4762]. 164 In this document we refer to various auto-discovery routes, as "A-D 165 routes". 167 4. Introduction 169 [RFC4761] and [RFC4762] describe a solution for VPLS multicast that 170 relies on the use of P2P RSVP-TE or MP2P LDP LSPs, referred to as 171 Ingress Replication in this document. This solution has certain 172 limitations for certain VPLS multicast traffic profiles. For example, 173 it may result in highly non-optimal bandwidth utilization in the MPLS 174 network when large amount of multicast traffic is to be transported. 176 This document describes procedures for overcoming the limitations of 177 existing VPLS multicast solutions. It describes procedures for VPLS 178 multicast that utilize multicast trees in the Service Provider (SP) 179 network. The procedures described in this document are applicable to 180 both [RFC4761] and [RFC4762]. 182 It provides mechanisms that allow a single multicast distribution 183 tree in the Service Provider (SP) network to carry all the multicast 184 traffic from one or more VPLS sites connected to a given PE, 185 irrespective of whether these sites belong to the same or different 186 VPLSes. Such a tree is referred to as an "Inclusive tree" and more 187 specifically as an "Aggregate Inclusive tree" when the tree is used 188 to carry multicast traffic from more than one VPLS. 190 This document also provides procedures by which a single multicast 191 distribution tree in the SP network can be used to carry traffic 192 belonging only to a specified set of IP multicast streams, originated 193 in one or more VPLS sites connected to a given PE, irrespective of 194 whether these sites belong to the same or different VPLSes. Such a 195 tree is referred to as a "Selective tree" and more specifically as an 196 "Aggregate Selective tree" when the IP multicast streams belong to 197 different VPLSes. This allows multicast traffic, by default, to be 198 carried on an Inclusive tree, while traffic from some specific 199 multicast streams, e.g., high bandwidth streams, could be carried on 200 one of the "Selective trees". 202 5. Existing Limitations of VPLS Multicast 204 One of the limitations of existing VPLS multicast solutions described 205 in [RFC4761] and [RFC4762] is that they rely on ingress replication. 206 Thus, the ingress PE replicates the multicast packet for each egress 207 PE and sends it to the egress PE using a unicast tunnel. 209 Ingress Replication may be an acceptable model when the bandwidth of 210 the multicast traffic is low or/and the number of replications 211 performed on average on each outgoing interface for a particular 212 customer VPLS multicast packet is small. If this is not the case it 213 is desirable to utilize multicast trees in the SP network to transmit 214 VPLS multicast packets [RFC5501]. Note that unicast packets that are 215 flooded to each of the egress PEs, before the ingress PE learns the 216 destination MAC address of those unicast packets, MAY still use 217 ingress replication. 219 6. Overview 221 This document describes procedures for using multicast trees in the 222 SP network to transport VPLS multicast data packets. RSVP-TE P2MP 223 LSPs described in [RFC4875] are an example of such multicast trees. 224 The use of multicast trees in the SP network can be beneficial when 225 the bandwidth of the multicast traffic is high or when it is 226 desirable to optimize the number of copies of a multicast packet 227 transmitted on a given link. This comes at a cost of state in the SP 228 network to build multicast trees and overhead to maintain this state. 229 This document describes procedures for using multicast trees for VPLS 230 multicast when the provider tunnels are P2MP LSPs signaled by either 231 P2MP RSVP-PE or mLDP [RFC6388]. 233 This document uses the prefix 'C' to refer to the customer control or 234 data packets and 'P' to refer to the provider control or data 235 packets. An IP (multicast source, multicast group) tuple is 236 abbreviated to (S, G). 238 6.1. Inclusive and Selective Multicast Trees 240 Multicast trees used for VPLS can be of two types: 242 + Inclusive trees. This option supports the use of a single 243 multicast distribution tree, referred to as an Inclusive P- 244 Multicast tree, in the SP network to carry all the multicast 245 traffic from a specified set of VPLS sites connected to a given 246 PE. There is no assumption made with respect to whether this 247 traffic is IP encapsulated or not. A particular P-Multicast tree 248 can be set up to carry the traffic originated by sites belonging 249 to a single VPLS, or to carry the traffic originated by sites 250 belonging to different VPLSes. The ability to carry the traffic 251 of more than one VPLS on the same tree is termed Aggregation. The 252 tree needs to include every PE that is a member of any of the 253 VPLSes that are using the tree. This implies that a PE may 254 receive multicast traffic for a multicast stream even if it 255 doesn't have any receivers that are interested in receiving 256 traffic for that stream. 258 An Inclusive P-Multicast tree as defined in this document is a 259 P2MP tree. A P2MP tree is used to carry traffic only from VPLS 260 sites that are connected to the PE that is the root of the tree. 262 + Selective trees. A Selective P-Multicast tree is used by a PE to 263 send IP multicast traffic for one or more specific IP multicast 264 streams, received by a PE over PE-CE interfaces that belong to 265 the same or different VPLSes, to a subset of the PEs that belong 266 to those VPLSes. Each of the PEs in the subset should be on the 267 path to a receiver of one or more multicast streams that are 268 mapped onto the tree. The ability to use the same tree for 269 multicast streams that belong to different VPLSes is termed 270 Aggregation. The reason for having Selective P-Multicast trees is 271 to provide a PE the ability to create separate SP multicast trees 272 for specific multicast streams, e.g. high bandwidth multicast 273 streams. This allows traffic for these multicast streams to reach 274 only those PE routers that have receivers in these streams. This 275 avoids flooding other PE routers in the VPLS. 277 A SP can use both Inclusive P-Multicast trees and Selective P- 278 Multicast trees or either of them for a given VPLS on a PE, based on 279 local configuration. Inclusive P-Multicast trees can be used for 280 both IP and non-IP data multicast traffic, while Selective P- 281 Multicast trees must be used only for IP multicast data traffic. The 282 use of Selective P-Multicast trees for non-IP multicast traffic is 283 outside the scope of this document. 285 A variety of transport technologies may be used in the SP network. 286 For inclusive P-Multicast trees, these transport technologies include 287 point-to-multipoint LSPs created by RSVP-TE or mLDP. For selective P- 288 Multicast trees, unicast PE-PE tunnels (using MPLS or IP/GRE 289 encapsulation) and P2MP LSPs are supported, and the supported P2MP 290 LSP signaling protocols are RSVP-TE, and mLDP. Other transport 291 technologies are outside the scope of this document. 293 This document also describes the data plane encapsulations for 294 supporting the various SP multicast transport options. 296 6.2. BGP-Based VPLS Membership Auto-Discovery 298 In order to establish Inclusive P-Multicast trees for one or more 299 VPLSes, when aggregation is performed (with either mLDP or P2MP RSVP- 300 TE as the tunneling technology), or when the tunneling technology is 301 P2MP RSVP-TE, the PE acting as a root of a P2MP LSP must be able to 302 discover the other PEs that have membership in one or more of these 303 VPLSes (these other PEs act as leaves of that P2MP LSP). This 304 document uses the BGP-based procedures described in [RFC4761] and 305 [RFC6074] for discovering the VPLS membership of all PEs. When no 306 aggregation is performed and the tunneling technology is mLDP, then 307 the root of the P2MP LSP need not discover the other PEs that are the 308 leaves of that LSP. 310 The leaves of the Inclusive P-Multicast tree must also be able to 311 auto-discover the identifier of the tree (note that this applies when 312 the tree is established by either mLDP or P2MP RSVP-TE). This is 313 described in section 6.4. 315 6.3. IP Multicast Group Membership Discovery 317 The setup of a Selective P-Multicast tree for one or more IP 318 multicast (C-S, C-G)s, requires the ingress PE to learn the PEs that 319 have receivers in one or more of these (C-S, C-G)s, in the following 320 cases: 322 + When aggregation is used OR 324 + When the tunneling technology is P2MP RSVP-TE 326 + If ingress replication is used and the ingress PE wants to send 327 traffic for (C-S, C-G)s to only those PEs that are on the path to 328 receivers for the (C-S,C-G)s. 330 For discovering the IP multicast group membership, this document 331 describes procedures that allow an ingress PE to enable explicit 332 tracking. Thus an ingress PE can request the IP multicast membership 333 from egress PEs for one or more C-multicast streams. These procedures 334 are described in section "Optimizing Multicast Distribution via 335 Selective Trees". 337 These procedures are applicable when IGMP is used as the multicast 338 signaling protocol between the VPLS CEs. They are also applicable 339 when PIM as specified in [RFC4601] is used as the multicast routing 340 protocol between the VPLS CEs and PIM join suppression is disabled on 341 all the CEs. However these procedures do not apply when PIM is used 342 as the multicast routing protocol between the VPLS CEs and PIM join 343 suppression is not disabled on all the CEs. Procedures for this case 344 are for further study. 346 The leaves of the Selective P-Multicast trees must also be able to 347 discover the identifier of the tree. This is described in section 348 6.4. 350 6.4. Advertising P-Multicast Tree to VPLS/C-Multicast Binding 352 This document describes procedures based on BGP VPLS Auto-Discovery 353 (A-D) that are used by the root of an Aggregate P-Multicast tree to 354 advertise the Inclusive or Selective P-Multicast tree binding and the 355 de-multiplexing information to the leaves of the tree. This document 356 uses the PMSI Tunnel attribute [RFC6514] for this purpose. 358 Once a PE decides to bind a set of VPLSes or customer multicast 359 groups to an Inclusive P-Multicast tree or a Selective P-Multicast 360 tree, it needs to announce this binding to other PEs in the network. 361 This procedure is referred to as Inclusive P-Multicast tree or 362 Selective P-Multicast tree binding distribution and is performed 363 using BGP. 365 When an Aggregated Inclusive P-Multicast tree is used by an ingress 366 PE, this discovery implies that an ingress PE MUST announce the 367 binding of all VPLSes bound to the Inclusive P-Multicast tree to the 368 other PEs. The inner label assigned by the ingress PE for each VPLS 369 MUST be included, if more than one VPLS is bound to the same P- 370 Multicast tree. The Inclusive P-Multicast tree Identifier MUST be 371 included. 373 For a Selective P-Multicast tree this discovery implies announcing 374 all the specific entries bound to this P-Multicast tree 375 along with the Selective P-Multicast tree Identifier. The inner label 376 assigned for each MUST be included if s from 377 different VPLSes are bound to the same P-Multicast tree. The labels 378 MUST be distinct on a per VPLS basis and MAY be distinct on a per basis. The Selective P-Multicast tree Identifier MUST be 380 included. 382 6.5. Aggregation 384 As described above the ability to carry the traffic of more than one 385 VPLS on the same P-Multicast tree is termed 'Aggregation'. Both 386 Inclusive and Selective P-Multicast trees support aggregation. 388 Aggregation enables the SP to place a bound on the amount of 389 multicast tree forwarding and control plane state which the P routers 390 must have. Let us call the number of VPLSes aggregated onto a single 391 P-Multicast tree as the "Aggregation Factor". When Inclusive source 392 P-Multicast trees are used the number of trees that a PE is the root 393 of is proportional to: 395 + (Number of VPLSes on the PE / Aggregation Factor). 397 In this case the state maintained by a P router, is proportional to: 399 + ((Average number of VPLSes on a PE / Aggregation Factor) * number 400 of PEs) / (Average number of P-Multicast trees that transit a 401 given P router) 403 Thus, the state does not grow linearly with the number of VPLSes. 405 Aggregation requires a mechanism for the egresses of the P-Multicast 406 tree to demultiplex the multicast traffic received over the P- 407 Multicast tree. To enable the egress nodes to perform this 408 demultiplexing, upstream-assigned labels [RFC5331] MUST be assigned 409 and distributed by the root of the aggregate P-multicast tree." 411 6.6. Inter-AS VPLS Multicast 413 This document supports four models of inter-AS VPLS service, option 414 (a), (b), (c), and (e). Options (a), (b), and (c) are very similar 415 conceptually to options (a), (b) and (c) specified in [RFC4364] for 416 IP VPNs. These options described here are also similar to the three 417 options described in [RFC4761], which in turn extends the concepts of 418 [RFC4364] to inter-AS VPLS. 420 For option (a) and option (b) support, this document specifies a 421 model where Inter-AS VPLS service can be offered without requiring a 422 single P-Multicast tree to span multiple ASes. There are two variants 423 of this model and they are described in section 10. 425 For option (c) support this document specifies a model where Inter-AS 426 VPLS service is offered by requiring a single P-Multicast tree to 427 span multiple ASes. This is because in the case of option (c) the 428 ASBRs do not exchange BGP-VPLS NLRIs or A-D routes. 430 In addition, this document also specifies option (e), which one may 431 think of as a variant of option (a). 433 7. Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding 435 This section specifies procedures for the intra-AS auto-discovery of 436 VPLS membership and the distribution of information used to 437 instantiate P-Multicast Tunnels. 439 VPLS auto-discovery/binding consists of two components: intra-AS and 440 inter-AS. The former provides VPLS auto-discovery/binding within a 441 single AS. The latter provides VPLS auto-discovery/binding across 442 multiple ASes. Inter-AS auto-discovery/binding is described in 443 section 10. 445 VPLS auto-discovery using BGP as described in [RFC4761, RFC6074] 446 enables a PE to learn the VPLS membership of other PEs. A PE that 447 belongs to a particular VPLS announces a BGP Network Layer 448 Reachability Information (NLRI) that identifies the Virtual Switch 449 Instance (VSI). This NLRI is constructed from the tuple. The 451 NLRI defined in [RFC4761] comprises the tuple and label 452 blocks for PW signaling. The VE-ID in this case is a two octet 453 number. The NLRI defined in [RFC6074] comprises only the 454 where the VE-ID is a four octet number. 456 The procedures for constructing Inclusive intra-AS and inter-AS trees 457 as specified in this document require the BGP A-D NLRI to carry only 458 the . Hence these procedures can be used for both BGP-VPLS 459 and LDP-VPLS with BGP A-D. 461 It is to be noted that BGP A-D is an inherent feature of BGP-VPLS. 462 However it is not an inherent feature of LDP-VPLS. In fact there are 463 deployments and/or implementations of LDP-VPLS that require 464 configuration to enable a PE in a particular VPLS to determine other 465 PEs in the VPLS and exchange PW labels using FEC 128 [RFC4447]. The 466 use of BGP A-D for LDP-VPLS [RFC6074], to enable automatic setup of 467 PWs, requires FEC 129 [RFC4447]. However FEC 129 is not required in 468 order to use procedures in this document for LDP-VPLS. An LDP-VPLS 469 implementation that supports this document MUST support the BGP A-D 470 procedures to setup P-Multicast trees, as described here, and it MAY 471 support FEC 129 to automate the signaling of PWs. 473 7.1. Originating intra-AS VPLS A-D routes 475 To participate in the VPLS auto-discovery/binding a PE router that 476 has a given VSI of a given VPLS originates an BGP VPLS intra-AS A-D 477 route and advertises this route in Multi-Protocol (MP) IBGP. The 478 route is constructed as described in [RFC4761] and [RFC6074]. 480 The route carries a single L2VPN NLRI with the RD set to the RD of 481 the VSI, and the VE-ID set to the VE-ID of the VSI. The route also 482 carries one or more Rout Targets (RTs) as specified in [RFC4761] and 483 [RFC6074]. 485 If an Inclusive P-Multicast tree is used to instantiate the provider 486 tunnel for VPLS multicast on the PE, the advertising PE MUST 487 advertise the type and the identity of the P-Multicast tree in the 488 PMSI Tunnel attribute [RFC6514]. This attribute is described in 489 section 12.1. 491 A PE that uses an Inclusive P-Multicast tree to instantiate the 492 provider tunnel MAY aggregate two or more VPLSes present on the PE 493 onto the same tree. If the PE decides to perform aggregation after it 494 has already advertised the intra-AS VPLS A-D routes for these VPLSes, 495 then aggregation requires the PE to re-advertise these routes. The 496 re-advertised routes MUST be the same as the original ones, except 497 for the PMSI Tunnel attribute. If the PE has not previously 498 advertised intra-AS A-D routes for these VPLSes, then the aggregation 499 requires the PE to advertise (new) intra-AS A-D routes for these 500 VPLSes. The PMSI attribute in the newly advertised/re-advertised 501 routes MUST carry the identity of the P-Multicast tree that 502 aggregates the VPLSes, as well as an MPLS upstream-assigned label 503 [RFC5331]. Each re-advertised route MUST have a distinct label. 505 Discovery of PE capabilities in terms of what tunnels types they 506 support is outside the scope of this document. Within a given AS PEs 507 participating in a VPLS are expected to advertise tunnel bindings 508 whose tunnel types are supported by all other PEs that are 509 participating in this VPLS and are part of the same AS. 511 7.2. Receiving intra-AS VPLS A-D routes 513 When a PE receives a BGP Update message that carries an intra-AS A-D 514 route such that (a) the route was originated by some other PE within 515 the same AS as the local PE, (b) at least one of the Route Targets of 516 the route matches one of the import Route Targets configured for a 517 particular VSI on the local PE, (c) the BGP route selection 518 determines that this is the best route with respect to the NLRI 519 carried by the route, and (d) the route carries the PMSI Tunnel 520 attribute, the PE performs the following. 522 If the route carries the PMSI Tunnel attribute then: 524 + If the Tunnel Type in the PMSI Tunnel attribute is set to LDP 525 P2MP LSP, the PE SHOULD join the P-Multicast tree whose identity 526 is carried in the PMSI Tunnel attribute. 528 + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE 529 P2MP LSP, the receiving PE has to establish the appropriate state 530 to properly handle the traffic received over that LSP. The PE 531 that originated the route MUST establish an RSVP-TE P2MP LSP with 532 the local PE as a leaf. This LSP MAY have been established before 533 the local PE receives the route. 535 + If the PMSI Tunnel attribute does not carry a label, then all 536 packets that are received on the P-Multicast tree, as identified 537 by the PMSI Tunnel attribute, are forwarded using the VSIs that 538 have at least one of its import Route Targets that matches one of 539 the Route Targets of the received A-D route. 541 + If the PMSI Tunnel attribute has the Tunnel Type set to LDP P2MP 542 LSP or RSVP-TE P2MP LSP, and the attribute also carries an MPLS 543 label, then the egress PE MUST treat this as an upstream-assigned 544 label, and all packets that are received on the P-Multicast tree, 545 as identified by the PMSI Tunnel attribute, with that upstream 546 label are forwarded using the VSIs that have at least one of its 547 import Route Target that matches one of the Route Targets of the 548 received intra-AS A-D route. 550 If the local PE uses RSVP-TE P2MP LSP for sending (multicast) 551 traffic, originated by VPLS sites connected to the PE, to the sites 552 attached to other PEs then the local PE MUST use the Originating 553 Router's IP address information carried in the intra-AS A-D route to 554 add the PE, that originated the route, as a leaf node to the LSP. 555 This MUST be done irrespective of whether the received Intra-AS A-D 556 route carries the PMSI Tunnel attribute or not. 558 8. Demultiplexing P-Multicast Tree Traffic 560 Demultiplexing received VPLS traffic requires the receiving PE to 561 determine the VPLS instance the packet belongs to. The egress PE can 562 then perform a VPLS lookup to further forward the packet. It also 563 requires the egress PE to determine the identity of the ingress PE 564 for MAC learning, as described in section 15. 566 8.1. One P-Multicast Tree - One VPLS Mapping 568 When a P-Multicast tree is mapped to only one VPLS, determining the 569 tree on which the packet is received is sufficient to determine the 570 VPLS instance on which the packet is received. The tree is determined 571 based on the tree encapsulation. If MPLS encapsulation is used, 572 e.g.,: RSVP-TE P2MP LSPs, the outer MPLS label is used to determine 573 the tree. Penultimate-hop-popping MUST be disabled on the MPLS LSP 574 (RSVP-TE P2MP LSP or LDP P2MP LSP). 576 8.2. One P-Multicast Tree - Many VPLS Mapping 578 As traffic belonging to multiple VPLSes can be carried over the same 579 tree, there is a need to identify the VPLS the packet belongs to. 580 This is done by using an inner label that determines the VPLS for 581 which the packet is intended. The ingress PE uses this label as the 582 inner label while encapsulating a customer multicast data packet. 583 Each of the egress PEs must be able to associate this inner label 584 with the same VPLS and use it to demultimplex the traffic received 585 over the Aggregate Inclusive tree or the Aggregate Selective tree. 587 If traffic from multiple VPLSes is carried on a single tree, 588 upstream-assigned labels [RFC5331] MUST be used. Hence the inner 589 label is assigned by the ingress PE. When the egress PE receives a 590 packet over an Aggregate tree, the outer encapsulation (in the case 591 of MPLS P2MP LSPs, the outer MPLS label) specifies the label space to 592 perform the inner label lookup. The same label space MUST be used by 593 the egress PE for all P-Multicast trees that have the same root 594 [RFC5331]. 596 If the tree uses MPLS encapsulation, as in RSVP-TE P2MP LSPs, the 597 outer MPLS label and optionally the incoming interface provides the 598 label space of the label beneath it. This assumes that penultimate- 599 hop-popping is disabled. The egress PE MUST NOT advertise IMPLICIT 600 NULL or EXPLICIT NULL for that tree once it is known to the egress PE 601 that the tree is bound to one or more VPLSes. Once the label 602 representing the tree is popped off the MPLS label stack, the next 603 label is the demultiplexing information that allows the proper VPLS 604 instance to be determined. 606 The ingress PE informs the egress PEs about the inner label as part 607 of the tree binding procedures described in section 12. 609 9. Establishing P-Multicast Trees 611 This document supports only P2MP P-Multicast trees wherein it is 612 possible for egress PEs to identify the ingress PE to perform MAC 613 learning. Specific procedures are specified only for RSVP-TE P2MP 614 LSPs and LDP P2MP LSPs. An implementation that supports this document 615 MUST support RSVP-TE P2MP LSPs and LDP P2MP LSPs. 617 A P2MP tree is used to carry traffic originated in sites connected to 618 the PE which is the root of the tree. These sites MAY belong to 619 different VPLSes or the same VPLS. 621 9.1. Common Procedures 623 The following procedures apply to both RSVP-TE P2MP and LDP P2MP 624 LSPs. 626 Demultiplexing the C-multicast data packets at the egress PE requires 627 that the PE must be able to determine the P2MP LSP that the packets 628 are received on. This enables the egress PE to determine the VPLS 629 instances that the packet belongs to. To achieve this the LSP MUST be 630 signaled with penultimate-hop-popping (PHP) off and a non-reserved 631 MPLS label off as described in section 8. In other words an egress PE 632 MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for a P2MP LSP that 633 is carrying traffic for one or more VPLSes. This is because the 634 egress PE needs to rely on the MPLS label, that it advertises to its 635 upstream neighbor, to determine the P2MP LSP that a C-multicast data 636 packet is received on. 638 The egress PE also needs to identify the ingress PE to perform MAC 639 learning. When P2MP LSPs are used as P2MP trees, determining the 640 P2MP LSP that the packets are received on, is sufficient to determine 641 the ingress PE. This is because the ingress PE is the root of the 642 P2MP LSP. 644 The egress PE relies on receiving the PMSI Tunnel attribute in BGP to 645 determine the VPLS instance to P2MP LSP mapping. 647 9.2. RSVP-TE P2MP LSPs 649 This section describes procedures that are specific to the usage of 650 RSVP-TE P2MP LSPs for instantiating a P-Multicast tree. Procedures in 651 [RFC4875] are used to signal the P2MP LSP. The LSP is signaled as the 652 root of the P2MP LSP discovers the leaves. The egress PEs are 653 discovered using the procedures described in section 7. Aggregation 654 as described in this document is supported. 656 9.2.1. P2MP TE LSP - VPLS Mapping 658 P2MP TE LSP to VPLS mapping is learned at the egress PEs using BGP 659 based advertisements of the P2MP TE LSP - VPLS mapping. They require 660 that the root of the tree include the P2MP TE LSP identifier as the 661 tunnel identifier in the BGP advertisements. This identifier contains 662 the following information elements: 663 - The type of the tunnel is set to RSVP-TE P2MP LSP 664 - RSVP-TE P2MP LSP's SESSION Object 666 This Tunnel Identifier is described in section 12.1. 668 Once the egress PE receives the P2MP TE LSP to VPLS mapping: 670 + If the egress PE already has RSVP-TE state for the P2MP TE LSP, 671 it MUST begin to assign an MPLS label from the non-reserved label 672 range, for the P2MP TE LSP and signal this to the previous hop of 673 the P2MP TE LSP. Further it MUST create forwarding state to 674 forward packets received on the P2MP LSP. 676 + If the egress PE does not have RSVP-TE state for the P2MP TE LSP, 677 it MUST retain this mapping. Subsequently when the egress PE 678 receives the RSVP-TE P2MP signaling message, it creates the RSVP- 679 TE P2MP LSP state. It MUST then assign an MPLS label from the 680 non-reserved label range, for the P2MP TE LSP, and signal this to 681 the previous hop of the P2MP TE LSP. 683 Note that if the signaling to set up an RSVP-TE P2MP LSP is 684 completed before a given egress PE learns, via a PMSI Tunnel 685 attribute, of the VPLS or set of VPLSes to which the LSP is 686 bound, the PE MUST discard any traffic received on that LSP until 687 the binding is received. In order for the egress PE to be able to 688 discard such traffic it needs to know that the LSP is associated 689 with one or more VPLSes and that the VPLS A-D route that binds 690 the LSP to a VPLS has not yet been received. This is provided by 691 extending [RFC4875] with [RFC6511]. 693 9.3. Receiver Initiated MPLS Trees 695 Receiver initiated P2MP MPLS trees signaled using LDP [RFC6388] can 696 also be used. Procedures in [RFC6388] MUST be used to signal the P2MP 697 LSP. The LSP is signaled once the leaves receive the LDP FEC for the 698 tree from the root as described in section 7. An ingress PE is 699 required to discover the egress PEs when aggregation is used and this 700 is achieved using the procedures in section 7. 702 9.3.1. P2MP LSP - VPLS Mapping 704 P2MP LSP to VPLS mapping is learned at the egress PEs using BGP based 705 advertisements of the P2MP LSP - VPLS mapping. They require that the 706 root of the tree include the P2MP LSP identifier as the tunnel 707 identifier in the BGP advertisements. This identifier contains the 708 following information elements: 709 - The type of the tunnel is set to LDP P2MP LSP 710 - LDP P2MP FEC which includes an identifier generated by the 711 root. 713 Each egress PE SHOULD "join" the P2MP MPLS tree by sending LDP label 714 mapping messages for the LDP P2MP FEC, that was learned in the BGP 715 advertisement, using procedures described in [RFC6388]. 717 9.4. Encapsulation of Aggregate P-Multicast Trees 719 An Aggregate Inclusive P-Multicast tree or an Aggregate Selective P- 720 Multicast tree MUST use MPLS encapsulation. The protocol type in the 721 data link header is as described in [RFC5332]. 723 10. Inter-AS Inclusive P-Multicast Tree A-D/Binding 725 This document supports four options of inter-AS VPLS service, option 726 (a), (b), (c) and (e). Of these option (a), (b) and (c) are very 727 similar conceptually to option (a), (b) and (c) specified in 728 [RFC4364] for IP VPNs. These three options are also similar to the 729 three options described in [RFC4761], which in turn extend the 730 concepts of [RFC4364] to inter-AS VPLS. An implementation MUST 731 support all three of these options. When there are multiple ways for 732 implementing one of these options this section specifies which one is 733 mandatory. Option (e) is described further down in section 10.1.2. 735 For option (a), (b) and (e) support this section specifies a model 736 where inter-AS VPLS service can be offered without requiring a single 737 P-Multicast tree to span multiple ASes. This allows individual ASes 738 to potentially use different P-tunneling technologies. There are two 739 variants of this model. One that requires MAC lookup on the ASBRs and 740 applies to option (a) and (e). The other is one that does not require 741 MAC lookup on the ASBRs and instead builds segmented inter-AS 742 Inclusive or Selective trees. This applies only to option (b). 744 For option (c) support this document specifies a model where Inter-AS 745 VPLS service is offered by requiring a single Inclusive P-Multicast 746 tree to span multiple ASes. This is referred to as a non-segmented P- 747 Multicast tree. This is because in the case of option (c) the ASBRs 748 do not exchange BGP-VPLS NLRIs or VPLS A-D routes. Selective inter-AS 749 trees for option (c) support may be segmented or non-segmented. 751 10.1. VSIs on the ASBRs 753 When VSIs are configured on ASBRs, the ASBRs MUST perform a MAC 754 lookup, in addition to any MPLS lookups, to determine the forwarding 755 decision on a VPLS packet. The P-Multicast trees are confined to an 756 AS. An ASBR on receiving a VPLS packet from another ASBR is required 757 to perform a MAC lookup to determine how to forward the packet. Thus 758 an ASBR is required to keep a VSI for the VPLS and MUST be configured 759 with its own VE ID for the VPLS. The BGP VPLS A-D routes generated by 760 PEs in an AS MUST NOT be propagated outside the AS. 762 10.1.1. Option (a): VSIs on the ASBRs 764 When VSIs are configured on ASBRs and option (a) is used then an ASBR 765 in one AS treats an adjoining ASBR in another AS as a CE and 766 determines the VSI for packets received from that ASBR based on the 767 incoming Ethernet interface or VLAN ID. In option (a) the ASBRs do 768 not exchange VPLS A-D routes. 770 An implementation MUST support option (a). 772 10.1.2. Option (e): VSIs on the ASBRs 774 The VSIs on the ASBRs scheme can be used such that the interconnect 775 between the ASBRs is a PW and MPLS encapsulation is used between the 776 ASBRs. An ASBR in one AS treats an adjoining ASBR in another AS as a 777 CE and determines the VSI for packets received from another ASBR 778 based on the incoming MPLS encapsulation. This is referred to as 779 option (e). The only VPLS A-D routes that are propagated outside the 780 AS are the ones originated by ASBRs. This MPLS PW connects the VSIs 781 on the ASBRs and MUST be signaled using the procedures defined in 782 [RFC4761] or [RFC4762]. 784 The P-Multicast trees for a VPLS are confined to each AS and the VPLS 785 auto-discovery/binding MUST follow the intra-AS procedures described 786 in section 8. An implementation MAY support option (e). 788 10.2. Option (b) - Segmented Inter-AS Trees 790 In this model, an inter-AS P-Multicast tree, rooted at a particular 791 PE for a particular VPLS instance, consists of a number of 792 "segments", one per AS, which are stitched together at ASBRs. These 793 are known as "segmented inter-AS trees". Each segment of a segmented 794 inter-AS tree may use a different multicast transport technology. In 795 this model, an ASBR is not required to keep a VSI for the VPLS and is 796 not required to perform a MAC lookup in order to forward the VPLS 797 packet. This implies that an ASBR is not required to be configured 798 with a VE ID for the VPLS. This model is applicable to option (b). An 799 implementation MUST support option (b) using this model. 801 The construction of segmented Inter-AS trees requires the BGP-VPLS A- 802 D NLRI described in [RFC4761, RFC6074]. A BGP VPLS A-D route for a 803 tuple advertised outside the AS, to which the originating 804 PE belongs, will be referred to as an inter-AS VPLS A-D route (Though 805 this route is originated by a PE as an intra-AS route and is referred 806 to as an inter-AS route outside the AS). 808 In addition to this, segmented inter-AS trees require support for the 809 PMSI Tunnel attribute described in section 12.1. They also require 810 additional procedures in BGP to signal leaf A-D routes between ASBRs 811 as explained in subsequent sections. 813 10.2.1. Segmented Inter-AS Trees VPLS Inter-AS A-D/Binding 815 This section specifies the procedures for inter-AS VPLS A-D/binding 816 for segmented inter-AS trees. 818 An ASBR must be configured to support a particular VPLS as follows: 820 + An ASBR MUST be configured with a set of (import) Route Targets 821 (RTs) that specify the set of VPLSes supported by the ASBR. These 822 Route Targets control acceptance of BGP VPLS auto-discovery 823 routes by the ASBR. Note that instead of being configured, the 824 ASBR MAY obtain this set of (import) Route Targets (RTs) by using 825 Route Target Constrain [RFC4684]. 827 + The ASBR MUST be configured with the tunnel types for the intra- 828 AS segments of the VPLSes supported by the ASBR, as well as 829 (depending on the tunnel type) the information needed to create 830 the PMSI Tunnel attribute for these tunnel types. Note that 831 instead of being configured, the ASBR MAY derive the tunnel types 832 from the intra-AS A-D routes received by the ASBR from the PEs in 833 its own AS. 835 If an ASBR is configured to support a particular VPLS, the ASBR MUST 836 participate in the intra-AS VPLS auto-discovery/binding procedures 837 for that VPLS within the ASBR's own AS, as defined in this document. 839 Moreover, in addition to the above the ASBR performs procedures 840 specified in the next section. 842 10.2.2. Propagating BGP VPLS A-D routes to other ASes: Overview 844 An A-D route for a given VPLS, originated by an ASBR within a given 845 AS, is propagated via BGP to other ASes. The precise rules for 846 distributing and processing the inter-AS A-D routes are given in 847 subsequent sections. 849 Suppose that an ASBR A receives and installs an A-D route for VPLS 850 "X" and VE ID "V" that originated at a particular PE, PE1. The BGP 851 next hop of that received route becomes A's "upstream neighbor" on a 852 multicast distribution tree for (X, V) that is rooted at PE1. When 853 the A-D routes have been distributed to all the necessary ASes, they 854 define a "reverse path" from any AS that supports VPLS X and VE ID V 855 back to PE1. For instance, if AS2 supports VPLS X, then there will be 856 a reverse path for VPLS X and VE ID V from AS2 to AS1. This path is a 857 sequence of ASBRs, the first of which is in AS2, and the last of 858 which is in AS1. Each ASBR in the sequence is the BGP next hop of the 859 previous ASBR in the sequence. 861 This reverse path information can be used to construct a 862 unidirectional multicast distribution tree for VPLS X and VE ID V, 863 containing all the ASes that support X, and having PE1 at the root. 864 We call such a tree an "inter-AS tree". Multicast data originating in 865 VPLS sites for VPLS X connected to PE1 will travel downstream along 866 the tree which is rooted at PE1. 868 The path along an inter-AS tree is a sequence of ASBRs. It is still 869 necessary to specify how the multicast data gets from a given ASBR to 870 the set of ASBRs which are immediately downstream of the given ASBR 871 along the tree. This is done by creating "segments": ASBRs in 872 adjacent ASes will be connected by inter-AS segments, ASBRs in the 873 same AS will be connected by "intra-AS segments". 875 For a given inter-AS tree and a given AS there MUST be only one ASBR 876 within that AS that accepts traffic flowing on that tree. Further for 877 a given inter-AS tree and a given AS there MUST be only one ASBR in 878 that AS that sends the traffic flowing on that tree to a particular 879 adjacent AS. The precise rules for accomplishing this are given in 880 subsequent sections. 882 An ASBR initiates creation of an intra-AS segment when the ASBR 883 receives an inter-AS A-D route from an EBGP neighbor. Creation of 884 the segment is completed as a result of distributing, via IBGP, this 885 route within the ASBR's own AS. 887 For a given inter-AS tunnel each of its intra-AS segments could be 888 constructed by its own independent mechanism. Moreover, by using 889 upstream-assigned labels within a given AS multiple intra-AS segments 890 of different inter-AS tunnels of either the same or different VPLSes 891 may share the same P-Multicast tree. 893 If the P-Multicast tree instantiating a particular segment of an 894 inter-AS tunnel is created by a multicast control protocol that uses 895 receiver-initiated joins (e.g, mLDP), and this P-Multicast tree does 896 not aggregate multiple segments, then all the information needed to 897 create that segment will be present in the inter-AS A-D routes 898 received by the ASBR from the neighboring ASBR. But if the P- 899 Multicast tree instantiating the segment is created by a protocol 900 that does not use receiver-initiated joins (e.g., RSVP-TE, ingress 901 unicast replication), or if this P-Multicast tree aggregates multiple 902 segments (irrespective of the multicast control protocol used to 903 create the tree), then the ASBR needs to learn the leaves of the 904 segment. These leaves are learned from A-D routes received from other 905 PEs in the AS, for the same VPLS as the one that the segment belongs 906 to. 908 The following sections specify procedures for propagation of inter-AS 909 A-D routes across ASes in order to construct inter-AS segmented 910 trees. 912 10.2.2.1. Propagating Intra-AS VPLS A-D routes in EBGP 914 For a given VPLS configured on an ASBR when the ASBR receives intra- 915 AS A-D routes originated by PEs in its own AS, the ASBR MUST 916 propagate each of these route in EBGP. This procedure MUST be 917 performed for each of the VPLSes configured on the ASBR. Each of 918 these routes is constructed as follows: 920 + The route carries a single BGP VPLS A-D NLRI with the RD and VE 921 ID being the same as the NLRI in the received intra-AS A-D route. 923 + The Next Hop field of the MP_REACH_NLRI attribute is set to a 924 routable IP address of the ASBR. 926 + The route carries the PMSI Tunnel attribute with the Tunnel Type 927 set to Ingress Replication; the attribute carries no MPLS labels. 929 + The route MUST carry the export Route Target used by the VPLS. 931 10.2.2.2. Inter-AS A-D route received via EBGP 933 When an ASBR receives from one of its EBGP neighbors a BGP Update 934 message that carries an inter-AS A-D route, if (a) at least one of 935 the Route Targets carried in the message matches one of the import 936 Route Targets configured on the ASBR, and (b) the ASBR determines 937 that the received route is the best route to the destination carried 938 in the NLRI of the route, the ASBR re-advertises this inter-AS A-D 939 route to other PEs and ASBRs within its own AS. The best route 940 selection procedures MUST ensure that for the same destination, all 941 ASBRs in an AS pick the same route as the best route. The best route 942 selection procedures are specified in [RFC4761] and clarified in 943 [MULTI-HOMING]. The best route procedures ensure that if multiple 944 ASBRs, in an AS, receive the same inter-AS A-D route from their EBGP 945 neighbors, only one of these ASBRs propagates this route in IBGP. 946 This ASBR becomes the root of the intra-AS segment of the inter-AS 947 tree and ensures that this is the only ASBR that accepts traffic into 948 this AS from the inter-AS tree. 950 When re-advertising an inter-AS A-D route the ASBR MUST set the Next 951 Hop field of the MP_REACH_NLRI attribute to a routable IP address of 952 the ASBR. 954 Depending on the type of a P-Multicast tunnel used to instantiate the 955 intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute of 956 the re-advertised inter-AS A-D route is constructed as follows: 958 + If the ASBR uses ingress replication to instantiate the intra-AS 959 segment of the inter-AS tunnel, the re-advertised route MUST NOT 960 carry the PMSI Tunnel attribute. 962 + If the ASBR uses a P-Multicast tree to instantiate the intra-AS 963 segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST 964 contain the identity of the tree that is used to instantiate the 965 segment (note that the ASBR could create the identity of the tree 966 prior to the actual instantiation of the segment). If in order to 967 instantiate the segment the ASBR needs to know the leaves of the 968 tree, then the ASBR obtains this information from the A-D routes 969 received from other PEs/ASBRs in ASBR's own AS. 971 + An ASBR that uses a P-Multicast tree to instantiate the intra-AS 972 segment of the inter-AS tunnel MAY aggregate two or more VPLSes 973 present on the ASBR onto the same tree. If the ASBR already 974 advertises inter-AS A-D routes for these VPLSes, then aggregation 975 requires the ASBR to re-advertise these routes. The re-advertised 976 routes MUST be the same as the original ones, except for the PMSI 977 Tunnel attribute. If the ASBR has not previously advertised 978 inter-AS A-D routes for these VPLSes, then the aggregation 979 requires the ASBR to advertise (new) inter-AS A-D routes for 980 these VPLSes. The PMSI Tunnel attribute in the newly 981 advertised/re-advertised routes MUST carry the identity of the P- 982 Multicast tree that aggregates the VPLSes, as well as an MPLS 983 upstream-assigned label [RFC5331]. Each re-advertised route MUST 984 have a distinct label. 986 In addition the ASBR MUST send to the EBGP neighbor, from whom it 987 receives the inter-AS A-D route, a BGP Update message that carries a 988 leaf A-D route. The exact encoding of this route is described in 989 section 12. This route contains the following information elements: 991 + The route carries a single NLRI with the Route Key field set to 992 the tuple of the BGP VPLS A-D NLRI of the inter-AS A- 993 D route received from the EBGP neighbor. The NLRI also carries 994 the IP address of the ASBR (this MUST be a routable IP address). 996 + The leaf A-D route MUST include the PMSI Tunnel attribute with 997 the Tunnel Type set to Ingress Replication, and the Tunnel 998 Identifier set to a routable address of the advertising router. 999 The PMSI Tunnel attribute MUST carry a downstream assigned MPLS 1000 label that is used to demultiplex the VPLS traffic received over 1001 a unicast tunnel by the advertising router. 1003 + The Next Hop field of the MP_REACH_NLRI attribute of the route 1004 SHOULD be set to the same IP address as the one carried in the 1005 Originating Router's IP Address field of the route. 1007 + To constrain the distribution scope of this route the route MUST 1008 carry the NO_ADVERTISE BGP community ([RFC1997]). 1010 + The ASBR constructs an IP-based Route Target extended community 1011 by placing the IP address carried in the next hop of the received 1012 Inter-AS VPLS A-D route in the Global Administrator field of the 1013 community, with the Local Administrator field of this community 1014 set to 0, and sets the Extended Communities attribute of the leaf 1015 A-D route to that community. Note that this Route Target is the 1016 same as the ASBR Import RT of the EBGP neighbor from which the 1017 ASBR received the inter-AS VPLS A-D route. 1019 10.2.2.3. Leaf A-D Route received via EBGP 1021 When an ASBR receives via EBGP a leaf A-D route, the ASBR accepts the 1022 route only if (a) at least one of the Route Targets carried in the 1023 message matches one of the import Route Targets configured on the 1024 ASBR, and (b) the ASBR determines that the received route is the best 1025 route to the destination carried in the NLRI of the route. 1027 If the ASBR accepts the leaf A-D route, the ASBR looks for an 1028 existing A-D route whose BGP-VPLS A-D NLRI has the same value as the 1029 field of the leaf A-D route just accepted. If such an A-D 1030 route is found, then the MPLS label carried in the PMSI Tunnel 1031 attribute of the leaf A-D route is used to stitch a one hop ASBR-ASBR 1032 LSP to the tail of the intra-AS tunnel segment associated with the 1033 found auto- discovery route. 1035 10.2.2.4. Inter-AS A-D Route received via IBGP 1037 In the context of this section we use the term "PE/ASBR router" to 1038 denote either a PE or an ASBR router. 1040 Note that a given inter-AS A-D route is advertised within a given AS 1041 by only one ASBR as described above. 1043 When a PE/ASBR router receives from one of its IBGP neighbors a BGP 1044 Update message that carries an inter-AS A-D route, if (a) at least 1045 one of the Route Targets carried in the message matches one of the 1046 import Route Targets configured on the PE/ASBR, and (b) the PE/ASBR 1047 determines that the received route is the best route to the 1048 destination carried in the NLRI of the route, the PE/ASBR performs 1049 the following operations. The best route determination is based as 1050 described in [RFC4761] and clarified in [MULTI-HOMING]. 1052 If the router is an ASBR then the ASBR propagates the route to its 1053 EBGP neighbors. When propagating the route to the EBGP neighbors the 1054 ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a 1055 routable IP address of the ASBR. 1057 If the received inter-AS A-D route carries the PMSI Tunnel attribute 1058 with the Tunnel Type set to LDP P2MP LSP, the PE/ASBR SHOULD join the 1059 P-Multicast tree whose identity is carried in the PMSI Tunnel 1060 attribute. 1062 If the received inter-AS A-D route carries the PMSI Tunnel attribute 1063 with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR 1064 that originated the route MUST establish an RSVP-TE P2MP LSP with the 1065 local PE/ASBR as a leaf. This LSP MAY have been established before 1066 the local PE/ASBR receives the route, or MAY be established after the 1067 local PE receives the route. 1069 If the received inter-AS A-D route carries the PMSI Tunnel attribute 1070 with the Tunnel Type set to LDP P2MP LSP, or RSVP-TE P2MP LSP, but 1071 the attribute does not carry a label, then the P-Multicast tree, as 1072 identified by the PMSI Tunnel attribute, is an intra-AS LSP segment 1073 that is part of the inter-AS Tunnel for the advertised 1074 by the inter-AS A-D route and rooted at the PE that originated the A- 1075 D route. If the PMSI Tunnel attribute carries a (upstream-assigned) 1076 label, then a combination of this tree and the label identifies the 1077 intra-AS segment. If the receiving router is an ASBR, this intra-AS 1078 segment may further be stitched to ASBR-ASBR inter-AS segment of the 1079 inter-AS tunnel. If the PE/ASBR has local receivers in the VPLS, 1080 packets received over the intra-AS segment must be forwarded to the 1081 local receivers using the local VSI. 1083 10.3. Option (c): Non-Segmented Tunnels 1085 In this model, there is a multi-hop EBGP peering between the PEs (or 1086 a Route Reflector) in one AS and the PEs (or Route Reflector) in 1087 another AS. The PEs exchange BGP-VPLS NLRI or BGP-VPLS A-D NLRI, 1088 along with PMSI Tunnel attribute, as in the intra-AS case described 1089 in section 8. An implementation MUST support this model. 1091 The PEs in different ASes use a non-segmented inter-AS P2MP tunnel 1092 for VPLS multicast. A non-segmented inter-AS tunnel is a single 1093 tunnel which spans AS boundaries. The tunnel technology cannot change 1094 from one point in the tunnel to the next, so all ASes through which 1095 the tunnel passes must support that technology. In essence, AS 1096 boundaries are of no significance to a non-segmented inter-AS P2MP 1097 tunnel. 1099 This model requires no VPLS A-D routes in the control plane or VPLS 1100 MAC address learning in the data plane on the ASBRs. The ASBRs only 1101 need to participate in the non-segmented P2MP tunnel setup in the 1102 control plane, and do MPLS label forwarding in the data plane. 1104 The setup of non-segmented inter-AS P2MP tunnels MAY require the P- 1105 routers in one AS to have IP reachability to the loopback addresses 1106 of the PE routers in another AS, depending on the tunneling 1107 technology chosen. If this is the case, reachability to the loopback 1108 addresses of PE routers in one AS MUST be present in the IGP in 1109 another AS. 1111 The data forwarding in this model is the same as in the intra-AS case 1112 described in section 8. 1114 11. Optimizing Multicast Distribution via Selective Trees 1116 Whenever a particular multicast stream is being sent on an Inclusive 1117 P-Multicast tree, it is likely that the data of that stream is being 1118 sent to PEs that do not require it as the sites connected to these 1119 PEs may have no receivers for the stream. If a particular stream has 1120 a significant amount of traffic, it may be beneficial to move it to a 1121 Selective P-Multicast tree which has at its leaves only those PEs, 1122 connected to sites that have receivers for the multicast stream (or 1123 at least includes fewer PEs that are attached to sites with no 1124 receivers compared to an Inclusive tree). 1126 A PE connected to the multicast source of a particular multicast 1127 stream may be performing explicit tracking - i.e., it may know the 1128 PEs that have receivers in the multicast stream. Section 11.3 1129 describes procedures that enable explicit tracking. If this is the 1130 case Selective P-Multicast trees can also be triggered on other 1131 criteria. For instance there could be a "pseudo wasted bandwidth" 1132 criteria: switching to a Selective tree would be done if the 1133 bandwidth multiplied by the number of "uninterested" PEs (PEs that 1134 are receiving the stream but have no receivers) is above a specified 1135 threshold. The motivation is that (a) the total bandwidth wasted by 1136 many sparsely subscribed low-bandwidth groups may be large, and (b) 1137 there's no point to moving a high-bandwidth group to a Selective tree 1138 if all the PEs have receivers for it. 1140 Switching a (C-S, C-G) stream to a Selective P-Multicast tree may 1141 require the root of the tree to determine the egress PEs that need to 1142 receive the (C-S, C-G) traffic. This is true in the following cases: 1144 + If the tunnel is a P2MP tree, such as a RSVP-TE P2MP Tunnel, the 1145 PE needs to know the leaves of the tree before it can instantiate 1146 the Selective tree. 1148 + If a PE decides to send traffic for multicast streams, belonging 1149 to different VPLSes, using one P-Multicast Selective tree, such a 1150 tree is termed an Aggregate tree with a selective mapping. The 1151 setting up of such an Aggregate tree requires the ingress PE to 1152 know all the other PEs that have receivers for multicast groups 1153 that are mapped onto the tree. 1155 + If ingress replication is used and the ingress PE wants to send 1156 traffic for (C-S, C-G)s to only those PEs that are on the path to 1157 receivers to the (C-S,C-G)s. 1159 For discovering the IP multicast group membership, for the above 1160 cases, this document describes procedures that allow an ingress PE to 1161 enable explicit tracking. Thus an ingress PE can request the IP 1162 multicast membership from egress PEs for one or more C-multicast 1163 streams. These procedures are described in section 11.3. 1165 The root of the Selective P-Multicast tree MAY decide to do explicit 1166 tracking of the IP multicast stream only after it has determined to 1167 move the stream to a Selective tree, or it MAY have been doing 1168 explicit tracking all along. This document also describes explicit 1169 tracking for a wildcard source and/or group in section 11.3, which 1170 facilitates a Selective P-Multicast tree only mode in which IP 1171 multicast streams are always carried on a Selective P-Multicast tree. 1172 In the description on Selective P-Multicast trees the notation C-S, 1173 is intended to represent either a specific source address or a 1174 wildcard. Similarly C-G is intended to represent either a specific 1175 group address or a wildcard. 1177 The PE at the root of the tree MUST signal the leaves of the tree 1178 that the (C-S, C-G) stream is now bound to the Selective Tree. Note 1179 that the PE could create the identity of the P-Multicast tree prior 1180 to the actual instantiation of the tunnel. 1182 If the Selective tree is instantiated by a RSVP-TE P2MP LSP the PE at 1183 the root of the tree MUST establish the P2MP RSVP-TE LSP to the 1184 leaves. This LSP MAY have been established before the leaves receive 1185 the Selective tree binding, or MAY be established after the leaves 1186 receive the binding. A leaf MUST NOT switch to the Selective tree 1187 until it receives the binding and the RSVP-TE P2MP LSP is setup to 1188 the leaf. 1190 11.1. Protocol for Switching to Selective Trees 1192 Selective trees provide a PE the ability to create separate P- 1193 Multicast trees for certain streams. The source PE, that 1194 originates the Selective tree, and the egress PEs, MUST use the 1195 Selective tree for the streams that are mapped to it. This 1196 may require the source and egress PEs to switch to the Selective tree 1197 from an Inclusive tree if they were already using an Inclusive tree 1198 for the streams mapped to the Selective tree. 1200 Once a source PE decides to setup a Selective tree, it MUST announce 1201 the mapping of the streams (which may be in different 1202 VPLSes) that are mapped to the tree to the other PEs using BGP. After 1203 the egress PEs receive the announcement they setup their forwarding 1204 path to receive traffic on the Selective tree if they have one or 1205 more receivers interested in the streams mapped to the 1206 tree. Setting up the forwarding path requires setting up the 1207 demultiplexing forwarding entries based on the top MPLS label (if 1208 there is no inner label) or the inner label (if present) as described 1209 in section 9. The egress PEs MAY perform this switch to the Selective 1210 tree once the advertisement from the ingress PE is received or wait 1211 for a preconfigured timer to do so, after receiving the 1212 advertisement, when the P2MP LSP protocol is mLDP. When the P2MP LSP 1213 protocol is P2MP RSVP-TE an egress PE MUST perform this switch to the 1214 Selective tree only after the advertisement from the ingress PE is 1215 received and the RSVP-TE P2MP LSP has been setup to the egress PE. 1216 This switch MAY be done after waiting for a preconfigured timer after 1217 these two steps have been accomplished. 1219 A source PE MUST use the following approach to decide when to start 1220 transmitting data on the Selective tree, if it was already using an 1221 Inclusive tree. A certain pre-configured delay after advertising the 1222 streams mapped to an Selective tree, the source PE begins 1223 to send traffic on the Selective tree. At this point it stops to send 1224 traffic for the streams, that are mapped on the Selective 1225 tree, on the Inclusive tree. This traffic is instead transmitted on 1226 the Selective tree. 1228 11.2. Advertising (C-S, C-G) Binding to a Selective Tree 1230 The ingress PE informs all the PEs that are on the path to receivers 1231 of the (C-S, C-G) of the binding of the Selective tree to the (C-S, 1232 C-G), using BGP. The BGP announcement is done by sending update for 1233 the MCAST-VPLS address family using what is referred to as the S-PMSI 1234 A-D route. The format of the NLRI is described in section 12.1. The 1235 NLRI MUST be constructed as follows: 1237 + The RD MUST be set to the RD configured locally for the VPLS. 1238 This is required to uniquely identify the as the 1239 addresses could overlap between different VPLSes. This MUST be 1240 the same RD value used in the VPLS auto-discovery process. 1242 + The Multicast Source field MUST contain the source address 1243 associated with the C-multicast stream, and the Multicast Source 1244 Length field is set appropriately to reflect this. If the source 1245 address is a wildcard the source address is set to 0. 1247 + The Multicast Group field MUST contain the group address 1248 associated with the C-multicast stream, and the Multicast Group 1249 Length field is set appropriately to reflect this. If the group 1250 address is a wildcard the group address is set to 0. 1252 + The Originating Router's IP Address field MUST be set to the IP 1253 address that the (local) PE places in the BGP next-hop of the 1254 BGP-VPLS A-D routes. Note that the tuple uniquely identifies a given VPLS instance on a PE. 1257 The PE constructs the rest of the Selective A-D route as follows. 1259 Depending on the type of a P-Multicast tree used for the P-tunnel, 1260 the PMSI tunnel attribute of the S-PMSI A-D route is constructed as 1261 follows: 1263 + The PMSI tunnel attribute MUST contain the identity of the P- 1264 Multicast tree (note that the PE could create the identity of the 1265 tree prior to the actual instantiation of the tree). 1267 + If in order to establish the P-Multicast tree the PE needs to 1268 know the leaves of the tree within its own AS, then the PE 1269 obtains this information from the leaf A-D routes received from 1270 other PEs/ASBRs within its own AS (as other PEs/ASBRs originate 1271 leaf A-D routes in response to receiving the S-PMSI A-D route) by 1272 setting the Leaf Information Required flag in the PMSI Tunnel 1273 attribute to 1. This enables explicit tracking for the multicast 1274 stream(s) advertised by the S-PMSI A-D route. 1276 + If a PE originates S-PMSI A-D routes with the Leaf Information 1277 Required flag in the PMSI Tunnel attribute set to 1, then the PE 1278 MUST be (auto)configured with an import Route Target, which 1279 controls acceptance of leaf A-D routes by the PE. (Procedures for 1280 originating leaf A-D routes by the PEs that receive the S-PMSI A- 1281 D route are described in section "Receiving S-PMSI A-D routes by 1282 PEs.") 1284 This Route Target is IP address specific. The Global 1285 Administrator field of this Route Target MUST be set to the IP 1286 address carried in the Next Hop of all the S-PMSI A-D routes 1287 advertised by this PE (if the PE uses different Next Hops, then 1288 the PE MUST be (auto)configured with multiple import RTs, one per 1289 each such Next Hop). The Local Administrator field of this Route 1290 Target MUST be set to 0. 1292 If the PE supports Route Target Constrain [RFC4684], the PE 1293 SHOULD advertise this import Route Target within its own AS using 1294 Route Target Constrains. To constrain distribution of the Route 1295 Target Constrain routes to the AS of the advertising PE these 1296 routes SHOULD carry the NO_EXPORT Community ([RFC1997]). 1298 + A PE MAY aggregate two or more S-PMSIs originated by the PE onto 1299 the same P-Multicast tree. If the PE already advertises S-PMSI A- 1300 D routes for these S-PMSIs, then aggregation requires the PE to 1301 re-advertise these routes. The re-advertised routes MUST be the 1302 same as the original ones, except for the PMSI tunnel attribute. 1303 If the PE has not previously advertised S-PMSI A-D routes for 1304 these S-PMSIs, then the aggregation requires the PE to advertise 1305 (new) S-PMSI A-D routes for these S-PMSIs. The PMSI Tunnel 1306 attribute in the newly advertised/re-advertised routes MUST carry 1307 the identity of the P-Multicast tree that aggregates the S-PMSIs. 1308 If at least some of the S-PMSIs aggregated onto the same P- 1309 Multicast tree belong to different VPLSes, then all these routes 1310 MUST carry an MPLS upstream assigned label [RFC5331]. If all 1311 these aggregated S-PMSIs belong to the same VPLS, then the routes 1312 MAY carry an MPLS upstream assigned label [RFC5331]. The labels 1313 MUST be distinct on a per VPLS basis, and MAY be distinct on a 1314 per route basis. 1316 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 1317 be set to the same IP address as the one carried in the Originating 1318 Router's IP Address field. 1320 By default the set of Route Targets carried by the route MUST be the 1321 same as the Route Targets carried in the BGP-VPLS A-D route 1322 originated from the VSI. The default could be modified via 1323 configuration. 1325 11.3. Receiving S-PMSI A-D routes by PEs 1327 Consider a PE that receives an S-PMSI A-D route. If one or more of 1328 the VSIs on the PE have their import Route Targets that contain one 1329 or more of the Route Targets carried by the received S-PMSI A-D 1330 route, then for each such VSI the PE performs the following. 1332 Procedures for receiving an S-PMSI A-D route by a PE (both within and 1333 outside of the AS of the PE that originates the route) are the same 1334 as specified in Section "Inter-AS A-D route received via IBGP" except 1335 that (a) instead of Inter-AS A-D routes the procedures apply to S- 1336 PMSI A-D routes, and (b) the rules for determining whether the 1337 received S-PMSI A-D route is the best route to the destination 1338 carried in the NLRI of the route, are the same as BGP path selection 1339 rules and may be modified by policy, and (c) a PE performs procedures 1340 specified in that section only if in addition to the criteria 1341 specified in that section the following is true: 1343 + If as a result of multicast state snooping on the PE-CE 1344 interfaces, the PE has snooped state for at least one multicast 1345 join that matches the multicast source and group advertised in 1346 the S-PMSI A-D route. Further if the oifs (outgoing interfaces) 1347 for this state contains one or more interfaces to the locally 1348 attached CEs. When the multicast signaling protocol among the CEs 1349 is IGMP, then snooping and associated procedures are defined in 1350 [RFC4541]. The snooped state is determined using these 1351 procedures. When the multicast signaling protocol among the CEs 1352 is PIM, the procedures in [RFC4541] are not sufficient to 1353 determine the snooped state. The additional details required to 1354 determine the snooped state when CE-CE protocol is PIM are for 1355 further study. When such procedures are defined it is expected 1356 that the procedures in this section will apply to the snooped 1357 state created as a result of PIM as PE-CE protocol. 1359 The snooped state is said to "match" the S-PMSI A-D route if any of 1360 the following is true: 1362 + The S-PMSI A-D route carries (C-S, C-G) and the snooped state is 1363 for (C-S, C-G) or for (C-*, C-G), OR 1365 + The S-PMSI A-D route carries (C-*, C-G) and (a) the snooped 1366 state is for (C-*, C-G) OR (b) the snooped state is for at least 1367 one multicast join with the multicast group address equal to C-G 1368 and there doesn't exist another S-PMSI A-D route that carries (C- 1369 S, C-G) where C-S is the source address of the snooped state. 1371 + The S-PMSI A-D route carries (C-S, C-*) and (a) the snooped 1372 state is for at least one multicast join with the multicast 1373 source address equal to C-S, and (b) there doesn't exist another 1374 S-PMSI A-D route that carries (C-S, C-G) where C-G is the group 1375 address of the snooped state. 1377 + The S-PMSI A-D route carries (C-*, C-*) and there is no other S- 1378 PMSI A-D route that matches the snooped state as per the above 1379 conditions. 1381 Note if the above conditions are true, and if the received S-PMSI A-D 1382 route has a PMSI Tunnel attribute with the Leaf Information Required 1383 flag set to 1, then the PE originates a leaf A-D route, constructed 1384 as follows: 1386 + The route carries a single MCAST-VPN NLRI with the Route Key 1387 field set to the MCAST-VPN NLRI of the received S-PMSI A-D route. 1389 + The Originating Router's IP address set to the IP address of the 1390 PE (this MUST be a routable IP address). 1392 + The PE constructs an IP-based Route Target Extended Community by 1393 placing the IP address carried in the Next Hop of the received S- 1394 PMSI A-D route in the Global Administrator field of the 1395 Community, with the Local Administrator field of this Community 1396 set to 0 and setting the Extended Communities attribute of the 1397 leaf A-D route to that Community. 1399 + The Next Hop field of the MP_REACH_NLRI attribute of the route 1400 MUST be set to the same IP address as the one carried in the 1401 Originating Router's IP Address field of the route. 1403 + To constrain the distribution scope of this route, the route 1404 MUST carry the NO_EXPORT Community [RFC1997], except for the 1405 inter-AS scenario with option (c). 1407 Once the leaf A-D route is constructed, the PE advertises this route 1408 into IBGP. 1410 In addition to the procedures specified in Section "Inter-AS A-D 1411 route received via IBGP" the PE MUST set up its forwarding path to 1412 receive traffic, for each multicast stream in the matching snooped 1413 state, from the tunnel advertised by the S-PMSI A-D route (the PE 1414 MUST switch to the Selective tree). 1416 When a new snooped state is created by a PE then the PE MUST first 1417 determine if there is a S-PMSI route that matches the snooped state 1418 as per the conditions described above. If such a S-PMSI route is 1419 found then the PE MUST follow the procedures described in this 1420 section, for that particular S-PMSI route. 1422 11.4. Inter-AS Selective Tree 1424 Inter-AS Selective trees support all three options of inter-AS VPLS 1425 service, option (a), (b) and (c), that are supported by Inter-AS 1426 Inclusive trees. They are constructed in a manner that is very 1427 similar to Inter-AS Inclusive trees. 1429 For option (a) and option (b) support inter-AS Selective trees are 1430 constructed without requiring a single P-Multicast tree to span 1431 multiple ASes. This allows individual ASes to potentially use 1432 different P-tunneling technologies. There are two variants of this. 1434 One that requires MAC and IP multicast lookup on the ASBRs and 1435 another that does not require MAC/IP multicast lookup on the ASBRs 1436 and instead builds segmented inter-AS Selective trees. 1438 Segmented Inter-AS Selective trees can also be used with option (c), 1439 unlike Segmented Inter-AS Inclusive trees. This is because the S-PMSI 1440 A-D routes can be exchanged via ASBRs (even though BGP VPLS A-D 1441 routes are not exchanged via ASBRs). 1443 In the case of Option (c) an Inter-AS Selective tree may also be a 1444 non-segmented P-Multicast tree that spans multiple ASes. 1446 11.4.1. VSIs on the ASBRs 1448 The requirements on ASBRs, when VSIs are present on the ABSRs, 1449 include the requirements presented in section 10. The source ASBR 1450 (that receives traffic from another AS) may independently decide 1451 whether it wishes to use Selective trees or not. If it uses Selective 1452 trees the source ASBR MUST perform a MAC lookup to determine the 1453 Selective tree to forward the VPLS packet on. 1455 11.4.1.1. VPLS Inter-AS Selective Tree A-D Binding 1457 The mechanisms for propagating S-PMSI A-D routes are the same as the 1458 intra-AS case described in section 12.2. The BGP Selective tree A-D 1459 routes generated by PEs in an AS MUST NOT be propagated outside the 1460 AS. 1462 11.4.2. Inter-AS Segmented Selective Trees 1464 Inter-AS Segmented Selective trees MUST be used when option (b) is 1465 used to provide the inter-AS VPLS service. They MAY be used when 1466 option (c) is used to provide the inter-AS VPLS service. 1468 A Segmented inter-AS Selective Tunnel is constructed similar to an 1469 inter-AS Segmented Inclusive Tunnel. Namely, such a tunnel is 1470 constructed as a concatenation of tunnel segments. There are two 1471 types of tunnel segments: an intra-AS tunnel segment (a segment that 1472 spans ASBRs within the same AS), and inter-AS tunnel segment (a 1473 segment that spans adjacent ASBRs in adjacent ASes). ASes that are 1474 spanned by a tunnel are not required to use the same tunneling 1475 mechanism to construct the tunnel - each AS may pick up a tunneling 1476 mechanism to construct the intra-AS tunnel segment of the tunnel, in 1477 its AS. 1479 The PE that decides to set up a Selective tree, advertises the 1480 Selective tree to multicast stream binding using an S-PMSI A-D route 1481 as per procedures in section 11.2, to the routers in its own AS. 1483 An S-PMSI A-D route advertised outside the AS, to which the 1484 originating PE belongs, will be referred to as an inter-AS Selective 1485 Tree A-D route (although this route is originated by a PE as an 1486 intra-AS route it is referred to as an inter-AS route outside the 1487 AS). 1489 11.4.2.1. Handling S-PMSI A-D routes by ASBRs 1491 Procedures for handling an S-PMSI A-D route by ASBRs (both within and 1492 outside of the AS of the PE that originates the route) are the same 1493 as specified in Section "Propagating VPLS BGP A-D routes to other 1494 ASes", except that instead of Inter-AS BGP-VPLS A-D routes and the 1495 BGP-VPLS A-D NLRI these procedures apply to S-PMSI A-D routes and the 1496 S-PMSI A-D NLRI. 1498 In addition to these procedures an ASBR advertises a leaf A-D route 1499 in response to an S-PMSI A-D route only if: 1501 + The S-PMSI A-D route was received via EBGP from another ASBR and 1502 the ASBR merges the S-PMSI A-D route into an Inter-AS BGP VPLS A- 1503 D route as described in the next section. OR 1505 + The ASBR receives a leaf A-D route from a downstream PE or ASBR 1506 in response to the S-PMSI A-D route, received from an upstream PE 1507 or ASBR, that the ASBR propagated inter-AS to downstream ASBRs 1508 and PEs. 1510 + The ASBR has snooped state from local CEs that matches the NLRI 1511 carried in the S-PMSI A-D route as per the following rules: 1513 i) The NLRI encodes (C-S, C-G) which is the same as the snooped 1514 (C-S, C-G) 1516 ii) The NLRI encodes (*, C-G) and there is snooped state for at 1517 least one (C-S, C-G) and there is no other matching S-PMSI A-D 1518 route for (C-S, C-G) OR there is snooped state for (*, C-G) 1520 iii) The NLRI encodes (*, *) and there is snooped state for at 1521 least one (C-S, C-G) or (*, C-G) and there is no other matching 1522 S-PMSI A-D route for that (C-S, C-G) or (*, C-G) respecively. 1524 The C-multicast data traffic is sent on the Selective tree by the 1525 originating PE. When it reaches an ASBR that is on the Inter-AS 1526 segmented tree, it is delivered to local receivers, if any. It is 1527 then forwarded on any inter-AS or intra-AS segments that exist on the 1528 Inter-AS Selective Segmented tree. If the Inter-AS Segmented 1529 Selective Tree is merged onto an Inclusive tree, as described in the 1530 next section, the data traffic is forwarded onto the Inclusive tree. 1532 11.4.2.1.1. Merging Selective Tree into an Inclusive Tree 1534 Consider the situation where: 1536 + An ASBR is receiving (or expecting to receive) inter-AS (C-S, C- 1537 G) data from upstream via a Selective tree. 1539 + The ASBR is sending (or expecting to send) the inter-AS (C-S, C- 1540 G) data downstream via an Inclusive tree. 1542 This situation may arise if the upstream providers have a policy of 1543 using Selective trees but the downstream providers have a policy of 1544 using Inclusive trees. To support this situation, an ASBR MAY, under 1545 certain conditions, merge one or more upstream Selective trees into a 1546 downstream Inclusive tree. Note that this can be the case only for 1547 option (b) and not for option (c) as for option (c) the ASBRs do not 1548 have Inclusive tree state. 1550 A Selective tree (corresponding to a particular S-PMSI A-D route) MAY 1551 be merged by a particular ASBR into an Inclusive tree (corresponding 1552 to a particular Inter-AS BGP VPLS A-D route) if and only if the 1553 following conditions all hold: 1555 + The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route 1556 originate in the same AS. The Inter-AS BGP VPLS A-D route carries 1557 the originating AS in the AS_PATH attribute of the route. The S- 1558 PMSI A-D route carries the originating AS in the AS_PATH 1559 attribute of the route. 1561 + The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route have 1562 exactly the same set of RTs. 1564 An ASBR performs merging by stitching the tail end of the P-tunnel, 1565 as specified in the PMSI Tunnel attribute of the S-PMSI A-D route 1566 received by the ASBR, to the head of the P-tunnel, as specified in 1567 the PMSI Tunnel attribute of the Inter-AS BGP VPLS A-D route re- 1568 advertised by the ASBR. 1570 An ASBR that merges an S-PMSI A-D route into an Inter-AS BGP VPLS A-D 1571 route MUST NOT re-advertise the S-PMSI A-D route. 1573 11.4.3. Inter-AS Non-Segmented Selective trees 1575 Inter-AS Non-segmented Selective trees MAY be used in the case of 1576 option (c). 1578 In this method, there is a multi-hop EBGP peering between the PEs (or 1579 a Route Reflector) in one AS and the PEs (or Route Reflector) in 1580 another AS. The PEs exchange BGP Selective tree A-D routes, along 1581 with PMSI Tunnel attribute, as in the intra-AS case described in 1582 section 10.3. 1584 The PEs in different ASes use a non-segmented Selective inter-AS P2MP 1585 tunnel for VPLS multicast. 1587 This method requires no VPLS information (in either the control or 1588 the data plane) on the ASBRs. The ASBRs only need to participate in 1589 the non-segmented P2MP tunnel setup in the control plane, and do MPLS 1590 label forwarding in the data plane. 1592 The data forwarding in this model is the same as in the intra-AS case 1593 described in section 9. 1595 12. BGP Extensions 1597 This section describes the encoding of the BGP extensions required by 1598 this document. 1600 12.1. Inclusive Tree/Selective Tree Identifier 1602 Inclusive P-Multicast tree and Selective P-Multicast tree 1603 advertisements carry the P-Multicast tree identifier. 1605 This document reuses the BGP attribute, called PMSI Tunnel attribute 1606 that is defined in [RFC6514]. 1608 This document supports only the following Tunnel Types when PMSI 1609 Tunnel attribute is carried in VPLS A-D or VPLS S-PMSI A-D routes: 1611 + 0 - No tunnel information present 1612 + 1 - RSVP-TE P2MP LSP 1613 + 2 - LDP P2MP LSP 1614 + 6 - Ingress Replication 1616 12.2. MCAST-VPLS NLRI 1618 This document defines a new BGP NLRI, called the MCAST-VPLS NLRI. 1620 Following is the format of the MCAST-VPLS NLRI: 1622 +-----------------------------------+ 1623 | Route Type (1 octet) | 1624 +-----------------------------------+ 1625 | Length (1 octet) | 1626 +-----------------------------------+ 1627 | Route Type specific (variable) | 1628 +-----------------------------------+ 1630 The Route Type field defines encoding of the rest of MCAST-VPLS NLRI 1631 (Route Type specific MCAST-VPLS NLRI). 1633 The Length field indicates the length in octets of the Route Type 1634 specific field of MCAST-VPLS NLRI. 1636 This document defines the following Route Types for A-D routes: 1637 + 3 - Selective Tree A-D route; 1638 + 4 - Leaf A-D route. 1640 The MCAST-VPLS NLRI is carried in BGP using BGP Multiprotocol 1641 Extensions [RFC4760] with an AFI of 25 (L2VPN AFI), and an SAFI of 1642 MCAST-VPLS [To be assigned by IANA]. The NLRI field in the 1643 MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the MCAST-VPLS NLRI 1644 (encoded as specified above). 1646 In order for two BGP speakers to exchange labeled MCAST-VPLS NLRI, 1647 they must use BGP Capabilities Advertisement to ensure that they both 1648 are capable of properly processing such NLRI. This is done as 1649 specified in [RFC4760], by using capability code 1 (multiprotocol 1650 BGP) with an AFI of 25 and an SAFI of MCAST-VPLS. 1652 The following describes the format of the Route Type specific MCAST- 1653 VPLS NLRI for various Route Types defined in this document. 1655 12.2.1. S-PMSI A-D route 1657 An S-PMSI A-D route type specific MCAST-VPLS NLRI consists of the 1658 following: 1660 +-----------------------------------+ 1661 | RD (8 octets) | 1662 +-----------------------------------+ 1663 | Multicast Source Length (1 octet) | 1664 +-----------------------------------+ 1665 | Multicast Source (Variable) | 1666 +-----------------------------------+ 1667 | Multicast Group Length (1 octet) | 1668 +-----------------------------------+ 1669 | Multicast Group (Variable) | 1670 +-----------------------------------+ 1671 | Originating Router's IP Addr | 1672 +-----------------------------------+ 1674 The RD is encoded as described in [RFC4364]. 1676 The Multicast Source field contains the C-S address i.e the address 1677 of the multicast source. If the Multicast Source field contains an 1678 IPv4 address, then the value of the Multicast Source Length field is 1679 32. If the Multicast Source field contains an IPv6 address, then the 1680 value of the Multicast Source Length field is 128. The value of the 1681 Multicast Source Length field may be set to 0 to indicate a wildcard. 1683 The Multicast Group field contains the C-G address i.e. the address 1684 of the multicast group. If the Multicast Group field contains an IPv4 1685 address, then the value of the Multicast Group Length field is 32. 1686 If the Multicast Group field contains an IPv6 address, then the value 1687 of the Multicast Group Length field is 128. The Multicast Group 1688 Length field may be set to 0 to indicate a wildcard. 1690 Whether the Originating Router's IP Address field carries an IPv4 or 1691 IPv6 address is determined from the value of the Length field of the 1692 MCAST-VPLS NLRI. If the Multicast Source field contains an IPv4 1693 address and the Multicast Group field contains an IPv4 address, then 1694 the value of the Length field is 22 bytes if the Originating Router's 1695 IP address carries an IPv4 address and 34 bytes if it is an IPv6 1696 address. If the Multicast Source and Multicast Group fields contain 1697 IPv6 addresses, then the value of the Length field is 46 bytes if the 1698 Originating Router's IP address carries an IPv4 address and 58 bytes 1699 if it is an IPv6 address. The following table summarizes the above. 1701 Multicast Multicast Originating Router's Length 1702 Source Group IP Address 1704 IPv4 IPv4 IPv4 22 1705 IPv4 IPv4 IPv6 34 1706 IPv6 IPv6 IPv4 46 1707 IPv6 IPv6 IPv6 58 1709 Usage of Selective Tree A-D routes is described in Section 1710 11. 1712 12.2.2. Leaf A-D route 1714 A leaf A-D route type specific MCAST-VPLS NLRI consists of the 1715 following: 1717 +-----------------------------------+ 1718 | Route Key (variable) | 1719 +-----------------------------------+ 1720 | Originating Router's IP Addr | 1721 +-----------------------------------+ 1723 Whether the Originating Router's IP Address field carries an IPv4 or 1724 IPv6 address is determined from the Length field of the MCAST-VPLS 1725 NLRI and the length of the Route Key field. From these two length 1726 fields one can compute the length of the Originating Router's IP 1727 Address. If this computed length is 4 then the address is an IPv4 1728 address and if its 16 then the address is an IPv6 address. 1730 Usage of leaf A-D routes is described in sections "Inter-AS Inclusive 1731 P-Multicast tree A-D/Binding" and "Optimizing Multicast Distribution 1732 via Selective trees". 1734 13. Aggregation Considerations 1736 In general the heuristic used to decide which VPLS instances or (C-S, 1737 C-G) entries to aggregate is implementation dependent. It is also 1738 conceivable that offline tools can be used for this purpose. This 1739 section discusses some tradeoffs with respect to aggregation. 1741 The "congruency" of aggregation is defined by the amount of overlap 1742 in the leaves of the client trees that are aggregated on an SP tree. 1743 For Aggregate Inclusive trees the congruency depends on the overlap 1744 in the membership of the VPLSes that are aggregated on the Aggregate 1745 Inclusive tree. If there is complete overlap aggregation is perfectly 1746 congruent. As the overlap between the VPLSes that are aggregated 1747 reduces, the congruency reduces. 1749 If aggregation is done such that it is not perfectly congruent a PE 1750 may receive traffic for VPLSes to which it doesn't belong. As the 1751 amount of multicast traffic in these unwanted VPLSes increases 1752 aggregation becomes less optimal with respect to delivered traffic. 1753 Hence there is a tradeoff between reducing multicast state in the 1754 core and delivering unwanted traffic. 1756 An implementation should provide knobs to control the congruency of 1757 aggregation. This will allow an SP to deploy aggregation depending on 1758 the VPLS membership and traffic profiles in its network. If 1759 different PEs or shared roots are setting up Aggregate Inclusive 1760 trees this will also allow an SP to engineer the maximum amount of 1761 unwanted VPLSes that a particular PE may receive traffic for. 1763 The state/bandwidth optimality trade-off can be further improved by 1764 having a versatile many-to-many association between client trees and 1765 provider trees. Thus a VPLS can be mapped to multiple Aggregate 1766 trees. The mechanisms for achieving this are for further study. Also 1767 it may be possible to use both ingress replication and an Aggregate 1768 tree for a particular VPLS. Mechanisms for achieving this are also 1769 for further study. 1771 14. Data Forwarding 1773 14.1. MPLS Tree Encapsulation 1775 14.1.1. Mapping multiple VPLS instances to a P2MP LSP 1777 The following diagram shows the progression of the VPLS multicast 1778 packet as it enters and leaves the SP network when MPLS trees are 1779 being used for multiple VPLS instances. RSVP-TE P2MP LSPs are 1780 examples of such trees. 1782 Packets received Packets in transit Packets forwarded 1783 at ingress PE in the service by egress PEs 1784 provider network 1786 +---------------+ 1787 |MPLS Tree Label| 1788 +---------------+ 1789 | VPLS Label | 1790 ++=============++ ++=============++ ++=============++ 1791 ||C-Ether Hdr || || C-Ether Hdr || || C-Ether Hdr || 1792 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1793 || C-IP Header || || C-IP Header || || C-IP Header || 1794 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1795 || C-Payload || || C-Payload || || C-Payload || 1796 ++=============++ ++=============++ ++=============++ 1798 The receiver PE does a lookup on the outer MPLS tree label and 1799 determines the MPLS forwarding table in which to lookup the inner 1800 MPLS label. This table is specific to the tree label space. The inner 1801 label is unique within the context of the root of the tree (as it is 1802 assigned by the root of the tree, without any coordination with any 1803 other nodes). Thus it is not unique across multiple roots. So, to 1804 unambiguously identify a particular VPLS one has to know the label, 1805 and the context within which that label is unique. The context is 1806 provided by the outer MPLS label [RFC5331]. 1808 The outer MPLS label is stripped. The lookup of the resulting MPLS 1809 label determines the VSI in which the receiver PE needs to do the C- 1810 multicast data packet lookup. It then strips the inner MPLS label and 1811 sends the packet to the VSI for multicast data forwarding. 1813 14.1.2. Mapping one VPLS instance to a P2MP LSP 1815 The following diagram shows the progression of the VPLS multicast 1816 packet as it enters and leaves the SP network when a given MPLS tree 1817 is being used for a single VPLS instance. RSVP-TE P2MP LSPs are 1818 examples of such trees. 1820 Packets received Packets in transit Packets forwarded 1821 at ingress PE in the service by egress PEs 1822 provider network 1824 +---------------+ 1825 |MPLS Tree Label| 1826 ++=============++ ++=============++ ++=============++ 1827 ||C-Ether Hdr || || C-Ether Hdr || || C-Ether Hdr || 1828 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1829 || C-IP Header || || C-IP Header || || C-IP Header || 1830 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1831 || C-Payload || || C-Payload || || C-Payload || 1832 ++=============++ ++=============++ ++=============++ 1834 The receiver PE does a lookup on the outer MPLS tree label and 1835 determines the VSI in which the receiver PE needs to do the C- 1836 multicast data packet lookup. It then strips the inner MPLS label and 1837 sends the packet to the VSI for multicast data forwarding. 1839 15. VPLS Data Packet Treatment 1841 If the destination MAC address of a VPLS packet received by a PE from 1842 a VPLS site is a multicast address, a P-Multicast tree SHOULD be used 1843 to transport the packet, if possible. If the packet is an IP 1844 multicast packet and a Selective tree exists for that multicast 1845 stream, the Selective tree MUST be used. Else if a (C-*, C-*) 1846 Selective tree exists for the VPLS it SHOULD be used. Else if an 1847 Inclusive tree exists for the VPLS, it SHOULD be used. 1849 If the destination MAC address of a VPLS packet is a broadcast 1850 address, it is flooded. If a (C-*, C-*) Selective tree exists for the 1851 VPLS the PE SHOULD flood over it. Else if Inclusive tree exists for 1852 the VPLS the PE SHOULD flood over it. Else the PE MUST flood over 1853 multiple PWs, based on [RFC4761] or [RFC4762]. 1855 If the destination MAC address of a packet is a unicast address and 1856 it has not been learned, the packet MUST be sent to all PEs in the 1857 VPLS. Inclusive P-Multicast trees or a Selective P-Multicast tree 1858 bound to (C-*, C-*) SHOULD be used for sending unknown unicast MAC 1859 packets to all PEs. When this is the case the receiving PEs MUST 1860 support the ability to perform MAC address learning for packets 1861 received on a multicast tree. In order to perform such learning, the 1862 receiver PE MUST be able to determine the sender PE when a VPLS 1863 packet is received on a P-Multicast tree. This further implies that 1864 the MPLS P-Multicast tree technology MUST allow the egress PE to 1865 determine the sender PE from the received MPLS packet. 1867 When a receiver PE receives a VPLS packet with a source MAC address, 1868 that has not yet been learned, on a P-Multicast tree, the receiver PE 1869 determines the PW to the sender PE. The receiver PE then creates 1870 forwarding state in the VPLS instance with a destination MAC address 1871 being the same as the source MAC address being learned, and the PW 1872 being the PW to the sender PE. 1874 It should be noted that when a sender PE that is sending packets 1875 destined to an unknown unicast MAC address over a P-Multicast tree 1876 learns the PW to use for forwarding packets destined to this unicast 1877 MAC address, it might immediately switch to transport such packets 1878 over this particular PW. Since the packets were initially being 1879 forwarded using a P-Multicast tree, this could lead to packet 1880 reordering. This constraint should be taken into consideration if 1881 unknown unicast frames are forwarded using a P-Multicast tree, 1882 instead of multiple PWs based on [RFC4761] or [RFC4762]. 1884 An implementation MUST support the ability to transport unknown 1885 unicast traffic over Inclusive P-Multicast trees. Further an 1886 implementation MUST support the ability to perform MAC address 1887 learning for packets received on a P-Multicast tree. 1889 16. Security Considerations 1891 Security considerations discussed in [RFC4761] and [RFC4762] apply to 1892 this document. This section describes additional considerations. 1894 As mentioned in [RFC4761], there are two aspects to achieving data 1895 privacy in a VPLS: securing the control plane and protecting the 1896 forwarding path. Compromise of the control plane could result in a PE 1897 sending multicast data belonging to some VPLS to another VPLS, or 1898 black-holing VPLS multicast data, or even sending it to an 1899 eavesdropper; none of which are acceptable from a data privacy point 1900 of view. The mechanisms in this document use BGP for the control 1901 plane. Hence techniques such as in [RFC5925] help authenticate BGP 1902 messages, making it harder to spoof updates (which can be used to 1903 divert VPLS traffic to the wrong VPLS) or withdrawals (denial-of- 1904 service attacks). In the multi-AS methods (b) and (c) described in 1905 Section 11, this also means protecting the inter-AS BGP sessions, 1906 between the ASBRs, the PEs, or the Route Reflectors. 1908 Note that [RFC5925] will not help in keeping MPLS labels, associated 1909 with P2MP LSPs or the upstream MPLS labels used for aggregation, 1910 private -- knowing the labels, one can eavesdrop on VPLS traffic. 1911 However, this requires access to the data path within a Service 1912 Provider network. 1914 One of the requirements for protecting the data plane is that the 1915 MPLS labels are accepted only from valid interfaces. This applies 1916 both to MPLS labels associated with P2MP LSPs and also applies to the 1917 upstream assigned MPLS labels. For a PE, valid interfaces comprise 1918 links from P routers. For an ASBR, valid interfaces comprise links 1919 from P routers and links from other ASBRs in ASes that have instances 1920 of a given VPLS. It is especially important in the case of multi-AS 1921 VPLSes that one accept VPLS packets only from valid interfaces. 1923 17. IANA Considerations 1925 This document defines a new NLRI, called MCAST-VPLS, to be carried in 1926 BGP using multiprotocol extensions. It requires assignment of a new 1927 SAFI. This is to be assigned by IANA. 1929 This document defines a BGP optional transitive attribute, called 1930 PMSI attribute. This is the same attribute as the one defined in 1931 [RFC6514] and the code point for this attribute has already been 1932 assigned by IANA as 22 [BGP-IANA]. Hence no further action is 1933 required from IANA regarding this attribute. 1935 18. Acknowledgments 1937 Many thanks to Thomas Morin for his support of this work. We would 1938 also like to thank authors of [RFC6514] and [RFC6513] as the details 1939 of the inter-AS segmented tree procedures in this document have 1940 benefited from those in [RFC6514] and [RFC6513]. We would also like 1941 to thank Wim Henderickx for his comments. 1943 19. Normative References 1945 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1946 Requirement Levels.", RFC 2119, March 1997. 1948 [RFC4760] T. Bates, et. al., "Multiprotocol Extensions for BGP-4", 1949 RFC 4760, January 2007. 1951 [RFC4761] K. Kompella, Y. Rekther, "Virtual Private LAN Service using 1952 BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. 1954 [RFC4762] M. Lasserre, V. Kompella, "Virtual Private LAN Services 1955 over MPLS Label Distribution Protocol (LDP) Signaling", RFC 4762, 1956 January 2007. 1958 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 1959 Assignment and Context Specific Label Space", RFC 5331, August 2008. 1961 [RFC6511] Z. Ali, G. Swallow, R. Aggarwal, "Non PHP behavior and 1962 out-of-band mapping for RSVP-TE LSPs", RFC 6511, February 2012. 1964 20. Informative References 1966 [RFC6514] R. Aggarwal, E. Rosen, Y. Rekhter, T. Morin, "BGP Encodings 1967 for Multicast in MPLS/BGP IP VPNs". RFC 6514, February 2012. 1969 [RFC6513] E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 1970 6513, February 2012. 1972 [RFC6388] I. Minei et. al, "Label Distribution Protocol Extensions 1973 for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 1974 Paths", RFC 6388, November 2011. 1976 [RFC6074] E. Rosen et. al., "Provisioning, Autodiscovery, and 1977 Signaling in L2VPNs", RFC 6074, January 2011. 1979 [RFC5501] Y. kamite, et. al., "Requirements for Multicast Support in 1980 Virtual Private LAN Services", RFC 5501, January 2009. 1982 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, "MPLS 1983 Multicast Encapsulations", RFC 5332, August 2008. 1985 [RFC4875] R. Aggarwal et. al, "Extensions to RSVP-TE for Point to 1986 Multipoint TE LSPs", RFC 4857, May 2007. 1988 [RFC4684] P. Marques et. al., "Constrained Route Distribution for 1989 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 1990 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 1991 November 2006. 1993 [RFC4601] B. Fenner, et. al., "PIM-SM Protocol Specification", RFC 1994 4601, August 2006. 1996 [RFC4541] M. Christensen et. al., "Considerations for Internet Group 1997 Management Protocol (IGMP) and Multicast Listener Discovery (MLD) 1998 Snooping Switches", RFC 4541, May 2006. 2000 [RFC4447] L. Martini et. al., "Pseudowire Setup and Maintenance Using 2001 the Label Distribution Protocol (LDP)", RFC 4447, April 2006. 2003 [RFC4364] "BGP MPLS VPNs", E. Rosen, Y.Rekhter, RFC4364, February 2004 2006. 2006 [RFC5925] J. Touch, et. al., "The TCP Authentication Option", 2007 RFC5925, June 2010. 2009 [RFC1997] R. Chandra, et. al., "BGP Communities Attribute", RFC 1997, 2010 August 1996. 2012 [MULTI-HOMING] K. Kompella et. al., "Multi-homing in BGP-based 2013 Virtual Private LAN Service", draft-ietf-l2vpn-vpls-multihoming Work 2014 in Progress. 2016 [BGP-IANA] http://www.iana.org/assignments/bgp-parameters 2018 21. Author's Address 2020 Rahul Aggarwal 2022 998 Lucky Avenue 2023 Menlo Park, CA 94025 2024 USA 2025 Phone: +1-415-806-5527 2026 Email: raggarwa_1@yahoo.com 2028 Yuji Kamite 2029 NTT Communications Corporation 2030 Tokyo Opera City Tower 2031 3-20-2 Nishi Shinjuku, Shinjuku-ku, 2032 Tokyo 163-1421, 2033 Japan 2035 Email: y.kamite@ntt.com 2037 Luyuan Fang 2038 Cisco Systems 2039 111 Wood Avenue South 2040 Iselin, NJ 08830 2041 USA 2043 Email: lufang@cisco.com 2045 Yakov Rekhter 2046 Juniper Networks 2047 1194 North Mathilda Ave. 2048 Sunnyvale, CA 94089 2049 USA 2051 Email: yakov@juniper.net 2053 Chaitanya Kodeboniya 2054 Cisco Systems 2055 Email: ckodeboy@cisco.com