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