idnits 2.17.1 draft-ietf-l2vpn-vpls-mcast-09.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. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1389 has weird spacing: '...ertised by th...' == Line 1512 has weird spacing: '...pecting to se...' == Line 1517 has weird spacing: '...rt this situa...' == Line 1524 has weird spacing: '...rged by a par...' == Line 1525 has weird spacing: '...ponding to a ...' == (1 more instance...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the Selective tree is instantiated by a RSVP-TE P2MP LSP the PE at the root of the tree MUST establish the P2MP RSVP-TE LSP to the leaves. This LSP MAY have been established before the leaves receive the Selective tree binding, or MAY be established after the leaves receives the binding. A leaf MUST not switch to the Selective tree until it receives the binding and the RSVP-TE P2MP LSP is setup to the leaf. -- 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.) -- The document date (July 05, 2011) is 4650 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'L2VPN-SIG' is mentioned on line 298, but not defined == Missing Reference: 'RFC 4541' is mentioned on line 1345, but not defined == Unused Reference: 'IGMP-SN' is defined on line 1986, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-vpls-bgp-02 == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-03 -- No information found for draft-ietf-mpls-rsvp-te-no-php-obb-mapping - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RSVP-OBB' == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-08 == Outdated reference: A later version (-08) exists of draft-ietf-l3vpn-2547bis-mcast-bgp-06 == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-vpls-mcast-reqts-05 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 7 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: Standards Track 5 Expiration Date: January 2012 Y. Kamite 6 NTT Communications 8 L. Fang 9 Cisco Systems, Inc 11 July 05, 2011 13 Multicast in VPLS 15 draft-ietf-l2vpn-vpls-mcast-09.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) 2010 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 ........................................... 9 88 6.6 Inter-AS VPLS Multicast ............................... 10 89 7 Intra-AS Inclusive P-Multicast Tree A-D/Binding ....... 11 90 7.1 Originating intra-AS VPLS auto-discovery routes ....... 12 91 7.2 Receiving intra-AS VPLS auto-discovery routes ......... 13 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 E-BGP ......... 21 110 10.2.2.2 Inter-AS A-D route received via E-BGP ................. 22 111 10.2.2.3 Leaf A-D Route received via E-BGP ..................... 24 112 10.2.2.4 Inter-AS A-D Route received via I-BGP ................. 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 ............. 28 116 11.2 Advertising C-(S, G) Binding to a Selective Tree ...... 28 117 11.3 Receiving S-PMSI A-D routes by PEs .................... 31 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 auto-discovery route ........................... 37 129 12.2.2 Leaf auto-discovery 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 ................................... 43 138 18 Acknowledgments ....................................... 44 139 19 Normative References .................................. 44 140 20 Informative References ................................ 44 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 4. Introduction 166 [RFC4761] and [RFC4762] describe a solution for VPLS multicast that 167 relies on the use of P2P RSVP-TE or MP2P LDP LSPs, referred to as 168 Ingress Replication in this document. This solution has certain 169 limitations for certain VPLS multicast traffic profiles. For example 170 it may result in highly non-optimal bandwidth utilization in the MPLS 171 network when large amount of multicast traffic is to be transported 173 This document describes procedures for overcoming the limitations of 174 existing VPLS multicast solutions. It describes procedures for VPLS 175 multicast that utilize multicast trees in the Sevice Provider (SP) 176 network. The procedures described in this document are applicable to 177 both [RFC4761] and [RFC4762]. 179 It provides mechanisms that allow a single multicast distribution 180 tree in the Service Provider (SP) network to carry all the multicast 181 traffic from one or more VPLS sites connected to a given PE, 182 irrespective of whether these sites belong to the same or different 183 VPLSes. Such a tree is referred to as an "Inclusive tree" and more 184 specifically as an "Aggregate Inclusive tree" when the tree is used 185 to carry multicast traffic from more than one VPLS. 187 This document also provides procedures by which a single multicast 188 distribution tree in the SP network can be used to carry traffic 189 belonging only to a specified set of IP multicast streams, originated 190 in one or more VPLS sites connected to a given PE, irrespective of 191 whether these sites belong to the same or different VPLSes. Such a 192 tree is referred to as a "Selective tree" and more specifically as an 193 "Aggregate Selective tree" when the IP multicast streams belong to 194 different VPLSes. This allows multicast traffic, by default, to be 195 carried on an Inclusive tree, while traffic from some specific 196 multicast streams, e.g., high bandwidth streams, could be carried on 197 one of the "Selective trees". 199 5. Existing Limitations of VPLS Multicast 201 One of the limitations of existing VPLS multicast solutions described 202 in [RFC4761] and [RFC4762] is that they rely on ingress replication. 203 Thus, the ingress PE replicates the multicast packet for each egress 204 PE and sends it to the egress PE using a unicast tunnel. 206 Ingress Replication may be an acceptable model when the bandwidth of 207 the multicast traffic is low or/and the number of replications 208 performed on an average on each outgoing interface for a particular 209 customer VPLS multicast packet is small. If this is not the case it 210 is desirable to utilize multicast trees in the SP network to transmit 211 VPLS multicast packets [MCAST-VPLS-REQ]. Note that unicast packets 212 that are flooded to each of the egress PEs, before the ingress PE 213 learns the destination MAC address of those unicast packets, MAY 214 still use ingress replication. 216 6. Overview 218 This document describes procedures for using multicast trees in the 219 SP network to transport VPLS multicast data packets. RSVP-TE P2MP 220 LSPs described in [RFC4875] are an example of such multicast trees. 221 The use of multicast trees in the SP network can be beneficial when 222 the bandwidth of the multicast traffic is high or when it is 223 desirable to optimize the number of copies of a multicast packet 224 transmitted on a given link. This comes at a cost of state in the SP 225 network to build multicast trees and overhead to maintain this state. 226 This document describes procedures for using multicast trees for VPLS 227 multicast when the provider tunnels are P2MP LSPs signaled by either 228 P2MP RSVP-PE or mLDP [MLDP]. 230 This document uses the prefix 'C' to refer to the customer control or 231 data packets and 'P' to refer to the provider control or data 232 packets. An IP (multicast source, multicast group) tuple is 233 abbreviated to (S, G). 235 6.1. Inclusive and Selective Multicast Trees 237 Multicast trees used for VPLS can be of two types: 239 1. Inclusive trees. This option supports the use of a single 240 multicast distribution tree, referred to as an Inclusive P-Multicast 241 tree, in the SP network to carry all the multicast traffic from a 242 specified set of VPLS sites connected to a given PE. There is no 243 assumption made with respect to whether this traffic is IP 244 encapsulated or not. A particular P-Multicast tree can be set up to 245 carry the traffic originated by sites belonging to a single VPLS, or 246 to carry the traffic originated by sites belonging to different 247 VPLSes. The ability to carry the traffic of more than one VPLS on the 248 same tree is termed Aggregation. The tree needs to include every PE 249 that is a member of any of the VPLSes that are using the tree. This 250 implies that a PE may receive multicast traffic for a multicast 251 stream even if it doesn't have any receivers that are interested in 252 receiving traffic for that stream. 254 An Inclusive P-Multicast tree as defined in this document is a P2MP 255 tree. A P2MP tree is used to carry traffic only from VPLS sites that 256 are connected to the PE that is the root of the tree. 258 2. Selective trees. A Selective P-Multicast tree is used by a PE 259 to send IP multicast traffic for one or IP more specific multicast 260 streams, received by a PE over PE-CE interfaces that belong to the 261 same or different VPLSes, to a subset of the PEs that belong to those 262 VPLSes. Each of the PEs in the subset should be on the path to a 263 receiver of one or more multicast streams that are mapped onto the 264 tree. The ability to use the same tree for multicast streams that 265 belong to different VPLSes is termed Aggregation. The reason for 266 having Selective P-Multicast trees is to provide a PE the ability to 267 create separate SP multicast trees for specific multicast streams, 268 e.g. high bandwidth multicast streams. This allows traffic for these 269 multicast streams to reach only those PE routers that have receivers 270 in these streams. This avoids flooding other PE routers in the VPLS. 272 A SP can use both Inclusive P-Multicast trees and Selective P- 273 Multicast trees or either of them for a given VPLS on a PE, based on 274 local configuration. Inclusive P-Multicast trees can be used for 275 both IP and non-IP data multicast traffic, while Selective P- 276 Multicast trees must be used only for IP multicast data traffic. The 277 use of Selective P-Multicast trees for non-IP multicast traffic is 278 outside the scope of this document. 280 A variety of transport technologies may be used in the SP network. 281 For inclusive P-Multicast trees, these transport technologies include 282 point-to-multipoint LSPs created by RSVP-TE or mLDP. For selective P- 283 Multicast trees, only unicast PE-PE tunnels (using MPLS or IP/GRE 284 encapsulation) and P2MP LSPs are supported, and the supported P2MP 285 LSP signaling protocols are RSVP-TE, and mLDP. Other transport 286 technologies are outside the scope of this document. 288 This document also describes the data plane encapsulations for 289 supporting the various SP multicast transport options. 291 6.2. BGP-Based VPLS Membership Auto-Discovery 293 In order to establish Inclusive P-Multicast trees for one or more 294 VPLSes, when Aggregation is performed or when the tunneling 295 technology is P2MP RSVP-TE, the root of the tree must be able to 296 discover the other PEs that have membership in one or more of these 297 VPLSes. This document uses the BGP-based procedures described in 298 [RFC4761] and [L2VPN-SIG] for discovering the VPLS membership of all 299 PEs. 301 The leaves of the Inclusive P-Multicast trees must also be able to 302 auto-discover the identifier of the tree. This is described in 303 section 6.4. 305 6.3. IP Multicast Group Membership Discovery 307 The setup of a Selective P-Multicast tree for one or more IP 308 multicast (S, G)s, requires the ingress PE to learn the PEs that have 309 receivers in one or more of these (C-S, C-G)s, in the following 310 cases: 312 + When aggregation is used OR 314 + When the tunneling technology is P2MP RSVP-TE 316 + If ingress replication is used and the ingress PE wants to send 317 traffic for (C-S, C-G)s to only those PEs that are on the path to 318 receivers to the (C-S,C-G)s. 320 For discovering the IP multicast group membership, this document 321 describes procedures that allow an ingress PE to enable explicit 322 tracking. Thus an ingress PE can request the IP multicast membership 323 from egress PEs for one or more C-multicast streams. These procedures 324 are described in section "Optimizing Multicast Distribution via 325 Selective Trees". 327 These procedures are applicable when IGMP is used as the multicast 328 signaling protocol between the VPLS CEs. They are also applicable 329 when PIM as specified in [RFC4601] is used as the multicast routing 330 protocol between the VPLS CEs and PIM join suppression is disabled on 331 all the CEs. However these procedures do not apply when PIM is used 332 as the multicast routing protocol between the VPLS CEs and PIM join 333 suppression is not disabled on all the CEs. Procedures for this case 334 are for further study. 336 The leaves of the Selective P-Multicast trees must also be able to 337 discover the identifier of the tree. This is described in section 338 6.4. 340 6.4. Advertising P-Multicast Tree to VPLS/C-Multicast Binding 342 This document describes procedures based on BGP VPLS Auto-Discovery 343 (A-D) that are used by the root of an Aggregate P-Multicast tree to 344 advertise the Inclusive or Selective P-Multicast tree binding and the 345 de-multiplexing information to the leaves of the tree. This document 346 uses the PMSI Tunnel attribute [BGP-MVPN] for this purpose. 348 Once a PE decides to bind a set of VPLSes or customer multicast 349 groups to an Inclusive P-Multicast tree or a Selective P-Multicast 350 tree, it needs to announce this binding to other PEs in the network. 351 This procedure is referred to as Inclusive P-Multicast tree or 352 Selective P-Multicast tree binding distribution and is performed 353 using BGP. 355 When an Aggregated Inclusive P-Multicast tree is used by an ingress 356 PE, this discovery implies that an ingress PE MUST announce the 357 binding of all VPLSes bound to the Inclusive P-Multicast tree to the 358 other PEs. The inner label assigned by the ingress PE for each VPLS 359 MUST be included, if more than one VPLS is bound to the same P- 360 Multicast tree. The Inclusive P-Multicast tree Identifier MUST be 361 included. 363 For a Selective P-Multicast tree this discovery implies announcing 364 all the specific entries bound to this P-Multicast tree 365 along with the Selective P-Multicast tree Identifier. The inner label 366 assigned for each MUST be included if s from 367 different VPLSes are bound to the same P-Multicast tree. The labels 368 MUST be distinct on a per VPLS basis and MAY be distinct on a per basis. The Selective P-Multicast tree Identifier MUST be 370 included. 372 6.5. Aggregation 374 As described above the ability to carry the traffic of more than one 375 VPLS on the same P-Multicast tree is termed 'Aggregation'. Both 376 Inclusive and Selective P-Multicast trees support aggregation. 378 Aggregation enables the SP to place a bound on the amount of 379 multicast tree forwarding and control plane state which the P routers 380 must have. Let us call the number of VPLSes aggregated onto a single 381 P-Multicast tree as the "Aggregation Factor". When Inclusive source 382 P-Multicast trees are used the number of trees that a PE is the root 383 of is proportional to: 385 + (Number of VPLSes on the PE / Aggregation Factor). 387 In this case the state maintained by a P router, is proportional to: 389 + ((Average number of VPLSes on a PE / Aggregation Factor) * number 390 of PEs) / (Average number of P-Multicast trees that transit a 391 given P router) 393 Thus, the state does not grow linearly with the number of VPLSes. 395 Aggregation requires a mechanism for the egresses of the P-Multicast 396 tree to demultiplex the multicast traffic received over the P- 397 Multicast tree. To enable the egress nodes to perform this 398 demultiplexing, upstream-assigned labels [RFC5331] MUST be assigned 399 and distributed by the root of the aggregate P-multicast tree." 401 6.6. Inter-AS VPLS Multicast 403 This document supports three models of inter-AS VPLS service, option 404 (a), (b) and (c) which are very similar conceptually to option (a), 405 (b) and (c) specified in [RFC4364] for IP VPNs. The three options 406 described here are also similar to the three options described in in 407 [RFC4761], which in turn extends the concepts of [RFC4364] to inter- 408 AS VPLS. 410 For option (a) and option (b) support this document specifies a model 411 where Inter-AS VPLS service can be offered without requiring a single 412 P-Multicast tree to span multiple ASes. There are two variants of 413 this model and they are described in section 10. 415 For option (c) support this document specifies a model where Inter-AS 416 VPLS service is offered by requiring a single P-Multicast tree to 417 span multiple ASs. This is because in the case of option (c) the 418 ASBRs do not exchange BGP-VPLS NLRIs or A-D routes. 420 7. Intra-AS Inclusive P-Multicast Tree A-D/Binding 422 This section specifies procedures for the intra-AS auto-discovery (A- 423 D) of VPLS membership and the distribution of information used to 424 instantiate P-Multicast Tunnels. 426 VPLS auto-discovery/binding consists of two components: intra-AS and 427 inter-AS. The former provides VPLS auto-discovery/binding within a 428 single AS. The latter provides VPLS auto-discovery/binding across 429 multiple ASes. Inter-AS auto-discovery/binding is described in 430 section 10. 432 VPLS auto-discovery using BGP as described in [RFC4761, RFC6074] 433 enables a PE to learn the VPLS membership of other PEs. A PE that 434 belongs to a particular VPLS announces a BGP Network Layer 435 Reachability Information (NLRI) that identifies the Virtual Switch 436 Instance (VSI). This NLRI is constructed from the tuple. The 438 NLRI defined in [RFC4761] comprises the tuple and label 439 blocks for PW signaling. The VE-ID in this case is a two octet 440 number. The NLRI defined in [RFC6074] comprises only the 441 where the VE-ID is a four octet number. 443 The procedures for constructing Inclusive intra-AS and inter-AS trees 444 as specified in this document require the BGP A-D NLRI to carry only 445 the . Hence these procedures can be used for both BGP-VPLS 446 and LDP-VPLS with BGP A-D. 448 It is to be noted that BGP A-D is an inherent feature of BGP-VPLS. 449 However it is not an inherent feature of LDP-VPLS. Infact there are 450 deployments and/or implementations of LDP-VPLS that require 451 configuration to enable a PE in a particular VPLS to determine other 452 PEs in the VPLS and exchange PW labels using FEC 128 [RFC4447]. The 453 use of BGP A-D for LDP-VPLS [RFC6074], to enable automatic setup of 454 PWs, requires FEC 129 [RFC4447]. However FEC 129 is not required in 455 order to use procedures in this document for LDP-VPLS. An LDP-VPLS 456 implementation that supports this document MUST support the BGP A-D 457 procedures to setup P-Multicast trees, as described here, and it MAY 458 support FEC 129 to automate the signaling of PWs. 460 7.1. Originating intra-AS VPLS auto-discovery routes 462 To participate in the VPLS auto-discovery/binding a PE router that 463 has a given VSI of a given VPLS originates an BGP VPLS intra-AS auto- 464 discovery route and advertises this route in Multi-Protocol (MP) I- 465 BGP. The route is constructed as described in [RFC4761] and 466 [RFC6074]. 468 The route carries a single L2VPN NLRI with the RD set to the RD of 469 the VSI, and the VE-ID set to the VE-ID of the VSI. 471 The route also carries one or more Rout Targets (RTs) as specified in 472 [RFC4761] and [RFC6074]. 474 If an Inclusive P-Multicast tree is used to instantiate the provider 475 tunnel for VPLS multicast on the PE, the advertising PE MUST 476 advertise the type and the identity of the P-Multicast tree in the 477 the PMSI Tunnel attribute [BGP-MVPN]. This attribute is described in 478 section 12.1. 480 A PE that uses an Inclusive P-Multicast tree to instantiate the 481 provider tunnel MAY aggregate two or more VPLSes present on the PE 482 onto the same tree. If the PE decides to perform aggregation after it 483 has already advertised the intra-AS VPLS auto-discovery routes for 484 these VPLSes, then aggregation requires the PE to re-advertise these 485 routes. The re-advertised routes MUST be the same as the original 486 ones, except for the PMSI Tunnel attribute. If the PE has not 487 previously advertised intra-AS auto-discovery routes for these 488 VPLSes, then the aggregation requires the PE to advertise (new) 489 intra-AS auto-discovery routes for these VPLSes. The PMSI attribute 490 in the newly advertised/re-advertised routes MUST carry the identity 491 of the P-Multicast tree that aggregates the VPLSes, as well as an 492 MPLS upstream-assigned label [RFC5331]. Each re-advertised route MUST 493 have a distinct label. 495 Discovery of PE capabilities in terms of what tunnels types they 496 support is outside the scope of this document. Within a given AS PEs 497 participating in a VPLS are expected to advertise tunnel bindings 498 whose tunnel types are supported by all other PEs that are 499 participating in this VPLS and are part of the same AS. 501 7.2. Receiving intra-AS VPLS auto-discovery routes 503 When a PE receives a BGP Update message that carries an intra-AS A-D 504 route such that (a) the route was originated by some other PE within 505 the same AS as the local PE, (b) at least one of the Route Targets of 506 the route matches one of the import Route Targets configured for a 507 particular VSI on the local PE, (c) the BGP route selection 508 determines that this is the best route with respect to the NLRI 509 carried by the route, and (d) the route carries the PMSI Tunnel 510 attribute, the PE performs the following. 512 If the route carries the PMSI Tunnel attribute then: 514 + If the Tunnel Type in the PMSI Tunnel attribute is set to LDP 515 P2MP LSP, the PE SHOULD join the P-Multicast tree whose identity 516 is carried in the PMSI Tunnel attribute. 518 + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE 519 P2MP LSP, the receiving PE has to establish the appropriate state 520 to properly handle the traffic received over that LSP. The PE 521 that originated the route MUST establish an RSVP-TE P2MP LSP with 522 the local PE as a leaf. This LSP MAY have been established before 523 the local PE receives the route. 525 + If the PMSI Tunnel attribute does not carry a label, then all 526 packets that are received on the P-Multicast tree, as identified 527 by the PMSI Tunnel attribute, are forwarded using the VSIs that 528 have at least one of its import Route Targets that matches one of 529 the Route Targets of the received auto-discovery route. 531 + If the PMSI Tunnel attribute has the Tunnel Type set to LDP P2MP 532 LSP or RSVP-TE P2MP LSP, and the attribute also carries an MPLS 533 label, then the egress PE MUST treat this as an upstream-assigned 534 label, and all packets that are received on the P-Multicast tree, 535 as identified by the PMSI Tunnel attribute, with that upstream 536 label are forwarded using the VSIs that have at least one of its 537 import Route Target that matches one of the Route Targets of the 538 received intra-AS auto-discovery route. 540 If the local PE uses RSVP-TE P2MP LSP for sending (multicast) 541 traffic, originated by VPLS sites connected to the PE, to the sites 542 attached to other PEs then the local PE MUST use the Originating 543 Router's IP address information carried in the intra-AS A-D route to 544 add the PE, that originated the route, as a leaf node to the LSP. 545 This MUST be done irrespective of whether the received Intra-AS A-D 546 route carries the PMSI Tunnel attribute or not. 548 8. Demultiplexing P-Multicast Tree Traffic 550 Demultiplexing received VPLS traffic requires the receiving PE to 551 determine the VPLS instance the packet belongs to. The egress PE can 552 then perform a VPLS lookup to further forward the packet. It also 553 requires the egress PE to determine the identity of the ingress PE 554 for MAC learning, as described in section 15. 556 8.1. One P-Multicast Tree - One VPLS Mapping 558 When a P-Multicast tree is mapped to only one VPLS, determining the 559 tree on which the packet is received is sufficient to determine the 560 VPLS instance on which the packet is received. The tree is determined 561 based on the tree encapsulation. If MPLS encapsulation is used, 562 e.g.,: RSVP-TE P2MP LSPs, the outer MPLS label is used to determine 563 the tree. Penultimate-hop-popping MUST be disabled on the MPLS LSP 564 (RSVP-TE P2MP LSP or LDP P2MP LSP). 566 8.2. One P-Multicast Tree - Many VPLS Mapping 568 As traffic belonging to multiple VPLSes can be carried over the same 569 tree, there is a need to identify the VPLS the packet belongs to. 570 This is done by using an inner label that determines to the VPLS for 571 which the packet is intended. The ingress PE uses this label as the 572 inner label while encapsulating a customer multicast data packet. 573 Each of the egress PEs must be able to associate this inner label 574 with the same VPLS and use it to demultimplex the traffic received 575 over the Aggregate Inclusive tree or the Aggregate Selective tree. 577 If traffic from multiple VPLSes is carried on a single tree, 578 upstream-assigned labels [RFC5331] MUST be used. Hence the inner 579 label is assigned by the ingress PE. When the egress PE receives a 580 packet over an Aggregate tree, the outer encapsulation [in the case 581 of MPLS P2MP LSPs, the outer MPLS label] specifies the label space to 582 perform the inner label lookup. The same label space MUST be used by 583 the egress PE for all P-Multicast trees that have the same root 584 [RFC5331]. 586 If the tree uses MPLS encapsulation, as in RSVP-TE P2MP LSPs, the 587 outer MPLS label and optionally the incoming interface provides the 588 label space of the label beneath it. This assumes that penultimate- 589 hop-popping is disabled. The egress PE MUST NOT advertise IMPLICIT 590 NULL or EXPLICIT NULL for that tree once its known to the egress PE 591 that the tree is bound to one or more VPLSes. Once the label 592 representing the tree is popped off the MPLS label stack, the next 593 label is the demultiplexing information that allows the proper VPLS 594 instance to be determined. 596 The ingress PE informs the egress PEs about the inner label as part 597 of the tree binding procedures described in section 12. 599 9. Establishing P-Multicast Trees 601 This document supports only P2MP P-Multicast trees wherein its 602 possible for egress PEs to identify the ingress PE to perform MAC 603 learning. Specific procedures are specified only for RSVP-TE P2MP 604 LSPs and LDP P2MP LSPs. An implementation that supports this document 605 MUST support RSVP-TE P2MP LSPs and LDP P2MP LSPs. 607 A P2MP tree is used to carry traffic originated in sites connected to 608 the PE which is the root of the tree. These sites MAY belong to 609 different VPLSes or the same VPLS. 611 9.1. Common Procedures 613 The following procedures apply to both RSVP-TE P2MP and LDP P2MP 614 LSPs. 616 Demultiplexing the C-multicast data packets at the egress PE requires 617 that the PE must be able to determine the P2MP LSP that the packets 618 are received on. This enables the egress PE to determine the VPLS 619 instances that the packet belongs to. To achieve this the LSP MUST be 620 signaled with penultimate-hop-popping (PHP) off and a non-reserved 621 MPLS label off as described in section 8. In other words an egress PE 622 MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for a P2MP LSP that 623 is carrying traffic for one or more VPLSes. This is because the 624 egress PE needs to rely on the MPLS label, that it advertises to its 625 upstream neighbor, to determine the P2MP LSP that a C-multicast data 626 packet is received on. 628 The egress PE also needs to identify the ingress PE to perform MAC 629 learning. When P2MP LSPs are used as P2MP trees, determining the 630 P2MP LSP that the packets are received on, is sufficient to determine 631 the ingress PE. This is because the ingress PE is the root of the 632 P2MP LSP. 634 The egress PE relies on receiving the PMSI Tunnel attribute in BGP to 635 determine the VPLS instance to P2MP LSP mapping. 637 9.2. RSVP-TE P2MP LSPs 639 This section describes procedures that are specific to the usage of 640 RSVP-TE P2MP LSPs for instantiating a P-Multicast tree. Procedures in 641 [RFC4875] are used to signal the P2MP LSP. The LSP is signaled as the 642 root of the P2MP LSP discovers the leaves. The egress PEs are 643 discovered using the procedures described in section 7. Aggregation 644 as described in this document is supported. 646 9.2.1. P2MP TE LSP - VPLS Mapping 648 P2MP TE LSP to VPLS mapping is learned at the egress PEs using BGP 649 based advertisements of the P2MP TE LSP - VPLS mapping. They require 650 that the root of the tree include the P2MP TE LSP identifier as the 651 tunnel identifier in the BGP advertisements. This identifier contains 652 the following information elements: 653 - The type of the tunnel is set to RSVP-TE P2MP LSP 654 - RSVP-TE P2MP LSP's SESSION Object 656 This Tunnel Identifier is described in section 12.1. 658 Once the egress PE receives the P2MP TE LSP to VPLS mapping: 660 + If the egress PE already has RSVP-TE state for the P2MP TE LSP, 661 it MUST begin to assign a MPLS label from the non-reserved label 662 range, for the P2MP TE LSP and signal this to the previous hop of 663 the P2MP TE LSP. Further it MUST create forwarding state to 664 forward packets received on the P2MP LSP. 666 + If the egress PE does not have RSVP-TE state for the P2MP TE LSP, 667 it MUST retain this mapping. Subsequently when the egress PE 668 receives the RSVP-TE P2MP signaling message, it creates the RSVP- 669 TE P2MP LSP state. It MUST then assign a MPLS label from the 670 non-reserved label range, for the P2MP TE LSP, and signal this to 671 the previous hop of the P2MP TE LSP. 673 Note that if the signaling to set up an RSVP-TE P2MP LSP is 674 completed before a given egress PE learns, via a PMSI Tunnel 675 attribute, of the VPLS or set of VPLSes to which the LSP is 676 bound, the PE MUST discard any traffic received on that LSP until 677 the binding is received. In order for the egress PE to be able to 678 discard such traffic it needs to know that the LSP is associated 679 with one or more VPLSes and that the VPLS A-D route that binds 680 the LSP to a VPLS has not yet been received. This is provided by 681 extending [RFC4875] with [RSVP-OBB]. 683 9.3. Receiver Initiated MPLS Trees 685 Receiver initiated P2MP MPLS trees signaled using LDP [mLDP] can also 686 be used. Procedures in [MLDP] MUST be used to signal the P2MP LSP. 687 The LSP is signaled once the leaves receive the LDP FEC for the tree 688 from the root as described in section 7. An ingress PE is required to 689 discover the egress PEs when aggregation is used and this is achieved 690 using the procedures in section 7. 692 9.3.1. P2MP LSP - VPLS Mapping 694 P2MP LSP to VPLS mapping is learned at the egress PEs using BGP based 695 advertisements of the P2MP LSP - VPLS mapping. They require that the 696 root of the tree include the P2MP LSP identifier as the tunnel 697 identifier in the BGP advertisements. This identifier contains the 698 following information elements: 699 - The type of the tunnel is set to LDP P2MP LSP 700 - LDP P2MP FEC which includes an identifier generated by the 701 root. 703 Each egress PE SHOULD "join" the P2MP MPLS tree by sending LDP label 704 mapping messages for the LDP P2MP FEC, that was learned in the BGP 705 advertisement, using procedures described in [MLDP]. 707 9.4. Encapsulation of Aggregate P-Multicast Trees 709 An Aggregate Inclusive P-Multicast tree or an Aggregate Selective P- 710 Multicast tree MUST use a MPLS encapsulation. The protocol type in 711 the data link header is as described in [RFC5332]. 713 10. Inter-AS Inclusive P-Multicast Tree A-D/Binding 715 This document supports four options of inter-AS VPLS service, option 716 (a), (b), (c) and (e). Of these option (a), (b) and (c) are very 717 similar conceptually to option (a), (b) and (c) specified in 718 [RFC4364] for IP VPNs. These three options are also similar to the 719 three options described in [RFC4761], which in turn extend the 720 concepts of [RFC4364] to inter-AS VPLS. An implementation MUST 721 support all three of these options. When there are multiple ways for 722 implementing one of these options this section specifies which one is 723 mandatory. 725 For option (a), (b) and (e) support this section specifies a model 726 where inter-AS VPLS service can be offered without requiring a single 727 P-Multicast tree to span multiple ASes. This allows individual ASes 728 to potentially use different P-tunneling technologies. There are two 729 variants of this model. One that requires MAC lookup on the ASBRs and 730 applies to option (a) and (e). The other is one that does not require 731 MAC lookup on the ASBRs and instead builds segmented inter-AS 732 Inclusive or Selective trees. This applies only to option (b). 734 For option (c) support this document specifies a model where Inter-AS 735 VPLS service is offered by requiring a single Inclusive P-Multicast 736 tree to span multiple ASs. This is referred to as a non-segmented P- 737 Multicast tree. This is because in the case of option (c) the ASBRs 738 do not exchange BGP-VPLS NLRIs or VPLS A-D routes. Selective inter-AS 739 trees for option (c) support may be segmented or non-segmented. 741 10.1. VSIs on the ASBRs 743 When VSIs are configured on ASBRs, the ASBRs MUST perform a MAC 744 lookup, in addition to any MPLS lookups, to determine the forwarding 745 decision on a VPLS packet. The P-Multicast trees are confined to an 746 AS. An ASBR on receiving a VPLS packet from another ASBR is required 747 to perform a MAC lookup to determine how to forward the packet. Thus 748 an ASBR is required to keep a VSI for the VPLS and MUST be configured 749 with its own VE ID for the VPLS. The BGP VPLS A-D routes generated by 750 PEs in an AS MUST NOT be propagated outside the AS. 752 10.1.1. Option (a): VSIs on the ASBRs 754 When VSIs are configured on ASBRs and option (a) is used then an ASBR 755 in one AS treats an adjoining ASBR in another AS as a CE and 756 determines the VSI for packets received from that ASBR based on the 757 incoming ethernet interface. In option (a) the ASBRs do not exchange 758 VPLS A-D routes. 760 An implementation MUST support option (a). 762 10.1.2. Option (e): VSIs on the ASBRs 764 The VSIs on the ASBRs scheme can be used such that the interconnect 765 between the ASBRs is a PW and MPLS encapsulation is used between the 766 ASBRs. An ASBR in one AS treats an adjoining ASBR in another AS as a 767 CE and determines the VSI for packets received from another ASBR 768 based on the incoming MPLS encapsulation. This is referred to as 769 option (e). The only VPLS A-D routes that are propagated outside the 770 AS are the ones originated by ASBRs. This MPLS PW connects the VSIs 771 on the ASBRs and MUST be signaled using the procedures defined in 772 [RFC4761] or [RFC4762]. 774 The P-Multicast trees for a VPLS are confined to each AS and the VPLS 775 auto-discovery/binding MUST follow the intra-AS procedures described 776 in section 8. An implementation MAY support option (e). 778 10.2. Option (b) - Segmented Inter-AS Trees 780 In this model, an inter-AS P-Multicast tree, rooted at a particular 781 PE for a particular VPLS instance, consists of a number of 782 "segments", one per AS, which are stitched together at ASBRs. These 783 are known as "segmented inter-AS trees". Each segment of a segmented 784 inter-AS tree may use a different multicast transport technology. In 785 this model, an ASBR is not required to keep a VSI for the VPLS and is 786 not required to perform a MAC lookup in order to forward the VPLS 787 packet. This implies that an ASBR is not required to be configured 788 with a VE ID for the VPLS. This model is applicable to option (b). An 789 implementation MUST support option (b) using this model. 791 The construction of segmented Inter-AS trees requires the BGP-VPLS A- 792 D NLRI described in [RFC4761, RFC6074]. A BGP VPLS A-D route for a 793 tuple advertised outside the AS, to which the originating 794 PE belongs, will be referred to as an inter-AS VPLS auto-discovery 795 route (Though this route is originated by a PE as an intra-AS route 796 and is referred to as an inter-AS route outside the AS). 798 In addition to this, segmented inter-AS trees require support for the 799 PMSI Tunnel attribute described in section 12.1. They also require 800 additional procedures in BGP to signal leaf A-D routes between ASBRs 801 as explained in subsequent sections. 803 10.2.1. Segmented Inter-AS Trees VPLS Inter-AS A-D/Binding 805 This section specifies the procedures for inter-AS VPLS A-D/binding 806 for segmented inter-AS trees. 808 An ASBR must be configured to support a particular VPLS as follows: 810 + An ASBR MUST be be configured with a set of (import) Route 811 Targets (RTs) that specifies the set of VPLSes supported by the 812 ASBR. These Route Targets control acceptance of BGP VPLS auto- 813 discovery routes by the ASBR. Note that instead of being 814 configured, the ASBR MAY obtain this set of (import) Route 815 Targets (RTs) by using Route Target Constrain [RFC4684]. 817 + The ASBR MUST be configured with the tunnel types for the intra- 818 AS segments of the VPLSes supported by the ASBR, as well as 819 (depending on the tunnel type) the information needed to create 820 the PMSI Tunnel attribute for these tunnel types. Note that 821 instead of being configured, the ASBR MAY derive the tunnel types 822 from the intra-AS auto-discovery routes received by the ASBR from 823 the PEs in its own AS. 825 If an ASBR is configured to support a particular VPLS, the ASBR MUST 826 participate in the intra-AS VPLS auto-discovery/binding procedures 827 for that VPLS within the ASBR's own AS, as defined in this document. 829 Moreover, in addition to the above the ASBR performs procedures 830 specified in the next section. 832 10.2.2. Propagating BGP VPLS A-D routes to other ASes: Overview 834 An auto-discovery route for a given VPLS, originated by an ASBR 835 within a given AS, is propagated via BGP to other ASes. The precise 836 rules for distributing and processing the inter-AS auto-discovery 837 routes are given in subsequent sections. 839 Suppose that an ASBR A receives and installs an auto-discovery route 840 for VPLS "X" and VE ID "V" that originated at a particular PE, PE1. 841 The BGP next hop of that received route becomes A's "upstream 842 neighbor" on a multicast distribution tree for (X, V) that is rooted 843 at PE1. When the auto-discovery routes have been distributed to all 844 the necessary ASes, they define a "reverse path" from any AS that 845 supports VPLS X and VE ID V back to PE1. For instance, if AS2 846 supports VPLS X, then there will be a reverse path for VPLS X and VE 847 ID V from AS2 to AS1. This path is a sequence of ASBRs, the first of 848 which is in AS2, and the last of which is in AS1. Each ASBR in the 849 sequence is the BGP next hop of the previous ASBR in the sequence. 851 This reverse path information can be used to construct a 852 unidirectional multicast distribution tree for VPLS X and VE ID V, 853 containing all the ASes that support X, and having PE1 at the root. 854 We call such a tree an "inter-AS tree". Multicast data originating in 855 VPLS sites for VPLS X connected to PE1 will travel downstream along 856 the tree which is rooted at PE1. 858 The path along an inter-AS tree is a sequence of ASBRs. It is still 859 necessary to specify how the multicast data gets from a given ASBR to 860 the set of ASBRs which are immediately downstream of the given ASBR 861 along the tree. This is done by creating "segments": ASBRs in 862 adjacent ASes will be connected by inter-AS segments, ASBRs in the 863 same AS will be connected by "intra-AS segments". 865 For a given inter-AS tree and a given AS there MUST be only one ASBR 866 within that AS that accepts traffic flowing on that tree. Further for 867 a given inter-AS tree and a given AS there MUST be only one ASBR in 868 that AS that sends the traffic flowing on that tree to a particular 869 adjacent AS. The precise rules for accomplishing this are given in 870 subsequent sections. 872 An ASBR initiates creation of an intra-AS segment when the ASBR 873 receives an inter-AS auto-discovery route from an E-BGP neighbor. 874 Creation of the segment is completed as a result of distributing, via 875 I-BGP, this route within the ASBR's own AS. 877 For a given inter-AS tunnel each of its intra-AS segments could be 878 constructed by its own independent mechanism. Moreover, by using 879 upstream-assigned labels within a given AS multiple intra-AS segments 880 of different inter-AS tunnels of either the same or different VPLSes 881 may share the same P-Multicast tree. 883 If the P-Multicast tree instantiating a particular segment of an 884 inter-AS tunnel is created by a multicast control protocol that uses 885 receiver-initiated joins (e.g, mLDP), and this P-Multicast tree does 886 not aggregate multiple segments, then all the information needed to 887 create that segment will be present in the inter-AS auto-discovery 888 routes received by the ASBR from the neighboring ASBR. But if the P- 889 Multicast tree instantiating the segment is created by a protocol 890 that does not use receiver-initiated joins (e.g., RSVP-TE, ingress 891 unicast replication), or if this P-Multicast tree aggregates multiple 892 segments (irrespective of the multicast control protocol used to 893 create the tree), then the ASBR needs to learn the leaves of the 894 segment. These leaves are learned from A-D routes received from other 895 PEs in the AS, for the same VPLS (i.e. same VE-ID) as the one that 896 the segment belongs to. 898 The following sections specify procedures for propagation of inter-AS 899 auto-discovery routes across ASes in order to construct inter-AS 900 segmented trees. 902 10.2.2.1. Propagating Intra-AS VPLS A-D routes in E-BGP 904 For a given VPLS configured on an ASBR when the ASBR receives intra- 905 AS A-D routes originated by PEs in its own AS, the ASBR MUST 906 propagate each of these route in E-BGP. This procedure MUST be 907 performed for each of the VPLSes configured on the ASBR. Each of 908 these routes is constructed as follows: 910 + The route carries a single BGP VPLS A-D NLRI with the RD and VE 911 ID being the same as the NLRI in the received intra-AS A-D route. 913 + The Next Hop field of the MP_REACH_NLRI attribute is set to a 914 routable IP address of the ASBR. 916 + The route carries the PMSI Tunnel attribute with the Tunnel Type 917 set to Ingress Replication; the attribute carries no MPLS labels. 919 + The route MUST carry the export Route Target used by the VPLS. 921 10.2.2.2. Inter-AS A-D route received via E-BGP 923 When an ASBR receives from one of its E-BGP neighbors a BGP Update 924 message that carries an inter-AS auto-discovery route, if (a) at 925 least one of the Route Targets carried in the message matches one of 926 the import Route Targets configured on the ASBR, and (b) the ASBR 927 determines that the received route is the best route to the 928 destination carried in the NLRI of the route, the ASBR re-advertises 929 this inter-AS auto-discovery route to other PEs and ASBRs within its 930 own AS. The best route selection procedures MUST ensure that for the 931 same destination, all ASBRs in an AS pick the same route as the best 932 route. The best route selection procedures are specified in 933 [RFC4761] and clarified in [MULTI-HOMING]. The best route procedures 934 ensure that if multiple ASBRs, in an AS, receive the same inter-AS A- 935 D route from their E-BGP neighbors, only one of these ASBRs 936 propagates this route in I-BGP. This ASBR becomes the root of the 937 intra-AS segment of the inter-AS tree and ensures that this is the 938 only ASBR that accepts traffic into this AS from the inter-AS tree. 940 When re-advertising an inter-AS auto-discovery route the ASBR MUST 941 set the Next Hop field of the MP_REACH_NLRI attribute to a routable 942 IP address of the ASBR. 944 Depending on the type of a P-Multicast tunnel used to instantiate the 945 intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute of 946 the re-advertised inter-AS auto-discovery route is constructed as 947 follows: 949 + If the ASBR uses ingress replication to instantiate the intra-AS 950 segment of the inter-AS tunnel, the re-advertised route MUST NOT 951 carry the PMSI Tunnel attribute. 953 + If the ASBR uses a P-Multicast tree to instantiate the intra-AS 954 segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST 955 contain the identity of the tree that is used to instantiate the 956 segment (note that the ASBR could create the identity of the tree 957 prior to the actual instantiation of the segment). If in order to 958 instantiate the segment the ASBR needs to know the leaves of the 959 tree, then the ASBR obtains this information from the auto- 960 discovery routes received from other PEs/ASBRs in ASBR's own AS. 962 + An ASBR that uses a P-Multicast tree to instantiate the intra-AS 963 segment of the inter-AS tunnel MAY aggregate two or more VPLSes 964 present on the ASBR onto the same tree. If the ASBR already 965 advertises inter-AS auto-discovery routes for these VPLSes, then 966 aggregation requires the ASBR to re-advertise these routes. The 967 re-advertised routes MUST be the same as the original ones, 968 except for the PMSI Tunnel attribute. If the ASBR has not 969 previously advertised inter-AS auto-discovery routes for these 970 VPLSes, then the aggregation requires the ASBR to advertise (new) 971 inter-AS auto-discovery routes for these VPLSes. The PMSI Tunnel 972 attribute in the newly advertised/re-advertised routes MUST carry 973 the identity of the P-Multicast tree that aggregates the VPLSes, 974 as well as an MPLS upstream-assigned label [RFC5331]. Each re- 975 advertised route MUST have a distinct label. 977 In addition the ASBR MUST send to the E-BGP neighbor, from whom it 978 receives the inter-AS auto-discovery route, a BGP Update message that 979 carries a "leaf auto-discovery route". The exact encoding of this 980 route is described in section 12. This route contains the following 981 information elements: 983 + The route carries a single NLRI with the Route Key field set to 984 the tuple of the BGP VPLS A-D NLRI of the inter-AS 985 auto-discovery route received from the E-BGP neighbor. The NLRI 986 also carries the IP address of the ASBR (this MUST be a routable 987 IP address). 989 + The leaf auto-discovery route MUST include the PMSI Tunnel 990 attribute with the Tunnel Type set to Ingress Replication, and 991 the Tunnel Identifier set to a routable address of the 992 advertising router. The PMSI Tunnel attribute MUST carry a 993 downstream assigned MPLS label that is used to demultiplex the 994 VPLS traffic received over a unicast tunnel by the advertising 995 router. 997 + The Next Hop field of the MP_REACH_NLRI attribute of the route 998 SHOULD be set to the same IP address as the one carried in the 999 Originating Router's IP Address field of the route. 1001 + To constrain the distribution scope of this route the route MUST 1002 carry the NO_ADVERTISE BGP community ([RFC1997]). 1004 + The ASBR constructs an IP-based Route Target extended community 1005 by placing the IP address carried in the next hop of the received 1006 Inter-AS VPLS A-D route in the Global Administrator field of the 1007 community, with the Local Administrator field of this community 1008 set to 0, and sets the Extended Communities attribute of the Leaf 1009 A-D route to that community. Note that this Route Target is the 1010 same as the ASBR Import RT of the EBGP neighbor from which the 1011 ASBR received the inter-AS VPLS A-D route. 1013 10.2.2.3. Leaf A-D Route received via E-BGP 1015 When an ASBR receives via E-BGP a leaf auto-discovery route, the ASBR 1016 accepts the route only if (a) at least one of the Route Targets 1017 carried in the message matches one of the import Route Targets 1018 configured on the ASBR, and (b) the ASBR determines that the received 1019 route is the best route to the destination carried in the NLRI of the 1020 route. 1022 If the ASBR accepts the leaf auto-discovery route, the ASBR finds an 1023 existing auto-discovery route whose BGP-VPLS A-D NLRI has the same 1024 value as the field of the leaf auto-discovery route. 1026 The MPLS label carried in the PMSI Tunnel attribute of the leaf auto- 1027 discovery route is used to stitch a one hop ASBR-ASBR LSP to the tail 1028 of the intra-AS tunnel segment associated with the found auto- 1029 discovery route. 1031 10.2.2.4. Inter-AS A-D Route received via I-BGP 1033 In the context of this section we use the term "PE/ASBR router" to 1034 denote either a PE or an ASBR router. 1036 Note that a given inter-AS auto-discovery route is advertised within 1037 a given AS by only one ASBR as described above. 1039 When a PE/ASBR router receives from one of its I-BGP neighbors a BGP 1040 Update message that carries an inter-AS auto-discovery route, if (a) 1041 at least one of the Route Targets carried in the message matches one 1042 of the import Route Targets configured on the PE/ASBR, and (b) the 1043 PE/ASBR determines that the received route is the best route to the 1044 destination carried in the NLRI of the route, the PE/ASBR performs 1045 the following operations. The best route determination is based as 1046 described in [RFC4761] and clarified in [MULTI-HOMING]. 1048 If the router is an ASBR then the ASBR propagates the route to its E- 1049 BGP neighbors. When propagating the route to the E-BGP neighbors the 1050 ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a 1051 routable IP address of the ASBR. 1053 If the received inter-AS auto-discovery route carries the PMSI Tunnel 1054 attribute with the Tunnel Type set to LDP P2MP LSP, the PE/ASBR 1055 SHOULD join the P-Multicast tree whose identity is carried in the 1056 PMSI Tunnel attribute. 1058 If the received inter-AS auto-discovery route carries the PMSI Tunnel 1059 attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then 1060 the ASBR that originated the route MUST establish an RSVP-TE P2MP LSP 1061 with the local PE/ASBRas a leaf. This LSP MAY have been established 1062 before the local PE/ASBR receives the route, or MAY be established 1063 after the local PE receives the route. 1065 If the received inter-AS auto-discovery route carries the PMSI Tunnel 1066 attribute with the Tunnel Type set to LDP P2MP LSP, or RSVP-TE P2MP 1067 LSP, but the attribute does not carry a label, then the P-Multicast 1068 tree, as identified by the PMSI Tunnel attribute, is an intra-AS LSP 1069 segment that is part of the inter-AS Tunnel for the 1070 advertised by the inter-AS auto-discovery route and rooted at the PE 1071 that originated the auto-discovery route. If the PMSI Tunnel 1072 attribute carries a (upstream-assigned) label, then a combination of 1073 this tree and the label identifies the intra-AS segment. If the 1074 received router is an ASBR, this intra-AS segment may further be 1075 stitched to ASBR-ASBR inter-AS segment of the inter-AS tunnel. If the 1076 PE/ASBR has local receivers in the VPLS, packets received over the 1077 intra-AS segment must be forwarded to the local receivers using the 1078 local VSI. 1080 10.3. Option (c): Non-Segmented Tunnels 1082 In this model. there is a multi-hop E-BGP peering between the PEs (or 1083 a Route Reflector) in one AS and the PEs (or Route Reflector) in 1084 another AS. The PEs exchange BGP-VPLS NLRI or BGP-VPLS A-D NLRI, 1085 along with PMSI Tunnel attribute, as in the intra-AS case described 1086 in section 8. An implementation MUST support this model. 1088 The PEs in different ASs use a non-segmented inter-AS P2MP tunnel for 1089 VPLS multicast. A non-segmented inter-AS tunnel is a single tunnel 1090 which spans AS boundaries. The tunnel technology cannot change from 1091 one point in the tunnel to the next, so all ASes through which the 1092 tunnel passes must support that technology. In essence, AS boundaries 1093 are of no significance to a non-segmented inter-AS P2MP tunnel. 1095 This model requires no VPLS A-D routes in the control or VPLS MAC 1096 address learning in the data plane on the ASBRs. The ASBRs only need 1097 to participate in the non-segmented P2MP tunnel setup in the control 1098 plane, and do MPLS label forwarding in the data plane. 1100 The setup of non-segmented inter-AS P2MP tunnels MAY require the P- 1101 routers in one AS to have IP reachability to the loopback addresses 1102 of the PE routers in another AS, depending on the tunneling 1103 technology chosen. If this is the case, reachability to the loopback 1104 addresses of PE routers in one AS MUST be present in the IGP in 1105 another AS. 1107 The data forwarding in this model is the same as in the intra-AS case 1108 described in section 8. 1110 11. Optimizing Multicast Distribution via Selective Trees 1112 Whenever a particular multicast stream is being sent on an Inclusive 1113 P-Multicast tree, it is likely that the data of that stream is being 1114 sent to PEs that do not require it as the sites connected to these 1115 PEs may have no receivers for the stream. If a particular stream has 1116 a significant amount of traffic, it may be beneficial to move it to a 1117 Selective P-Multicast tree which has at its leaves only those PEs, 1118 connected to sites that have receivers for the multicast stream (or 1119 at least includes fewer PEs that are attached to sites with no 1120 receivers compared to an Inclusive tree). 1122 A PE connected to the multicast source of a particular multicast 1123 stream may be performing explicit tracking i.e. it may know the PEs 1124 that have receivers in the multicast stream. Section 11.3 describes 1125 procedures that enable explicit tracking. If this is the case 1126 Selective P-Multicast trees can also be triggered on other criteria. 1127 For instance there could be a "pseudo wasted bandwidth" criteria: 1128 switching to a Selective tree would be done if the bandwidth 1129 multiplied by the number of uninterested PEs (PE that are receiving 1130 the stream but have no receivers) is above a specified threshold. The 1131 motivation is that (a) the total bandwidth wasted by many sparsely 1132 subscribed low-bandwidth groups may be large, and (b) there's no 1133 point to moving a high-bandwidth group to a Selective tree if all the 1134 PEs have receivers for it. 1136 Switching a (C-S, C-G) stream to a Selective P-Multicast tree may 1137 require the root of the tree to determine the egress PEs that need to 1138 receive the (C-S, C-G) traffic. This is true in the following cases: 1140 + If the tunnel is a P2MP tree, such as a RSVP-TE P2MP Tunnel, the 1141 PE needs to know the leaves of the tree before it can instantiate 1142 the Selective tree. 1144 + If a PE decides to send traffic for multicast streams, belonging 1145 to different VPLSes, using one P-Multicast Selective tree, such a 1146 tree is termed an Aggregate tree with a selective mapping. The 1147 setting up of such an Aggregate tree requires the ingress PE to 1148 know all the other PEs that have receivers for multicast groups 1149 that are mapped onto the tree. 1151 + If ingress replication is used and the ingress PE wants to send 1152 traffic for (C-S, C-G)s to only those PEs that are on the path to 1153 receivers to the (C-S,C-G)s. 1155 For discovering the IP multicast group membership, for the above 1156 cases, this document describes procedures that allow an ingress PE to 1157 enable explicit tracking. Thus an ingress PE can request the IP 1158 multicast membership from egress PEs for one or more C-multicast 1159 streams. These procedures are described in section 11.3. 1161 The root of the Selective P-Multicast tree MAY decide to do explicit 1162 tracking of the IP multicast stream only after it has determined to 1163 move the stream to a Selective tree, or it MAY have been doing 1164 explicit tracking all along. This document also describes explicit 1165 tracking for a wild-card source and/or group in section 11.3, which 1166 facilitates a Selective P-Multicast tree only mode in which IP 1167 multicast streams are always carried on a Selective P-Multicast tree. 1168 In the description on Selective P-Multicast trees the notation C-S, 1169 is intended to representeither a specific source address or a 1170 wildcard. Similarly C-G is intended to represent either a specific 1171 group address or a wildcard. 1173 The PE at the root of the tree MUST signal the leaves of the tree 1174 that the (C-S, C-G) stream is now bound to the to the Selective Tree. 1175 Note that the PE could create the identity of the P-Multicast tree 1176 prior to the actual instantiation of the tunnel. 1178 If the Selective tree is instantiated by a RSVP-TE P2MP LSP the PE at 1179 the root of the tree MUST establish the P2MP RSVP-TE LSP to the 1180 leaves. This LSP MAY have been established before the leaves receive 1181 the Selective tree binding, or MAY be established after the leaves 1182 receives the binding. A leaf MUST not switch to the Selective tree 1183 until it receives the binding and the RSVP-TE P2MP LSP is setup to 1184 the leaf. 1186 11.1. Protocol for Switching to Selective Trees 1188 Selective trees provide a PE the ability to create separate P- 1189 Multicast trees for certain streams. The source PE, that 1190 originates the Selective tree, and the egress PEs, MUST use the 1191 Selective tree for the streams that are mapped to it. This 1192 may require the source and egress PEs to switch to the Selective tree 1193 from an Inclusive tree if they were already using an Inclusive tree 1194 for the streams mapped to the Selective tree. 1196 Once a source PE decides to setup an Selective tree, it MUST announce 1197 the mapping of the streams (which may be in different 1198 VPLSes) that are mapped to the tree to the other PEs using BGP. After 1199 the egress PEs receive the announcement they setup their forwarding 1200 path to receive traffic on the Selective tree if they have one or 1201 more receivers interested in the streams mapped to the 1202 tree. Setting up the forwarding path requires setting up the 1203 demultiplexing forwarding entries based on the top MPLS label (if 1204 there is no inner label) or the inner label (if present) as described 1205 in section 9. The egress PEs MAY perform this switch to the Selective 1206 tree once the advertisement from the ingress PE is received or wait 1207 for a preconfigured timer to do so, after receiving the 1208 advertisement, when the P2MP LSP protocol is mLDP. When the P2MP LSP 1209 protocol is P2MP RSVP-TE an egress PE MUST perform this switch to the 1210 Selective tree only after the advertisement from the ingress PE is 1211 received and the RSVP-TE P2MP LSP has been setup to the egress PE. 1212 This switch MAY be done after waiting for a preconfigured timer after 1213 these two steps have been accomplished. 1215 A source PE MUST use the following approach to decide when to start 1216 transmitting data on the Selective tree, if it was already using an 1217 Inclusive tree. A certain pre-configured delay after advertising the 1218 streams mapped to an Selective tree, the source PE begins 1219 to send traffic on the Selective tree. At this point it stops to send 1220 traffic for the streams, that are mapped on the Selective 1221 tree, on the Inclusive tree. This traffic is instead transmitted on 1222 the Selective tree. 1224 11.2. Advertising C-(S, G) Binding to a Selective Tree 1226 The ingress PE informs all the PEs that are on the path to receivers 1227 of the (C-S, C-G) of the binding of the Selective tree to the (C-S, 1228 C-G), using BGP. The BGP announcement is done by sending update for 1229 the MCAST-VPLS address family using what is referred to as the S-PMSI 1230 A-D route. The format of the NLRI is described in section 12.1. The 1231 NLRI MUST be constructed as follows: 1233 + The RD MUST be set to the RD configured locally for the VPLS. 1234 This is required to uniquely identify the as the 1235 addresses could overlap between different VPLSes. This MUST be 1236 the same RD value used in the VPLS auto-discovery process. 1238 + The Multicast Source field MUST contain the source address 1239 associated with the C-multicast stream, and the Multicast Source 1240 Length field is set appropriately to reflect this. If the source 1241 address is a wildcard the source address is set to 0. 1243 + The Multicast Group field MUST contain the group address 1244 associated with the C-multicast stream, and the Multicast Group 1245 Length field is set appropriately to reflect this. If the group 1246 address is a wildcard the group address is set to 0. 1248 + The Originating Router's IP Address field MUST be set to the IP 1249 address that the (local) PE places in the BGP next-hop of the 1250 BGP-VPLS A-D routes. Note that the tuple uniquely identifies a given VPLS. 1253 The PE constructs the rest of the Selective A-D route as follows. 1255 Depending on the type of a P-Multicast tree used for the P-tunnel, 1256 the PMSI tunnel attribute of the S-PMSI A-D route is constructed as 1257 follows: 1259 + The PMSI tunnel attribute MUST contain the identity of the P- 1260 Multicast tree (note that the PE could create the identity of the 1261 tree prior to the actual instantiation of the tree). 1263 + If in order to establish the P-Multicast tree the PE needs to 1264 know the leaves of the tree within its own AS, then the PE 1265 obtains this information from the Leaf A-D routes received from 1266 other PEs/ASBRs within its own AS (as other PEs/ASBRs originate 1267 Leaf A-D routes in response to receiving the S-PMSI A-D route) by 1268 setting the Leaf Information Required flag in the PMSI Tunnel 1269 attribute to 1. This enables explicit tracking for the multicast 1270 stream(s) advertised by the S-PMSI A-D route. 1272 + If a PE originates S-PMSI A-D routes with the Leaf Information 1273 Required flag in the PMSI Tunnel attribute set to 1, then the PE 1274 MUST be (auto)configured with an import Route Target, which 1275 controls acceptance of Leaf A-D routes by the PE. (Procedures for 1276 originating Leaf A-D routes by the PEs that receive the S-PMSI A- 1277 D route are described in section "Receiving S-PMSI A-D routes by 1278 PEs.) 1279 This Route Target is IP address specific. The Global 1280 Administrator field of this Route Target MUST be set to the IP 1281 address carried in the Next Hop of all the S-PMSI A-D routes 1282 advertised by this PE (if the PE uses different Next Hops, then 1283 the PE MUST be (auto)configured with multiple import RTs, one per 1284 each such Next Hop). The Local Administrator field of this Route 1285 Target MUST be set to 0. 1287 If the PE supports Route Target Constrain [RFC4684], the PE 1288 SHOULD advertise this import Route Target within its own AS using 1289 Route Target Constrains. To constrain distribution of the Route 1290 Target Constrain routes to the AS of the advertising PE these 1291 routes SHOULD carry the NO_EXPORT Community ([RFC1997]). 1293 + A PE MAY aggregate two or more S-PMSIs originated by the PE onto 1294 the same P-Multicast tree. If the PE already advertises S-PMSI A- 1295 D routes for these S-PMSIs, then aggregation requires the PE to 1296 re-advertise these routes. The re-advertised routes MUST be the 1297 same as the original ones, except for the PMSI tunnel attribute. 1298 If the PE has not previously advertised S-PMSI A-D routes for 1299 these S-PMSIs, then the aggregation requires the PE to advertise 1300 (new) S-PMSI A-D routes for these S-PMSIs. The PMSI Tunnel 1301 attribute in the newly advertised/re-advertised routes MUST carry 1302 the identity of the P-Multicast tree that aggregates the S-PMSIs. 1303 If at least some of the S-PMSIs aggregated onto the same P- 1304 Multicast tree belong to different VPLSes, then all these routes 1305 MUST carry an MPLS upstream assigned label [RFC5331]. If all 1306 these aggregated S-PMSIs belong to the same VPLS, then the routes 1307 MAY carry an MPLS upstream assigned label [RFC5331]. The labels 1308 MUST be distinct on a per VPLS basis, and MAY be distinct on a 1309 per route basis. 1311 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 1312 be set to the same IP address as the one carried in the Originating 1313 Router's IP Address field. 1315 By default the set of Route Targets carried by the route MUST be the 1316 same as the Route Targets carried in the BGP-VPLS A-D route 1317 originated from the VSI. The default could be modified via 1318 configuration. 1320 11.3. Receiving S-PMSI A-D routes by PEs 1322 Consider a PE that receives an S-PMSI A-D route. If one or more of 1323 the VSIs on the PE have their import Route Targets that contain one 1324 or more of the Route Targets carried by the received S-PMSI A-D 1325 route, then for each such VSI the PE performs the following. 1327 Procedures for receiving an S-PMSI A-D route by a PE (both within and 1328 outside of the AS of the PE that originates the route) are the same 1329 as specified in Section "Inter-AS A-D route received via IBGP" except 1330 that (a) instead of Inter-AS I-PMSI A-D routes the procedures apply 1331 to S-PMSI A-D routes, and (b) the rules for determining whether the 1332 received S-PMSI A-D route is the best route to the destination 1333 carried in the NLRI of the route, are the same as BGP path selection 1334 rules and may be modified by policy, and (c) a PE performs procedures 1335 specified in that section only if in addition to the criteria 1336 specified in that section the following is true: 1338 + If as a result of multicast state snooping on the PE-CE 1339 interfaces, the PE has snooped state for at least one multicast 1340 join that matches the multicast source and group advertised in 1341 the S-PMSI A-D route. Further if the oif (outgoing interfaces) 1342 for this state contains one or more interfaces to the locally 1343 attached CEs. When the multicast signaling protocol between PE 1344 and CE is IGMP, then snooping and associated procedures are 1345 defined in [RFC 4541]. The snooped state is determined using 1346 these procedures. When the multicast signaling protocol between 1347 PE and CE is PIM the, procedures in RFC4541 are not sufficient to 1348 determine the snooped state. The additional details required to 1349 determine the snooped state when PE-CE protocol is PIM are for 1350 further study. When such procedures are defined it is expected 1351 that the procedures in this section will apply to the snooped 1352 state created as a result of PIM as PE-CE protocol. 1354 The snooped state is said to "match" the S-PMSI A-D route if any of 1355 the following is true: 1357 + The S-PMSI A-D route carries (C-S, C-G) and the snooped state is 1358 for (C-S, C-G). OR 1360 + The S-PMSI A-D route carries (C-*, C-G) and (a) the snooped 1361 state is for (C-*, C-G) OR (b) the snooped state is for at least 1362 one multicast join with the multicast group address equal to C-G 1363 and there doesn't exist another S-PMSI A-D route that carries (C- 1364 S, C-G) where C-S is the source address of the snooped state. 1366 + The S-PMSI A-D route carries (C-S, C-*) and (a) the snooped 1367 state is for at least one multicast join with the multicast 1368 source address equal to C-S, and (b) there doesn't exist another 1369 S-PMSI A-D route that carries (C-S, C-G) where C-G is the group 1370 address of the snooped state. 1372 + The S-PMSI A-D route carries (C-*, C-*) and there is no other S- 1373 PMSI A-D route that matches the snooped state as per the above 1374 conditions. 1376 Note if the above conditions are true, and if the received S-PMSI A-D 1377 route has a PMSI Tunnel attribute with the Leaf Information Required 1378 flag set to 1, then the PE originates a Leaf A-D route. The Route Key 1379 of the Leaf A-D route is set to the MCAST-VPLS NLRI of the S-PMSI A-D 1380 route. The rest of the Leaf A-D route is constructed using the same 1381 procedures as specified in section "Originating Leaf A-D route into 1382 IBGP", except that instead of originating Leaf A-D routes in response 1383 to receiving Inter-AS A-D routes the procedures apply to originating 1384 Leaf A-D routes in response to receiving S-PMSI A-D routes. 1386 In addition to the procedures specified in Section "Inter-AS A-D 1387 route received via IBGP" the PE MUST set up its forwarding path to 1388 receive traffic, for each multicast stream in the matching snooped 1389 state, from the tunnel advertised by the S-PMSI A-D route (the PE 1390 MUST switch to the Selective tree). 1392 When a new snooped state is created by a PE then the PE MUST first 1393 determine if there is a S-PMSI route that matches the snooped state 1394 as per the conditions described above. If such a S-PMSI route is 1395 found then the PE MUST follow the procedures described in this 1396 section, for that particular S-PMSI route. 1398 11.4. Inter-AS Selective Tree 1400 Inter-AS Selective trees support all three options of inter-AS VPLS 1401 service, option (a), (b) and (c), that are supported by Inter-AS 1402 Inclusive trees. They are constructed in a manner that is very 1403 similar to Inter-AS Inclusive trees. 1405 For option (a) and option (b) support inter-AS Selective trees are 1406 constructed without requiring a single P-Multicast tree to span 1407 multiple ASes. This allows individual ASes to potentially use 1408 different P-tunneling technologies.There are two variants of this. 1409 One that requires MAC and IP multicast lookup on the ASBRs and 1410 another that does not require MAC/IP multicast lookup on the ASBRs 1411 and instead builds segmented inter-AS Selective trees. 1413 Segmented Inter-AS Selective trees can also be used with option (c) 1414 unlike Segmented Inter-AS Inclusive trees. This is because the S-PMSI 1415 A-D routes can be exchanged via ASBRs (even though BGP VPLS A-D 1416 routes are not exchanged via ASBRs). 1418 In the case of Option (c) an Inter-AS Selective tree may also be a 1419 non-segmented P-Multicast tree that spans multiple ASs. 1421 11.4.1. VSIs on the ASBRs 1423 The requirements on ASBRs, when VSIs are present on the ABSRs, 1424 include the requirements presented in section 10. The source ASBR 1425 (that receives traffic from another AS) may independently decide 1426 whether it wishes to use Selective trees or not. If it uses Selective 1427 trees the source ASBR MUST perform a MAC lookup to determine the 1428 Selective tree to forward the VPLS packet on. 1430 11.4.1.1. VPLS Inter-AS Selective Tree A-D Binding 1432 The mechanisms for propagating S-PMSI A-D routes are the same as the 1433 intra-AS case described in section 12.2. The BGP Selective tree A-D 1434 routes generated by PEs in an AS MUST NOT be propagated outside the 1435 AS. 1437 11.4.2. Inter-AS Segmented Selective Trees 1439 Inter-AS Segmented Selective trees MUST be used when option (b) is 1440 used to provide the inter-AS VPLS service. They MAY be used when 1441 option (c) is used to provide the inter-AS VPLS service. 1443 A Segmented inter-AS Selective Tunnel is constructed similar to an 1444 inter-AS Segmented Inclusive Tunnel. Namely, such a tunnel is 1445 constructed as a concatenation of tunnel segments. There are two 1446 types of tunnel segments: an intra-AS tunnel segment (a segment that 1447 spans ASBRs within the same AS), and inter-AS tunnel segment (a 1448 segment that spans adjacent ASBRs in adjacent ASes). ASes that are 1449 spanned by a tunnel are not required to use the same tunneling 1450 mechanism to construct the tunnel - each AS may pick up a tunneling 1451 mechanism to construct the intra-AS tunnel segment of the tunnel, in 1452 its AS. 1454 The PE that decides to set up a Selective tree, advertises the 1455 Selective tree to multicast stream binding using a S-PMSI A-D route 1456 as per procedures in section 11.2, to the routers in its own AS. 1458 A S-PMSI A-D route advertised outside the AS, to which the 1459 originating PE belongs, will be referred to as an inter-AS Selective 1460 Tree A-D route (Although this route is originated by a PE as an 1461 intra-AS route it is referred to as an inter-AS route outside the 1462 AS). 1464 11.4.2.1. Handling S-PMSI A-D routes by ASBRs 1466 Procedures for handling an S-PMSI A-D route by ASBRs (both within and 1467 outside of the AS of the PE that originates the route) are the same 1468 as specified in Section "Propagating VPLS BGP A-D routes to other 1469 ASes", except that instead of Inter-AS BGP-VPLS A-D routes and the 1470 BGP-VPLS A-D NLRI these procedures apply to S-PMSI A-D routes and the 1471 S-PMSI A-D NLRI. 1473 In addition to these procedures an ASBR advertises a Leaf A-D route 1474 in response to a S-PMSI A-D route only if: 1476 + The S-PMSI A-D route was received via EBGP from another ASBR and 1477 the ASBR merges the S-PMSI A-D route into an Inter-AS BGP VPLS A- 1478 D route as described in the next section. OR 1480 + The ASBR receives a Leaf A-D route from a downstream PE or ASBR 1481 in response to the S-PMSI A-D route, received from an upstream PE 1482 or ASBR, that the ASBR propagated inter-AS to downstream ASBRs 1483 and PEs. 1485 + The ASBR has snooped state from local CEs that matches the NLRI 1486 carried in the S-PMSI A-D route as per the following rules: 1488 i) The NLRI encodes (C-S, C-G) which is the same as the snooped 1489 (C-S, C-G) ii) The NLRI encodes (*, C-G) and there is snooped 1490 state for at least one (C-S, C-G) and there is no other matching 1491 SPMSI A-D route for (C-S, C-G) OR there is snooped state for (*, 1492 C-G) iii) The NLRI encodes (*, *) and there is snooped state for 1493 at least one (C-S, C-G) or (*, C-G) and there is no other 1494 matching SPMSI A-D route for that (C-S, C-G) or (*, C-G) 1495 respecively. 1497 The C-multicast data traffic is sent on the Selective tree by the 1498 originating PE. When it reaches an ASBR that is on the Inter-AS 1499 segmented tree, it is delivered to local receivers, if any. It is 1500 then forwarded on any inter-AS or intra-AS segments that exist on the 1501 Inter-AS Selective Segmented tree. If the Inter-AS Segmented 1502 Selective Tree is merged onto an Inclusive tree, as described in the 1503 next section, the data traffic is forwarded onto the Inclusive tree. 1505 11.4.2.1.1. Merging Selective Tree into an Inclusive Tree 1507 Consider the situation where: 1509 + An ASBR is receiving (or expecting to receive) inter-AS (C-S, C- 1510 G) data from upstream via a Selective tree. 1512 + The ASBR is sending (or expecting to send) the inter-AS (C-S, 1513 C-G) data downstream via an Inclusive tree. 1515 This situation may arise if the upstream providers have a policy of 1516 using Selective trees but the downstream providers have a policy of 1517 using Inclusive trees. To support this situation, an ASBR MAY, 1518 under certain conditions, merge one or more upstream Selective trees 1519 into a downstream Inclusive tree. Note that this can be the case only 1520 for option (b) and not for option (c) as for option (c) the ASBRs do 1521 not have Inclusive tree state. 1523 A Selective tree (corresponding to a particular S-PMSI A-D route) MAY 1524 be merged by a particular ASBR into an Inclusive tree 1525 (corresponding to a particular Inter-AS BGP VPLS A-D route) if and 1526 only if the following conditions all hold: 1528 + The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route 1529 originate in the same AS. The Inter-AS BGP VPLS A-D route carries 1530 the originating AS in the AS_PATH attribute of the route. The S- 1531 PMSI A-D route carries the originating AS in the AS_PATH 1532 attribute of the route. 1534 + The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route have 1535 exactly the same set of RTs. 1537 An ASBR performs merging by stitching the tail end of the P-tunnel, 1538 as specified in the the PMSI Tunnel attribute of the S-PMSI A-D route 1539 received by the ASBR, to the to the head of the P-tunnel, as 1540 specified in the PMSI Tunnel attribute of the Inter-AS BGP VPLS A-D 1541 route re-advertised by the ASBR. 1543 An ASBR that merges an S-PMSI A-D route into an Inter-AS BGP VPLS A-D 1544 route MUST NOT re-advertise the S-PMSI A-D route. 1546 11.4.3. Inter-AS Non-Segmented Selective trees 1548 Inter-AS Non-segmented Selective trees MAY be used in the case of 1549 option (c). 1551 In this method, there is a multi-hop E-BGP peering between the PEs 1552 (or a Route Reflector) in one AS and the PEs (or Route Reflector) in 1553 another AS. The PEs exchange BGP Selective tree A-D routes, along 1554 with PMSI Tunnel attribute, as in the intra-AS case described in 1555 section 10.3. 1557 The PEs in different ASs use a non-segmented Selective inter-AS P2MP 1558 tunnel for VPLS multicast. 1560 This method requires no VPLS information (in either the control or 1561 the data plane) on the ASBRs. The ASBRs only need to participate in 1562 the non-segmented P2MP tunnel setup in the control plane, and do MPLS 1563 label forwarding in the data plane. 1565 The data forwarding in this model is the same as in the intra-AS case 1566 described in section 9. 1568 12. BGP Extensions 1570 This section describes the encoding of the BGP extensions required by 1571 this document. 1573 12.1. Inclusive Tree/Selective Tree Identifier 1575 Inclusive P-Multicast tree and Selective P-Multicast tree 1576 advertisements carry the P-Multicast tree identifier. 1578 This document reuses the BGP attribute, called PMSI Tunnel attribute 1579 that is defined in [BGP-MVPN]. 1581 This document supports only the following Tunnel Types when PMSI 1582 Tunnel attribute is carried in VPLS A-D or VPLS S-PMSI A-D routes: 1584 + 0 - No tunnel information present 1585 + 1 - RSVP-TE P2MP LSP 1586 + 2 - LDP P2MP LSP 1587 + 6 - Ingress Replication 1589 12.2. MCAST-VPLS NLRI 1591 This document defines a new BGP NLRI, called the MCAST-VPLS NLRI. 1593 Following is the format of the MCAST-VPLS NLRI: 1595 +-----------------------------------+ 1596 | Route Type (1 octet) | 1597 +-----------------------------------+ 1598 | Length (1 octet) | 1599 +-----------------------------------+ 1600 | Route Type specific (variable) | 1601 +-----------------------------------+ 1603 The Route Type field defines encoding of the rest of MCAST-VPLS NLRI 1604 (Route Type specific MCAST-VPLS NLRI). 1606 The Length field indicates the length in octets of the Route Type 1607 specific field of MCAST-VPLS NLRI. 1609 This document defines the following Route Types for auto-discovery 1610 routes: 1611 + 3 - Selective Tree auto-discovery route; 1612 + 4 - Leaf auto-discovery route. 1614 The MCAST-VPLS NLRI is carried in BGP using BGP Multiprotocol 1615 Extensions [RFC4760] with an AFI of 25 (L2VPN AFI), and an SAFI of 1616 MCAST-VPLS [To be assigned by IANA]. The NLRI field in the 1617 MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the MCAST-VPLS NLRI 1618 (encoded as specified above). 1620 In order for two BGP speakers to exchange labeled MCAST-VPLS NLRI, 1621 they must use BGP Capabilities Advertisement to ensure that they both 1622 are capable of properly processing such NLRI. This is done as 1623 specified in [RFC4760], by using capability code 1 (multiprotocol 1624 BGP) with an AFI of 25 and an SAFI of MCAST-VPLS. 1626 The following describes the format of the Route Type specific MCAST- 1627 VPLS NLRI for various Route Types defined in this document. 1629 12.2.1. S-PMSI auto-discovery route 1631 An S-PMSI A-D route type specific MCAST-VPLS NLRI consists of the 1632 following: 1634 +-----------------------------------+ 1635 | RD (8 octets) | 1636 +-----------------------------------+ 1637 | Multicast Source Length (1 octet) | 1638 +-----------------------------------+ 1639 | Multicast Source (Variable) | 1640 +-----------------------------------+ 1641 | Multicast Group Length (1 octet) | 1642 +-----------------------------------+ 1643 | Multicast Group (Variable) | 1644 +-----------------------------------+ 1645 | Originating Router's IP Addr | 1646 +-----------------------------------+ 1648 The RD is encoded as described in [RFC4364]. 1650 The Multicast Source field contains the C-S address i.e the address 1651 of the multicast source. If the Multicast Source field contains an 1652 IPv4 address, then the value of the Multicast Source Length field is 1653 32. If the Multicast Source field contains an IPv6 address, then the 1654 value of the Multicast Source Length field is 128. The value of the 1655 Multicast Source Length field may be set to 0 to indicate a wildcard. 1657 The Multicast Group field contains the C-G address i.e. the address 1658 of the multicast group. If the Multicast Group field contains an IPv4 1659 address, then the value of the Multicast Group Length field is 32. 1660 If the Multicast Group field contains an IPv6 address, then the value 1661 of the Multicast Group Length field is 128. The Multicast Group 1662 Length field may be set to 0 to indicate a wildcard. 1664 Whether the Originating Router's IP Address field carries an IPv4 or 1665 IPv6 address is determined from the value of the Length field of the 1666 MCAST-VPLS NLRI. If the Multicast Source field contains an IPv4 1667 address and the Multicast Group field contains an IPv4 address, then 1668 the value of the Length field is 22 if the Originating Router's IP 1669 address carries an IPv4 address and 34 if it is an IPv6 address. If 1670 the Multicast Source and Multicast Group fields contain IPv6 1671 addresses, then the value of the Length field is 46 if the 1672 Originating Router's IP address carries an IPv4 address and 58 if it 1673 is an IPv6 address. The following table summarizes the above. 1675 Multicast Multicast Originating Router's Length 1676 Source Group IP Address 1678 IPv4 IPv4 IPv4 22 1679 IPv4 IPv4 IPv6 34 1680 IPv6 IPv6 IPv4 46 1681 IPv6 IPv6 IPv6 58 1683 Usage of Selective Tree auto-discovery routes is described in Section 1684 11. 1686 12.2.2. Leaf auto-discovery route 1688 A leaf auto-discovery route type specific MCAST-VPLS NLRI consists of 1689 the following: 1691 +-----------------------------------+ 1692 | Route Key (variable) | 1693 +-----------------------------------+ 1694 | Originating Router's IP Addr | 1695 +-----------------------------------+ 1697 Whether the Originating Router's IP Address field carries an IPv4 or 1698 IPv6 address is determined from the Length field of the MCAST-VPLS 1699 NLRI and the length field of the Route Key. From these two length 1700 fields one can compute the length of the Originating Router's IP 1701 Address. If this computed length is 4 then the address is an IPv4 1702 address and if its 16 then the address is an IPv6 address. 1704 Usage of Leaf auto-discovery routes is described in sections "Inter- 1705 AS Inclusive P-Multicast tree A-D/Binding" and "Optimizing Multicast 1706 Distribution via Selective trees". 1708 13. Aggregation Considerations 1710 In general the heuristic used to decide which VPLS instances or entries to aggregate is implementation dependent. It is also 1712 conceivable that offline tools can be used for this purpose. This 1713 section discusses some tradeoffs with respect to aggregation. 1715 The "congruency" of aggregation is defined by the amount of overlap 1716 in the leaves of the client trees that are aggregated on a SP tree. 1717 For Aggregate Inclusive trees the congruency depends on the overlap 1718 in the membership of the VPLSes that are aggregated on the Aggregate 1719 Inclusive tree. If there is complete overlap aggregation is perfectly 1720 congruent. As the overlap between the VPLSes that are aggregated 1721 reduces, the congruency reduces. 1723 If aggregation is done such that it is not perfectly congruent a PE 1724 may receive traffic for VPLSes to which it doesn't belong. As the 1725 amount of multicast traffic in these unwanted VPLSes increases 1726 aggregation becomes less optimal with respect to delivered traffic. 1727 Hence there is a tradeoff between reducing state and delivering 1728 unwanted traffic. 1730 An implementation should provide knobs to control the congruency of 1731 aggregation. This will allow a SP to deploy aggregation depending on 1732 the VPLS membership and traffic profiles in its network. If 1733 different PEs or shared roots' are setting up Aggregate Inclusive 1734 trees this will also allow a SP to engineer the maximum amount of 1735 unwanted VPLSes that a particular PE may receive traffic for. 1737 The state/bandwidth optimality trade-off can be further improved by 1738 having a versatile many-to-many association between client trees and 1739 provider trees. Thus a VPLS can be mapped to multiple Aggregate 1740 trees. The mechanisms for achieving this are for further study. Also 1741 it may be possible to use both ingress replication and an Aggregate 1742 tree for a particular VPLS. Mechanisms for achieving this are also 1743 for further study. 1745 14. Data Forwarding 1747 14.1. MPLS Tree Encapsulation 1749 14.1.1. Mapping multiple VPLS instances to a P2MP LSP 1751 The following diagram shows the progression of the VPLS multicast 1752 packet as it enters and leaves the SP network when MPLS trees are 1753 being used for multiple VPLS instances. RSVP-TE P2MP LSPs are 1754 examples of such trees. 1756 Packets received Packets in transit Packets forwarded 1757 at ingress PE in the service by egress PEs 1758 provider network 1760 +---------------+ 1761 |MPLS Tree Label| 1762 +---------------+ 1763 | VPLS Label | 1764 ++=============++ ++=============++ ++=============++ 1765 ||C-Ether Hdr || || C-Ether Hdr || || C-Ether Hdr || 1766 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1767 || C-IP Header || || C-IP Header || || C-IP Header || 1768 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1769 || C-Payload || || C-Payload || || C-Payload || 1770 ++=============++ ++=============++ ++=============++ 1772 The receiver PE does a lookup on the outer MPLS tree label and 1773 determines the MPLS forwarding table in which to lookup the inner 1774 MPLS label. This table is specific to the tree label space. The inner 1775 label is unique within the context of the root of the tree (as it is 1776 assigned by the root of the tree, without any coordination with any 1777 other nodes). Thus it is not unique across multiple roots. So, to 1778 unambiguously identify a particular VPLS one has to know the label, 1779 and the context within which that label is unique. The context is 1780 provided by the outer MPLS label [RFC5331]. 1782 The outer MPLS label is stripped. The lookup of the resulting MPLS 1783 label determines the VSI in which the receiver PE needs to do the C- 1784 multicast data packet lookup. It then strips the inner MPLS label and 1785 sends the packet to the VSI for multicast data forwarding. 1787 14.1.2. Mapping one VPLS instance to a P2MP LSP 1789 The following diagram shows the progression of the VPLS multicast 1790 packet as it enters and leaves the SP network when a given MPLS tree 1791 is being used for a single VPLS instance. RSVP-TE P2MP LSPs are 1792 examples of such trees. 1794 Packets received Packets in transit Packets forwarded 1795 at ingress PE in the service by egress PEs 1796 provider network 1798 +---------------+ 1799 |MPLS Tree Label| 1800 ++=============++ ++=============++ ++=============++ 1801 ||C-Ether Hdr || || C-Ether Hdr || || C-Ether Hdr || 1802 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1803 || C-IP Header || || C-IP Header || || C-IP Header || 1804 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1805 || C-Payload || || C-Payload || || C-Payload || 1806 ++=============++ ++=============++ ++=============++ 1808 The receiver PE does a lookup on the outer MPLS tree label and 1809 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 15. VPLS Data Packet Treatment 1815 If the destination MAC address of a VPLS packet received by a PE from 1816 a VPLS site is a multicast address, a P-Multicast tree SHOULD be used 1817 to transport the packet, if possible. If the packet is an IP 1818 multicast packet and a Selective tree exists for that multicast 1819 stream, the Selective tree MUST be used. Else if a (C-*, C-*) 1820 Selective tree exisits for the VPLS it SHOULD be used. Else if an 1821 Inclusive tree exists for the VPLS, it SHOULD be used. 1823 If the destination MAC address of a VPLS packet is a broadcast 1824 address, it is flooded. If a (C-*, C-*) Selective tree exists for the 1825 VPLS the PE SHOULD flood over it. Else if Inclusive tree exists for 1826 the VPLS the PE SHOULD flood over it. Else the PE MUST flood over 1827 multiple PWs, based on [RFC4761] or [RFC4762]. 1829 If the destination MAC address of a packet is a unicast address and 1830 it has not been learned, the packet MUST be sent to all PEs in the 1831 VPLS. Inclusive P-Multicast trees or a Selective P-Multicast tree 1832 bound to (C-*, C-*) SHOULD be used for sending unknown unicast MAC 1833 packets to all PEs. When this is the case the receiving PEs MUST 1834 support the ability to perform MAC address learning for packets 1835 received on a multicast tree. In order to perform such learning, the 1836 receiver PE MUST be able to determine the sender PE when a VPLS 1837 packet is received on a P-Multicast tree. This further implies that 1838 the MPLS P-Multicast tree technology MUST allow the egress PE to 1839 determine the sender PE from the received MPLS packet. 1841 When a receiver PE receives a VPLS packet with a source MAC address, 1842 that has not yet been learned, on a P-Multicast tree, the receiver PE 1843 determines the PW to the sender PE. The receiver PE then creates 1844 forwarding state in the VPLS instance with a destination MAC address 1845 being the same as the source MAC address being learned, and the PW 1846 being the PW to the sender PE. 1848 It should be noted that when a sender PE that is sending packets 1849 destined to an unknown unicast MAC address over a P-Multicast tree 1850 learns the PW to use for forwarding packets destined to this unicast 1851 MAC address, it might immediately switch to transport such packets 1852 over this particular PW. Since the packets were initially being 1853 forwarded using a P-Multicast tree, this could lead to packet 1854 reordering. This constraint should be taken into consideration if 1855 unknown unicast frames are forwarded using a P-Multicast tree, 1856 instead of multiple PWs based on [RFC4761] or [RFC4762]. 1858 An implementation MUST support the ability to transport unknown 1859 unicast traffic over Inclusive P-Multicast trees. Further an 1860 implementation MUST support the ability to perform MAC address 1861 learning for packets received on a P-Multicast tree. 1863 16. Security Considerations 1865 Security considerations discussed in [RFC4761] and [RFC4762] apply to 1866 this document. This section describes additional considerations. 1868 As mentioned in [RFC4761], there are two aspects to achieving data 1869 privacy in a VPLS: securing the control plane and protecting the 1870 forwarding path. Compromise of the control plane could result in a PE 1871 sending multicast data belonging to some VPLS to another VPLS, or 1872 blackholing VPLS multicast data, or even sending it to an 1873 eavesdropper; none of which are acceptable from a data privacy point 1874 of view. The mechanisms in this document use BGP for the control 1875 plane. Hence techniques such as in [RFC2385] help authenticate BGP 1876 messages, making it harder to spoof updates (which can be used to 1877 divert VPLS traffic to the wrong VPLS) or withdraws (denial-of- 1878 service attacks). In the multi-AS methods (b) and (c) described in 1879 Section 11, this also means protecting the inter-AS BGP sessions, 1880 between the ASBRs, the PEs, or the Route Reflectors. 1882 Note that [RFC2385] will not help in keeping MPLS labels, associated 1883 with P2MP LSPs or the upstream MPLS labels used for aggregation, 1884 private -- knowing the labels, one can eavesdrop on VPLS traffic. 1885 However, this requires access to the data path within a Service 1886 Provider network. 1888 One of the requirements for protecting the data plane is that the 1889 MPLS labels are accepted only from valid interfaces. This applies 1890 both to MPLS labels associated with P2MP LSPs and also applies to the 1891 upstream assigned MPLS labels. For a PE, valid interfaces comprise 1892 links from P routers. For an ASBR, valid interfaces comprise links 1893 from P routers and links from other ASBRs in ASes that have instances 1894 of a given VPLS. It is especially important in the case of multi-AS 1895 VPLSes that one accept VPLS packets only from valid interfaces. 1897 17. IANA Considerations 1899 This document defines a new NLRI, called MCAST-VPLS, to be carried in 1900 BGP using multiprotocol extensions. It requires assignment of a new 1901 SAFI. This is to be assigned by IANA. 1903 This document defines a BGP optional transitive attribute, called 1904 PMSI attribute. This is the same attribute as the one defined in 1905 [BGP-MVPN] and the code point for this attribute has already been 1906 assigned by IANA as 22 [BGP-IANA]. Hence no further action is 1907 required from IANA regarding this attribute. 1909 18. Acknowledgments 1911 Many thanks to Thomas Morin for his support of this work. We would 1912 also like to thank authors of [BGP-MVPN] and [MVPN] as the details of 1913 the inter-AS segmented tree procedures in this document have 1914 benefited from those in [BGP-MVPN] and [MVPN]. We would also like to 1915 thank Wim Henderickx for his comments. 1917 19. Normative References 1919 [RFC2119] "Key words for use in RFCs to Indicate Requirement 1920 Levels.", Bradner, March 1997 1922 [RFC4761] K. Kompella, Y. Rekther, "Virtual Private LAN Service", 1923 draft-ietf-l2vpn-vpls-bgp-02.txt 1925 [RFC4762] M. Lasserre, V. Kompella, "Virtual Private LAN Services 1926 over MPLS", draft-ietf-l2vpn-vpls-ldp-03.txt 1928 [RFC4760] T. Bates, et. al., "Multiprotocol Extensions for BGP-4", 1929 January 2007 1931 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 1932 Assignment and Context Specific Label Space", RFC 5331, August 2008 1934 [RSVP-OBB] Z. Ali, G. Swallow, R. Aggarwal, "Non PHP behavior and 1935 out-of-band mapping for RSVP-TE LSPs", draft-ietf-mpls-rsvp-te-no- 1936 php-obb-mapping, work in progress. 1938 20. Informative References 1940 [RFC6074] E. Rosen et. al., "Provisioning, Autodiscovery, and 1941 Signaling in L2VPNs", RFC 6074 1943 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, "MPLS 1944 Multicast Encapsulations", RFC 5332, August 2008 1946 [MVPN] E. Rosen, R. Aggarwal, "Multicast in 2547 VPNs", draft-ietf- 1947 l3vpn-2547bis-mcast-08.txt" 1949 [BGP-MVPN] R. Aggarwal, E. Rosen, Y. Rekhter, T. Morin, C. 1950 Kodeboniya. "BGP Encodings for Multicast in 2547 VPNs", draft-ietf- 1951 l3vpn-2547bis-mcast-bgp-06.txt 1953 [RFC4875] R. Aggarwal et. al, "Extensions to RSVP-TE for Point to 1954 Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-07.txt 1956 [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for 1957 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 1958 Paths", draft-ietf-mpls-ldp-p2mp, work in progress. 1960 [RFC4364] "BGP MPLS VPNs", E. Rosen, Y.Rekhter, February 2006 1962 [MCAST-VPLS-REQ] Y. kamite, et. al., "Requirements for Multicast 1963 Support in Virtual Private LAN Services", draft-ietf-l2vpn-vpls- 1964 mcast-reqts-05.txt 1966 [RFC1997] R. Chandra, et. al., "BGP Communities Attribute", August 1967 1996 1969 [BGP-IANA] http://www.iana.org/assignments/bgp-parameters 1971 [RFC4684] P. Marques et. al., "Constrained Route Distribution for 1972 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 1973 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 1974 November 2006 1976 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1977 Signature Option", RFC 2385, August 1998. 1979 [RFC4447] L. Martini et. al., "Pseudowire Setup and Maintenance Using 1980 the Label Distribution Protocol (LDP)", RFC 4447 April 2006 1982 [MULTI-HOMING] K. Kompella et. al., "Multi-homing in BGP-based 1983 Virtual Private LAN Service", draft-kompella-l2vpn-vpls- 1984 multihoming-02.txt 1986 [IGMP-SN] M. Christensen et. al., "Considerations for Internet Group 1987 Management Protocol (IGMP) and Multicast Listener Discovery (MLD) 1988 Snooping Switches", RFC 4541, May 2006 1990 [RFC4601] B. Fenner, et. al., "PIM-SM Protocol Specification", RFC 1991 4601 1993 21. Author's Address 1995 Rahul Aggarwal 1996 Juniper Networks 1997 1194 North Mathilda Ave. 1998 Sunnyvale, CA 94089 1999 USA 2000 Phone: +1-408-936-2720 2001 Email: rahul@juniper.net 2003 Yuji Kamite 2004 NTT Communications Corporation 2005 Tokyo Opera City Tower 2006 3-20-2 Nishi Shinjuku, Shinjuku-ku, 2007 Tokyo 163-1421, 2008 Japan 2010 Email: y.kamite@ntt.com 2012 Luyuan Fang 2013 Cisco Systems 2014 300 Beaver Brook Road 2015 BOXBOROUGH, MA 01719 2016 USA 2018 Email: lufang@cisco.com 2020 Yakov Rekhter 2021 Juniper Networks 2022 1194 North Mathilda Ave. 2023 Sunnyvale, CA 94089 2024 USA 2026 Email: yakov@juniper.net 2028 Chaitanya Kodeboniya