idnits 2.17.1 draft-kompella-l2vpn-l2vpn-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 12, 2012) is 4481 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4446' is defined on line 970, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella 3 Internet-Draft Juniper Networks 4 Intended status: Informational B. Kothari 5 Expires: July 15, 2012 Cisco Systems 6 R. Cherukuri 7 Juniper Networks 8 January 12, 2012 10 Layer 2 Virtual Private Networks Using BGP for Auto-discovery and 11 Signaling 12 draft-kompella-l2vpn-l2vpn-08.txt 14 Abstract 16 Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM 17 circuits have been around a long time; more recently, Ethernet VPNs, 18 including Virtual Private LAN Service, have become popular. 19 Traditional L2VPNs often required a separate Service Provider 20 infrastructure for each type, and yet another for the Internet and IP 21 VPNs. In addition, L2VPN provisioning was cumbersome. This document 22 presents a new approach to the problem of offering L2VPN services 23 where the L2VPN customer's experience is virtually identical to that 24 offered by traditional Layer 2 VPNs, but such that a Service Provider 25 can maintain a single network for L2VPNs, IP VPNs and the Internet, 26 as well as a common provisioning methodology for all services. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 15, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 64 1.2. Advantages of Layer 2 VPNs . . . . . . . . . . . . . . . . 6 65 1.2.1. Separation of Administrative Responsibilities . . . . 6 66 1.2.2. Migrating from Traditional Layer 2 VPNs . . . . . . . 7 67 1.2.3. Privacy of Routing . . . . . . . . . . . . . . . . . . 7 68 1.2.4. Layer 3 Independence . . . . . . . . . . . . . . . . . 7 69 1.2.5. PE Scaling . . . . . . . . . . . . . . . . . . . . . . 7 70 1.2.6. Ease of Configuration . . . . . . . . . . . . . . . . 8 71 1.3. Advantages of Layer 3 VPNs . . . . . . . . . . . . . . . . 9 72 1.3.1. Layer 2 Independence . . . . . . . . . . . . . . . . . 9 73 1.3.2. SP Routing as Added Value . . . . . . . . . . . . . . 9 74 1.3.3. Class-of-Service . . . . . . . . . . . . . . . . . . . 10 75 1.4. Multicast Routing . . . . . . . . . . . . . . . . . . . . 10 76 1.5. Conventions used in this document . . . . . . . . . . . . 11 77 2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 3. Operation of a Layer 2 VPN . . . . . . . . . . . . . . . . . . 13 79 3.1. Network Topology . . . . . . . . . . . . . . . . . . . . . 13 80 3.2. Configuration . . . . . . . . . . . . . . . . . . . . . . 14 81 3.2.1. CE Configuration . . . . . . . . . . . . . . . . . . . 15 82 3.2.2. PE Configuration . . . . . . . . . . . . . . . . . . . 16 83 3.2.3. Adding a New Site . . . . . . . . . . . . . . . . . . 16 84 4. PE Information Exchange . . . . . . . . . . . . . . . . . . . 17 85 4.1. Circuit Status Vector . . . . . . . . . . . . . . . . . . 19 86 4.2. Generalizing the VPN Topology . . . . . . . . . . . . . . 20 87 5. Layer 2 Interworking . . . . . . . . . . . . . . . . . . . . . 21 88 6. Packet Transport . . . . . . . . . . . . . . . . . . . . . . . 22 89 6.1. Layer 2 MTU . . . . . . . . . . . . . . . . . . . . . . . 22 90 6.2. Layer 2 Frame Format . . . . . . . . . . . . . . . . . . . 22 91 6.3. IP-only Layer 2 Interworking . . . . . . . . . . . . . . . 23 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 93 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 96 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 97 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 100 1. Introduction 102 The earliest Virtual Private Networks (VPNs) were based on Layer 2 103 circuits: X.25, Frame Relay and ATM (see [Kosiur]). More recently, 104 multipoint VPNs based on Ethernet Virtual Local Area Networks (VLANs) 105 and Virtual Private LAN Service (VPLS) ([RFC4761] and [RFC4762]) have 106 become quite popular. In contrast, the VPNs described in this 107 document are point-to-point, and usually called Virtual Private Wire 108 Service (VPWS). All of these come under the classification of Layer 109 2 VPNs (L2VPNs), as the customer to Service Provider (SP) hand-off is 110 at Layer 2. 112 There are at least two factors that adversely affected the cost of 113 offering L2VPNs. The first is that the easiest way to offer a L2VPN 114 of a given type of Layer 2 was over an infrastructure of the same 115 type. This approach required that the Service Provider build a 116 separate infrastructure for each Layer 2 encapsulation -- e.g., an 117 ATM infrastructure for ATM VPNs, an Ethernet infrastructure for 118 Ethernet VPNs, etc. In addition, a separate infrastructure was 119 needed for the Internet and IP VPNs ([RFC4364], and possibly yet 120 another for voice services. Going down this path meant a 121 proliferation of networks. 123 The other is that each of these networks had different provisioning 124 methodologies. Furthermore, the provisioning of a L2VPN was fairly 125 complex. It is important to distinguish between a single Layer 2 126 circuit, which connects two customer sites, and a Layer 2 VPN, which 127 is a set of circuits that connect sites belonging to the same 128 customer. The fact that two different circuits belonged to the same 129 VPN was typically known only to the provisioning system, not to the 130 switches offering the service; this complicated the setting up, and 131 subsequently, the troubleshooting, of a L2VPN. Also, each switch 132 offering the service had to be provisioned with the address of every 133 other switch in the same VPN, requiring, in the case of full-mesh VPN 134 connectivity, provisioning proportional to the square of the number 135 of sites. This made full-mesh L2VPN connectivity prohibitively 136 expensive for the SP, and thus in turn for customers. Finally, even 137 setting up a individual circuit often required the provisioning of 138 every switch along the path. 140 Of late, there has been much progress in network "convergence", 141 whereby Layer 2 traffic, Internet traffic and IP VPN traffic can be 142 carried over a single, consolidated network infrastructure based on 143 IP/MPLS tunnels; this is made possible by techniques such as those 144 described in [RFC4448], [RFC4618], [RFC4619], and [RFC4717] for Layer 145 2 traffic, and [RFC4364] for IP VPN traffic. This development goes a 146 long way toward addressing the problem of network profileration. 147 This document goes one step further and shows how a Service Provider 148 can offer Layer 2 VPNs using protocol and provisioning methodologies 149 similar to that used for VPLS ([RFC4761]) and IP VPNs ([RFC4364]), 150 thereby achieving a significant degree of operational convergence as 151 well. In particular, all of these methodologies include the notion 152 of a VPN identifier that serves to unify components of a given VPN, 153 and the concept of auto-discovery, which simplifies the provisioning 154 of dense VPN topologies (for example, a full mesh). In addition, 155 similar techniques are used in all of the above-mentioned VPN 156 technologies to offer inter-AS and inter-provider VPNs (i.e., VPNs 157 whose sites are connected to multiple Autonomous Systems (ASs) or 158 service providers). 160 Technically, the approach proposed here uses the concepts and 161 solution and described in [RFC4761], which describes a method for 162 VPLS, a particular form of a Layer 2 VPN. That document in turn 163 borrowed much from [RFC4364]. This includes the use of BGP for auto- 164 discovery and "demultiplexor" (see below) exchange, and the concepts 165 of Route Distinguishers to make VPN advertisements unique, and Route 166 Targets to control VPN topology. In addition, all three documents 167 share the idea that routers not directly connected to VPN customers 168 should carry no VPN state, restricting the provisioning of individual 169 connections to just the edge devices. This is achieved by using 170 tunnels to carry the data, with a demultiplexor that identifies 171 individual VPN circuits. These tunnels could be based on MPLS, GRE, 172 or any other tunnel technology that offers a demultiplexing field; 173 the signaling of these tunnels is outside the scope of this document. 174 The specific approach taken here is to use an MPLS label as the 175 demultiplexor. 177 Layer 2 VPNs typically require that all sites in the VPN connect to 178 the SP with the same Layer 2 encapsulation. To ease this 179 restriction, this document proposes a limited form of Layer 2 180 interworking, by restricting the Layer 3 protocol to IP only (see 181 Section 5). 183 It may be instructive to compare the approach in [RFC4447] and 184 [RFC6074] (these are the IETF-approved technologies for the functions 185 described in this document, albeit using two separate protocols) with 186 the one described here. Devices implementing the solution described 187 in this document must also implement the approach in [RFC4447] and 188 [RFC6074]. 190 The rest of this section discusses the relative merits of Layer 2 and 191 Layer 3 VPNs. Section 3 describes the operation of a Layer 2 VPN. 192 Section 5 describes IP-only Layer 2 interworking. Section 6 193 describes how the L2 packets are transported across the SP network. 195 1.1. Terminology 197 The terminology used is from [RFC4761] and [RFC4364], and is briefly 198 repeated here. A "customer" is a customer of a Service Provider 199 seeking to interconnect their various "sites" (each an independent 200 network) at Layer 2 through the Service Provider's network, while 201 maintaining privacy of communication and address space. The device 202 in a customer site that connects to a Service Provider router is 203 termed the CE (customer edge) device; this device may be a router or 204 a switch. The Service Provider router to which a CE connects is 205 termed a PE. A router in the Service Provider's network which 206 doesn't connect directly to any CE is termed P. Every pair of PEs is 207 connected by a "tunnel"; within a tunnel, VPN data is distinguished 208 by a "demultiplexor", which in this document is an MPLS label. 210 Each CE within a VPN is assigned a CE ID, a number that uniquely 211 identifies a CE within an L2 VPN. More accurately, the CE ID 212 identifies a physical connection from the CE device to the PE, since 213 a CE may be connected to multiple PEs (or multiply connected to a 214 PE); in such a case, the CE would have a CE ID for each connection. 215 A CE may also be part of many L2 VPNs; it would need one (or more) CE 216 ID(s) for each L2 VPN of which it is a member. The number space for 217 CE IDs is scoped to a given VPN. 219 In the case of inter-Provider L2 VPNs, there needs to be some 220 coordination of allocation of CE IDs. One solution is to allocate 221 ranges for each SP. Other solutions may be forthcoming. 223 Within each physical connection from a CE to a PE, there may be 224 multiple virtual circuits. These will be referred to as Attachment 225 Circuits (ACs), following [RFC3985]. Similarly, the entity that 226 connects two attachment circuits across the Service Provider network 227 is called a pseudowire (PW). 229 1.2. Advantages of Layer 2 VPNs 231 A Layer 2 VPN is one where a Service Provider provides Layer 2 232 connectivity to the customer. The Service Provider does not 233 participate in the customer's Layer 3 network, in particular, in the 234 routing, resulting in several advantages to the SP as a whole and to 235 PE routers in particular. 237 1.2.1. Separation of Administrative Responsibilities 239 In a Layer 2 VPN, the Service Provider is responsible for Layer 2 240 connectivity; the customer is responsible for Layer 3 connectivity, 241 which includes routing. If the customer says that host x in site A 242 cannot reach host y in site B, the Service Provider need only 243 demonstrate that site A is connected to site B. The details of how 244 routes for host y reach host x are the customer's responsibility. 246 Another important factor is that once a PE provides Layer 2 247 connectivity to its connected CE, its job is done. A misbehaving CE 248 can at worst flap its interface, but route flaps in the customer 249 network have little effect on the SP network. On the other hand, a 250 misbehaving CE in a Layer 3 VPN can flap its routes, leading to 251 instability of the PE router or even the entire SP network. Thus, 252 when offering a Layer 3 VPN, a SP should proactively protect itself 253 from Layer 3 instability in the CE network. 255 1.2.2. Migrating from Traditional Layer 2 VPNs 257 Since "traditional" Layer 2 VPNs (i.e., real Frame Relay circuits 258 connecting sites) are indistinguishable from tunnel-based VPNs from 259 the customer's point-of-view, migrating from one to the other raises 260 few issues. Layer 3 VPNs, on the other hand, require a considerable 261 re-design of the customer's Layer 3 routing architecture. 262 Furthermore, with Layer 3 VPNs, special care has to be taken that 263 routes within the traditional VPN are not preferred over the Layer 3 264 VPN routes (the so-called "backdoor routing" problem, whose solution 265 requires protocol changes that are somewhat ad hoc). 267 1.2.3. Privacy of Routing 269 In a Layer 2 VPN, the privacy of customer routing is a natural 270 fallout of the fact that the Service Provider does not participate in 271 routing. The SP routers need not do anything special to keep 272 customer routes separate from other customers or from the Internet; 273 there is no need for per-VPN routing tables, and the additional 274 complexity this imposes on PE routers. 276 1.2.4. Layer 3 Independence 278 Since the Service Provider simply provides Layer 2 connectivity, the 279 customer can run any Layer 3 protocols they choose. If the SP were 280 participating in customer routing, it would be vital that the 281 customer and SP both use the same Layer 3 protocol(s) and routing 282 protocols. 284 Note that IP-only Layer 2 interworking doesn't have this benefit as 285 it restricts the Layer 3 to IP only. 287 1.2.5. PE Scaling 289 In the Layer 2 VPN scheme described below, each PE transmits a single 290 small chunk of information about every CE that the PE is connected to 291 to every other PE. That means that each PE need only maintain a 292 single chunk of information from each CE in each VPN, and keep a 293 single "route" to every site in every VPN. This means that both the 294 Forwarding Information Base and the Routing Information Base scale 295 well with the number of sites and number of VPNs. Furthermore, the 296 scaling properties are independent of the customer: the only germane 297 quantity is the total number of VPN sites. 299 This is to be contrasted with Layer 3 VPNs, where each CE in a VPN 300 may have an arbitrary number of routes that need to be carried by the 301 SP. This leads to two issues. First, both the information stored at 302 each PE and the number of routes installed by the PE for a CE in a 303 VPN can be (in principle) unbounded, which means in practice that a 304 PE must restrict itself to installing routes associated with the VPNs 305 that it is currently a member of. Second, a CE can send a large 306 number of routes to its PE, which means that the PE must protect 307 itself against such a condition. Thus, the SP must enforce limits on 308 the number of routes accepted from a CE; this in turn requires the PE 309 router to offer such control. 311 The scaling issues of Layer 3 VPNs come into sharp focus at a BGP 312 route reflector (RR). An RR cannot keep all the advertised routes in 313 every VPN since the number of routes will be too large. The 314 following solutions/extensions are needed to address this issue: 316 1. RRs could be partitioned so that each RR services a subset of 317 VPNs so that no single RR has to carry all the routes. 319 2. An RR could use a preconfigured list of Route-Targets for its 320 inbound route filtering. The RR may choose to perform Route Target 321 Filtering, described in [RFC4684]. 323 1.2.6. Ease of Configuration 325 Configuring traditional Layer 2 VPNs with dense topologies was a 326 burden primarily because of the O(n*n) nature of the task. If there 327 are n CEs in a Frame Relay VPN, say full-mesh connected, n*(n-1)/2 328 DLCI PVCs must be provisioned across the SP network. At each CE, 329 (n-1) DLCIs must be configured to reach each of the other CEs. 330 Furthermore, when a new CE is added, n new DLCI PVCs must be 331 provisioned; also, each existing CE must be updated with a new DLCI 332 to reach the new CE. Finally, each PVC requires state in every 333 transit switch. 335 In our proposal, PVCs are tunnelled across the SP network. The 336 tunnels used are provisioned independently of the L2VPNs, using 337 signalling protocols (in case of MPLS, LDP or RSVP-TE can be used), 338 or set up by configuration; and the number of tunnels is independent 339 of the number of L2VPNs. This reduces a large part of the 340 provisioning burden. 342 Furthermore, we assume that DLCIs at the CE edge are relatively 343 cheap; and VPN labels in the SP network are cheap. This allows the 344 SP to "over-provision" VPNs: for example, allocate 50 CEs to a VPN 345 when only 20 are needed. With this over-provisioning, adding a new 346 CE to a VPN requires configuring just the new CE and its associated 347 PE; existing CEs and their PEs need not be re-configured. Note that 348 if DLCIs at the CE edge are expensive, e.g. if these DLCIs are 349 provisioned across a switched network, one could provision them as 350 and when needed, at the expense of extra configuration. This need 351 not still result in extra state in the SP network, i.e. an 352 intelligent implementation can allow overprovisioning of the pool of 353 VPN labels. 355 1.3. Advantages of Layer 3 VPNs 357 Layer 3 VPNs ([RFC4364] in particular) offer a good solution when the 358 customer traffic is wholly IP, customer routing is reasonably simple, 359 and the customer sites connect to the SP with a variety of Layer 2 360 technologies. 362 1.3.1. Layer 2 Independence 364 One major restriction in a Layer 2 VPN is that the Layer 2 media with 365 which the various sites of a single VPN connect to the SP must be 366 uniform. On the other hand, the various sites of a Layer 3 VPN can 367 connect to the SP with any supported media; for example, some sites 368 may connect with Frame Relay circuits, and others with Ethernet. 370 This restriction of Layer 2 VPN is alleviated by the IP-only Layer 2 371 interworking proposed in this document. This comes at the cost of 372 losing the Layer 3 independence. 374 A corollary to this is that the number of sites that can be in a 375 Layer 2 VPN is determined by the number of Layer 2 circuits that the 376 Layer 2 technology provides. For example, if the Layer 2 technology 377 is Frame Relay with 2-octet DLCIs, a CE can connect to at most about 378 a thousand other CEs in a VPN. 380 1.3.2. SP Routing as Added Value 382 Another problem with Layer 2 VPNs is that the CE router in a VPN must 383 be able to deal with having N routing peers, where N is the number of 384 sites in the VPN. This can be alleviated by manipulating the 385 topology of the VPN. For example, a hub-and-spoke VPN architecture 386 means that only one CE router (the hub) needs to deal with N 387 neighbors. However, in a Layer 3 VPN, a CE router need only deal 388 with one neighbor, the PE router. Thus, the SP can offer Layer 3 389 VPNs as a value-added service to its customers. 391 Moreover, with Layer 2 VPNs it is up to a customer to build and 392 operate the whole network. With Layer 3 VPNs, a customer is just 393 responsible for building and operating routing within each site, 394 which is likely to be much simpler than building and operating 395 routing for the whole VPN. That, in turn, makes Layer 3 VPNs more 396 suitable for customers who don't have sufficient routing expertise, 397 again allowing the SP to provide added value. 399 As mentioned later, multicast routing and forwarding is another 400 value-added service that an SP can offer. 402 1.3.3. Class-of-Service 404 Class-of-Service issues have been addressed for Layer 3 VPNs. Since 405 the PE router has visibility into the network Layer (IP), the PE 406 router can take on the tasks of CoS classification and routing. This 407 restriction on Layer 2 VPNs is again eased in the case of IP-only 408 Layer 2 interworking, as the PE router has visibility into the 409 network Layer (IP). 411 1.4. Multicast Routing 413 There are two aspects to multicast routing that we will consider. On 414 the protocol front, supporting IP multicast in a Layer 3 VPN requires 415 PE routers to participate in the multicast routing instance of the 416 customer, and thus keep some related state information. 418 In the Layer 2 VPN case, the CE routers run native multicast routing 419 directly. The SP network just provides pipes to connect the CE 420 routers; PEs are unaware whether the CEs run multicast or not, and 421 thus do not have to participate in multicast protocols or keep 422 multicast state information. 424 On the forwarding front, in a Layer 3 VPN, CE routers do not 425 replicate multicast packets; thus, the CE-PE link carries only one 426 copy of a multicast packet. Whether replication occurs at the 427 ingress PE, or somewhere within the SP network depends on the 428 sophistication of the Layer 3 VPN multicast solution. The simple 429 solution where a PE replicates packets for each of its CEs may place 430 considerable burden on the PE. More complex solutions may require 431 VPN multicast state in the SP network, but may significantly reduce 432 the traffic in the SP network by delaying packet replication until 433 needed. 435 In a Layer 2 VPN, packet replication occurs at the CE. This has the 436 advantage of distributing the burden of replication among the CEs 437 rather than focusing it on the PE to which they are attached, and 438 thus will scale better. However, the CE-PE link will need to carry 439 the multiple copies of multicast packets. In the case of Virtual 440 Private LAN Service (a specific type of L2 VPN; see [RFC4761]), 441 however, the CE-PE link need transport only one copy of a multicast 442 packet. 444 Thus, just as in the case of unicast routing, the SP has the choice 445 to offer a value-added service (multicast routing and forwarding) at 446 some cost (multicast state and packet replication) using a Layer 3 447 VPN, or to keep it simple and use a Layer 2 VPN. 449 1.5. Conventions used in this document 451 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 452 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 453 document are to be interpreted as described in [RFC2119]. 455 2. Contributors 457 The following contributed to this document. 459 Manoj Leelanivas, Juniper Networks 460 Quaizar Vohra, Juniper Networks 461 Javier Achirica, Consultant 462 Ronald Bonica, Juniper Networks 463 Dave Cooper, Global Crossing 464 Chris Liljenstolpe, Telstra 465 Eduard Metz, KPN Dutch Telecom 466 Hamid Ould-Brahim, Nortel 467 Chandramouli Sargor 468 Himanshu Shah, Ciena 469 Vijay Srinivasan 470 Zhaohui Zhang, Juniper Networks 472 3. Operation of a Layer 2 VPN 474 The following simple example of a customer with 4 sites connected to 475 3 PE routers in a Service Provider network will hopefully illustrate 476 the various aspects of the operation of a Layer 2 VPN. For 477 simplicity, we assume that a full-mesh topology is desired. 479 In what follows, Frame Relay serves as the Layer 2 media, and each CE 480 has multiple DLCIs to its PE, each to connect to another CE in the 481 VPN. If the Layer 2 media were ATM, then each CE would have multiple 482 VPI/VCIs to connect to other CEs. For PPP and Cisco HDLC, each CE 483 would have multiple physical interfaces to connect to other CEs. In 484 the case of IP-only Layer 2 interworking, each CE could have a mix of 485 one or more of the above Layer 2 media to connect to other CEs. 487 3.1. Network Topology 489 Consider a Service Provider network with edge routers PE0, PE1, and 490 PE2. Assume that PE0 and PE1 are IGP neighbors, and PE2 is more than 491 one hop away from PE0. 493 Suppose that a customer C has 4 sites S0, S1, S2 and S3 that C wants 494 to connect via the Service Provider's network using Frame Relay. 495 Site S0 has CE0 and CE1 both connected to PE0. Site S1 has CE2 496 connected to PE0. Site S2 has CE3 connected to PE1 and CE4 connected 497 to PE2. Site S3 has CE5 connected to PE2. (See Figure 1 below.) 498 Suppose further that C wants to "over-provision" each current site, 499 in expectation that the number of sites will grow to at least 10 in 500 the near future. However, CE4 is only provisioned with 9 DLCIs. 501 (Note that the signalling mechanism discussed in Section 4 will allow 502 a site to grow in terms of connectivity to other sites at a later 503 point of time at the cost of additional signalling, i.e., over- 504 provisioning is not a must but a recommendation). 506 Suppose finally that CE0 and CE2 have DLCIs 100 through 109 507 provisioned; CE1 and CE3 have DLCIs 200 through 209 provisioned; CE4 508 has DLCIs 107, 209, 265, 301, 414, 555, 654, 777 and 888 provisioned; 509 and CE5 has DLCIs 417-426. 511 S0 S3 512 .............. .............. 513 . . . . 514 . +-----+ . . . 515 . | CE0 |-----------+ . +-----+ . 516 . +-----+ . | . | CE5 | . 517 . . | . +--+--+ . 518 . +-----+ . | . | . 519 . | CE1 |-------+ | .......|...... 520 . +-----+ . | | / 521 . . | | / 522 .............. | | / 523 | | SP Network / 524 .....|...|.............................../..... 525 . | | / . 526 . +-+---+-+ +-------+ / . 527 . | PE0 |-------| P |-- | . 528 . +-+---+-+ +-------+ \ | . 529 . / \ \ +---+---+ . 530 . | -----+ --| PE2 | . 531 . | | +---+---+ . 532 . | +---+---+ / . 533 . | | PE1 | / . 534 . | +---+---+ / . 535 . | \ / . 536 ...|.............|.............../............. 537 | | / 538 | | / 539 | | / 540 S1 | | S2 / 541 .............. | ........|........../...... 542 . . | . | | . 543 . +-----+ . | . +--+--+ +--+--+ . 544 . | CE2 |-----+ . | CE3 | | CE4 | . 545 . +-----+ . . +-----+ +-----+ . 546 . . . . 547 .............. .......................... 549 Figure 1: Example Network Topology 551 3.2. Configuration 553 The following sub-sections detail the configuration that is needed to 554 provision the above VPN. For the purpose of exposition, we assume 555 that the customer will connect to the SP with Frame Relay circuits. 557 While we focus primarily on the configuration that an SP has to do, 558 we touch upon the configuration requirements of CEs as well. The 559 main point of contact in CE-PE configuration is that both must agree 560 on the DLCIs that will be used on the interface connecting them. 562 If the PE-CE connection is Frame Relay, it is recommended to run LMI 563 between the PE and CE. For the case of ATM VCs, OAM cells may be 564 used; for PPP and Cisco HDLC, keepalives may be used directly between 565 CEs; however, in this case, PEs would not have visibility as to the 566 liveness of customers circuits. 568 In case of IP-only Layer 2 interworking, if CE1, attached to PE0, 569 connects to CE3, attached to PE1, via a L2VPN circuit, the Layer 2 570 media between CE1 and PE0 is independent of the Layer 2 media between 571 CE3 and PE1. Each side will run its own Layer 2 specific link 572 management protocol, e.g., LMI, LCP, etc. PE0 will inform PE1 about 573 the status of its local circuit to CE1 via the circuit status vector 574 TLV defined in Section 4. Similarly PE1 will inform PE0 about the 575 status of its local circuit to CE3. 577 3.2.1. CE Configuration 579 Each CE that belongs to a VPN is given a "CE ID". CE IDs must be 580 unique in the context of a VPN. For the example, we assume that the 581 CE ID for CE-k is k. 583 Each CE is configured to communicate with its corresponding PE with 584 the set of DLCIs given above; for example, CE0 is configured with 585 DLCIs 100 through 109. In general, a CE is configured with a list of 586 circuits, all with the same Layer 2 encapsulation type, e.g., DLCIs, 587 VCIs, physical PPP interface etc. (IP-only Layer 2 interworking 588 allows a mix of Layer 2 encapsulation types). The size of this list/ 589 set determines the number of remote CEs a given CE can communicate 590 with. Denote the size of this list/set as the CE's range. A CE's 591 range must be at least the number of remote CEs that the CE will 592 connect to in a given VPN; if the range exceeds this, then the CE is 593 over-provisioned, in anticipation of growth of the VPN. 595 Each CE also "knows" which DLCI connects it to each other CE. The 596 methodology followed in this example is to use the CE ID of the other 597 CE as an index into the DLCI list this CE has (with zero-based 598 indexing, i.e., 0 is the first index). For example, CE0 is connected 599 to CE3 through its fourth DLCI, 103; CE4 is connected to CE2 by the 600 third DLCI in its list, namely 265. This is just the methodology 601 used in the example below; the actual methodology used to pick the 602 DLCI to be used is a local matter; the key factor is that CE-k may 603 communicate with CE-m using a different DLCI from the DLCI that CE-m 604 uses to communicate to CE-k, i.e., the SP network effectively acts as 605 a giant Frame Relay switch. This is very important, as it decouples 606 the DLCIs used at each CE site, making for much simpler provisioning. 608 3.2.2. PE Configuration 610 Each PE is configured with the VPNs in which it participates. Each 611 VPN is associated with one or more Route Target communities [RFC4360] 612 which serve to define the topology of the VPN. For each VPN, the PE 613 must determine a Route Distinguisher (RD) to use; this may either be 614 configured or chosen by the PE. RDs do not have to be unique across 615 the VPN. For each CE attached to the PE in a given VPN, the PE must 616 know the set of virtual circuits (DLCI, VCI/VPI or VLAN) connecting 617 it to the CE, and a CE ID identifying the CE within the VPN. CE IDs 618 must be unique in the context of a given VPN. 620 3.2.3. Adding a New Site 622 The first step in adding a new site to a VPN is to pick a new CE ID. 623 If all current members of the VPN are over-provisioned, i.e., their 624 range includes the new CE ID, adding the new site is a purely local 625 task. Otherwise, the sites whose range doesn't include the new CE ID 626 and wish to communicate directly with the new CE must have their 627 ranges increased by allocating additional local circuits to 628 incorporate the new CE ID. 630 The next step is ensuring that the new site has the required 631 connectivity. This usually requires adding a new virtual circuit 632 between the PE and CE; in most cases, this configuration is limited 633 to the PE in question. 635 The rest of the configuration is a local matter between the new CE 636 and the PE to which it is attached. 638 It bears repeating that the key to making additions easy is over- 639 provisioning and the algorithm for mapping a CE-id to a DLCI which is 640 used for connecting to the corresponding CE. However, what is being 641 over-provisioned is the number of DLCIs/VCIs that connect the CE to 642 the PE. This is a local matter between the PE and CE, and does not 643 affect other PEs or CEs. 645 4. PE Information Exchange 647 When a PE is configured with all the required information for a CE, 648 it advertises to other PEs the fact that it is participating in a VPN 649 via BGP messages, as per [RFC4761], section 3. BGP was chosen as the 650 means for exchanging L2 VPN information for two reasons: it offers 651 mechanisms for both auto-discovery and signaling, and allows for 652 operational convergence, as explained in Section 1. A bonus for 653 using BGP is a robust inter-AS solution for L2VPNs. 655 There are two modifications to the formating of messages. The first 656 is that the set of Encaps Types carried in the L2-info extended 657 community has been expanded to include those from Table 1. The value 658 of the Encaps Type field identifies the Layer 2 encapsulation, e.g., 659 ATM, Frame Relay etc. 661 +-----------+-------------------------------------------+-----------+ 662 | Encaps | Description | Reference | 663 | Type | | | 664 +-----------+-------------------------------------------+-----------+ 665 | 0 | Reserved | - | 666 | | | | 667 | 1 | Frame Relay | RFC 4446 | 668 | | | | 669 | 2 | ATM AAL5 SDU VCC transport | RFC 4446 | 670 | | | | 671 | 3 | ATM transparent cell transport | RFC 4816 | 672 | | | | 673 | 4 | Ethernet (VLAN) Tagged Mode | RFC 4448 | 674 | | | | 675 | 5 | Ethernet Raw Mode | RFC 4448 | 676 | | | | 677 | 6 | Cisco HDLC | RFC 4618 | 678 | | | | 679 | 7 | PPP | RFC 4618 | 680 | | | | 681 | 8 | SONET/SDH Circuit Emulation Service | RFC 4842 | 682 | | | | 683 | 9 | ATM n-to-one VCC cell transport | RFC 4717 | 684 | | | | 685 | 10 | ATM n-to-one VPC cell transport | RFC 4717 | 686 | | | | 687 | 11 | IP Layer 2 Transport | RFC 3032 | 688 | | | | 689 | 15 | Frame Relay Port mode | RFC 4619 | 690 | | | | 691 | 17 | Structure-agnostic E1 over packet | RFC 4553 | 692 | | | | 693 | 18 | Structure-agnostic T1 (DS1) over packet | RFC 4553 | 694 | | | | 695 | 19 | VPLS | RFC 4761 | 696 | | | | 697 | 20 | Structure-agnostic T3 (DS3) over packet | RFC 4553 | 698 | | | | 699 | 21 | Nx64kbit/s Basic Service using | RFC 5086 | 700 | | Structure-aware | | 701 | | | | 702 | 25 | Frame Relay DLCI | RFC 4619 | 703 | | | | 704 | 40 | Structure-agnostic E3 over packet | RFC 4553 | 705 | | | | 706 | 41 (1) | Octet-aligned payload for | RFC 4553 | 707 | | Structure-agnostic DS1 circuits | | 708 | | | | 709 | 42 (2) | E1 Nx64kbit/s with CAS using | RFC 5086 | 710 | | Structure-aware | | 711 | | | | 712 | 43 | DS1 (ESF) Nx64kbit/s with CAS using | RFC 5086 | 713 | | Structure-aware | | 714 | | | | 715 | 44 | DS1 (SF) Nx64kbit/s with CAS using | RFC 5086 | 716 | | Structure-aware | | 717 +-----------+-------------------------------------------+-----------+ 719 Table 1: Encaps Types 721 Note (1): Allocation of a separate code point for Encaps Type 722 eliminates the need for TDM payload size. 724 Note (2): Having separate code points for Encaps Types 42-44 allows 725 specifying the trunk framing (i.e, E1, T1 ESF or T1 SF) with CAS. 727 The second is the introduction of TLVs (Type-Length-Value triplets) 728 in the VPLS NLRI. L2VPN TLVs can be added to extend the information 729 carried in the NLRI, using the format shown in Figure 2. In L2VPN 730 TLVs, Type is 1 octet, Length is 2 octets and represents the size of 731 the Value field in bits. 733 0 1 2 3 734 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Type | Length | Value | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Value (continued, if needed) ... | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 Figure 2: Format of TLVs 743 +----------+-----------------------+ 744 | TLV Type | Description | 745 +----------+-----------------------+ 746 | 1 | Circuit Status Vector | 747 +----------+-----------------------+ 749 Table 2: TLV Types 751 4.1. Circuit Status Vector 753 This sub-TLV carries the status of a L2VPN PVC between a pair of PEs. 754 Note that a L2VPN PVC is bidirectional, composed of two simplex 755 connection going in opposite directions. A simplex connection 756 consists of the 3 segments: 1) the local access circuit between the 757 source CE and the ingress PE, 2) the tunnel LSP between the ingress 758 and egress PEs, and 3) the access circuit between the egress PE and 759 the destination CE. 761 To monitor the status of a PVC, a PE needs to monitor the status of 762 both simplex connections. Since it knows that status of its access 763 circuit, and the status of the tunnel towards the remote PE, it can 764 inform the remote PE of these two. Similarly, the remote PE can 765 inform the status of its access circuit to its local CE and the 766 status of the tunnel to the first PE. Combining the local and the 767 remote information, a PE can determine the status of a PVC. 769 The basic unit of advertisement in L2VPN for a given CE is a label- 770 block. Each label within a label-block corresponds to a PVC on the 771 CE. The local status information for all PVCs corresponding to a 772 label-block is advertised along with the NLRI for the label-block 773 using the status vector TLV. The Type field of this TLV is 1. The 774 Length field of the TLV specifies the length of the value field in 775 bits. The Value field of this TLV is a bit-vector, each bit of which 776 indicates the status of the PVC associated with the corresponding 777 label in the label-block. Bit value 0 corresponds to the PVC 778 associated with the first label in the label block, and indicates 779 that the local circuit and the tunnel LSP to the remote PE is up, 780 while a value of 1 indicates that either or both of them are down. 782 The Value field is padded to the nearest octet boundary. 784 If PE A receives an L2VPN NLRI, while selecting a label from a label- 785 block (advertised by PE B, for remote CE m, and VPN X) for one of its 786 local CE n (in VPN X) can also determine the status of the 787 corresponding PVC (between CE n and CE m) by looking at the 788 appropriate bit in the circuit status vector. 790 4.2. Generalizing the VPN Topology 792 In the above, we assumed for simplicity that the VPN was a full mesh. 793 To allow for more general VPN topologies, a mechanism based on 794 filtering on BGP extended communities can be used (see Section 4). 796 5. Layer 2 Interworking 798 As defined so far in this document, all CE-PE connections for a given 799 Layer 2 VPN must use the same Layer 2 encapsulation, e.g., they must 800 all be Frame Relay. This is often a burdensome restriction. One 801 answer is to use an existing Layer 2 interworking mechanism, for 802 example, Frame Relay-ATM interworking. 804 In this document, we take a different approach: we postulate that the 805 network Layer is IP, and base Layer 2 interworking on that. Thus, 806 one can choose between pure Layer 2 VPNs, with a stringent Layer 2 807 restriction but with Layer 3 independence, or a Layer 2 interworking 808 VPNs, where there is no restriction on Layer 2, but Layer 3 must be 809 IP. Of course, a PE may choose to implement Frame Relay-ATM 810 interworking. For example, an ATM Layer 2 VPN could have some CEs 811 connect via Frame Relay links, if their PE could translate Frame 812 Relay to ATM transparent to the rest of the VPN. This would be 813 private to the CE-PE connection, and such a course is outside the 814 scope of this document. 816 For Layer 2 interworking as defined here, when an IP packet arrives 817 at a PE, its Layer 2 address is noted, then all Layer 2 overhead is 818 stripped, leaving just the IP packet. Then, a VPN label is added, 819 and the packet is encapsulated in the PE-PE tunnel (as required by 820 the tunnel technology). Finally, the packet is forwarded. Note that 821 the forwarding decision is made on the basis of the Layer 2 822 information, not the IP header. At the egress, the VPN label 823 determines to which CE the packet must be sent, and over which 824 virtual circuit; from this, the egress PE can also determine the 825 Layer 2 encapsulation to place on the packet once the VPN label is 826 stripped. 828 An added benefit of restricting interworking to IP only as the Layer 829 3 technology is that the provider's network can provide IP Diffserv 830 or any other IP based QOS mechanism to the L2VPN customer. The 831 ingress PE can set up IP/TCP/UDP based classifiers to do DiffServ 832 marking, and other functions like policing and shaping on the L2 833 circuits of the VPN customer. Note the division of labor: the CE 834 determines the destination CE, and encodes that in the Layer 2 835 address. The ingress PE thus determines the egress PE and VPN label 836 based on the Layer 2 address supplied by the CE, but the ingress PE 837 can choose the tunnel to reach the egress PE (in the case that there 838 are different tunnels for each CoS/DiffServ code point), or the CoS 839 bits to place in the tunnel (in the case where a single tunnel 840 carries multiple CoS/DiffServ code points) based on its own 841 classification of the packet. 843 6. Packet Transport 845 When a packet arrives at a PE from a CE in a Layer 2 VPN, the Layer 2 846 address of the packet identifies to which other CE the packet is 847 destined. The procedure outlined above installs a route that maps 848 the Layer 2 address to a tunnel (which identifies the PE to which the 849 destination CE is attached) and a VPN label (which identifies the 850 destination CE). If the egress PE is the same as the ingress PE, no 851 tunnel or VPN label is needed. 853 The packet may then be modified (depending on the Layer 2 854 encapsulation). In case of IP-only Layer 2 interworking, the Layer 2 855 header is completely stripped off till the IP header. Then, a VPN 856 label and tunnel encapsulation are added as specified by the route 857 described above, and the packet is sent to the egress PE. 859 If the egress PE is the same as the ingress, the packet "arrives" 860 with no labels. Otherwise, the packet arrives with the VPN label, 861 which is used to determine which CE is the destination CE. The 862 packet is restored to a fully-formed Layer 2 packet, and then sent to 863 the CE. 865 6.1. Layer 2 MTU 867 This document requires that the Layer 2 MTU configured on all the 868 access circuits connecting CEs to PEs in a L2VPN be the same. This 869 can be ensured by passing the configured Layer 2 MTU in the Layer2- 870 info extended community when advertising L2VPN label-blocks. On 871 receiving L2VPN label-block from remote PEs in a VPN, the MTU value 872 carried in the Layer2-info extendend community should be compared 873 against the configured value for the VPN. If they don't match, then 874 the label-block should be ignored. 876 The MTU on the Layer 2 access links MUST be chosen such that the size 877 of the L2 frames plus the L2VPN header does not exceed the MTU of the 878 SP network. Layer 2 frames that exceed the MTU after encapsulation 879 MUST be dropped. For the case of IP-only Layer 2 interworking the IP 880 MTU on the Layer 2 access link must be chosen such that the size of 881 the IP packet and the L2VPN header does not exceed the MTU of the SP 882 network. 884 6.2. Layer 2 Frame Format 886 The modification to the Layer 2 frame depends on the Layer 2 type. 887 This document requires that the encapsulation methods used in 888 transporting of Layer 2 frames over tunnels be the same as described 889 in [RFC4448], [RFC4618], [RFC4619], and [RFC4717], except in the case 890 of IP-only Layer 2 Interworking which is described next. 892 6.3. IP-only Layer 2 Interworking 894 +-----------------------------------+ 895 | PSN Transport | VPN | IP | VPN label is the 896 | Header | Label | Packet | demultiplexing field 897 +-----------------------------------+ 899 Figure 3: Format of IP-only Layer 2 interworking packet 901 At the ingress PE, an L2 frame's L2 header is completely stripped off 902 and is carried over as an IP packet within the SP network (Figure 3). 903 The forwarding decision is still based on the L2 address of the 904 incoming L2 frame. At the egress PE, the IP packet is encapsulated 905 back in an L2 frame and transported over to the destination CE. The 906 forwarding decision at the egress PE is based on the VPN label as 907 before. The L2 technology between egress PE and CE is independent of 908 the L2 technology between ingress PE and CE. 910 7. Security Considerations 912 RFC 4761, on which this document is based, has a detailed discussion 913 of security considerations. As in RFC 4761, the focus here is the 914 privacy of customer VPN data (as opposed to confidentiality, 915 integrity, or authentication of said data); to achieve the latter, 916 one can use the methods suggested in RFC 4761. The techniques 917 described in RFC 4761 for securing the control plane and protecting 918 the forwarding path apply equally to L2 VPNs, as do the remarks 919 regarding multi-AS operation. The mitigation strategies and the 920 analogies with [RFC4364] also apply here. 922 RFC 4761 perhaps should have discussed Denial of Service attacks 923 based on the fact that VPLS PEs have to learn MAC addresses and 924 replicate packets (for flooding and multicast). However, those 925 considerations don't apply here, as neither of those actions are 926 required of PEs implementing the procedures in this document. 928 8. Acknowledgments 930 The authors would like to thank Chaitanya Kodeboyina, Dennis 931 Ferguson, Der-Hwa Gan, Dave Katz, Nischal Sheth, John Stewart, and 932 Paul Traina for the enlightening discussions that helped shape the 933 ideas presented here, and Ross Callon for his valuable comments. 935 The idea of using extended communities for more general connectivity 936 of a Layer 2 VPN was a contribution by Yakov Rekhter, who also gave 937 many useful comments on the text; many thanks to him. 939 9. IANA Considerations 941 IANA is requested to create two new registries: the first is for the 942 one-octet Encaps Type field of the L2-info extended community. The 943 name of the registry is "BGP L2 Encapsulation Types"; the values 944 already allocated are in Table 1 of Section 4. The allocation policy 945 for new entries up to and including value 127 is "Expert Review". 946 The allocation policy for values 128 through 251 is "First Come First 947 Served". The values from 252 through 255 are for "Experimental Use". 949 The second registry is for the one-octet Type field of the TLVs of 950 the L2VPN NLRI. The name of the registry is "BGP L2 TLV Types"; the 951 sole allocated value is in Table 2 of Section 4. The allocation 952 policy for new entries up to and including value 127 is "Expert 953 Review". The allocation policy for values 128 through 251 is "First 954 Come First Served". The values from 252 through 255 are for 955 "Experimental Use". 957 10. References 959 10.1. Normative References 961 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 962 Requirement Levels", BCP 14, RFC 2119, March 1997. 964 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 965 Communities Attribute", RFC 4360, February 2006. 967 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 968 Networks (VPNs)", RFC 4364, February 2006. 970 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 971 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 973 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 974 "Encapsulation Methods for Transport of Ethernet over MPLS 975 Networks", RFC 4448, April 2006. 977 [RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, 978 "Encapsulation Methods for Transport of PPP/High-Level 979 Data Link Control (HDLC) over MPLS Networks", RFC 4618, 980 September 2006. 982 [RFC4619] Martini, L., Kawa, C., and A. Malis, "Encapsulation 983 Methods for Transport of Frame Relay over Multiprotocol 984 Label Switching (MPLS) Networks", RFC 4619, 985 September 2006. 987 [RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., 988 Brayley, J., and G. Koleyni, "Encapsulation Methods for 989 Transport of Asynchronous Transfer Mode (ATM) over MPLS 990 Networks", RFC 4717, December 2006. 992 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 993 (VPLS) Using BGP for Auto-Discovery and Signaling", 994 RFC 4761, January 2007. 996 10.2. Informative References 998 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 999 Edge (PWE3) Architecture", RFC 3985, March 2005. 1001 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1002 Heron, "Pseudowire Setup and Maintenance Using the Label 1003 Distribution Protocol (LDP)", RFC 4447, April 2006. 1005 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 1006 R., Patel, K., and J. Guichard, "Constrained Route 1007 Distribution for Border Gateway Protocol/MultiProtocol 1008 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 1009 Private Networks (VPNs)", RFC 4684, November 2006. 1011 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 1012 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 1013 RFC 4762, January 2007. 1015 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 1016 "Provisioning, Auto-Discovery, and Signaling in Layer 2 1017 Virtual Private Networks (L2VPNs)", RFC 6074, 1018 January 2011. 1020 [Kosiur] Kosiur, D., "Building and Managing Virtual Private 1021 Networks", November 1996. 1023 Authors' Addresses 1025 Kireeti Kompella 1026 Juniper Networks 1027 1194 N. Mathilda Ave. 1028 Sunnyvale, CA 94089 1029 US 1031 Email: kireeti@juniper.net 1033 Bhupesh Kothari 1034 Cisco Systems 1035 3750 Cisco Way 1036 San Jose, CA 95134 1037 USA 1039 Email: bhupesh@cisco.com 1041 Rao Cherukuri 1042 Juniper Networks 1043 1194 N. Mathilda Ave. 1044 Sunnyvale, CA 94089 1045 US 1047 Email: cherukuri@juniper.net