idnits 2.17.1 draft-ietf-l2vpn-vpls-bgp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 2004) is 7404 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '1' is mentioned on line 53, but not defined == Missing Reference: '2' is mentioned on line 63, but not defined == Missing Reference: '3' is mentioned on line 382, but not defined == Missing Reference: '4' is mentioned on line 74, but not defined == Missing Reference: '5' is mentioned on line 80, but not defined == Missing Reference: '6' is mentioned on line 289, but not defined == Missing Reference: '7' is mentioned on line 486, but not defined == Missing Reference: '8' is mentioned on line 256, but not defined == Missing Reference: '9' is mentioned on line 257, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-05 ** Obsolete normative reference: RFC 2385 (ref. '11') (Obsoleted by RFC 5925) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella (Editor) 3 Internet Draft Y. Rekhter (Editor) 4 Category: Standards Track Juniper Networks 5 Expires: July 2004 January 2004 6 draft-ietf-l2vpn-vpls-bgp-01.txt 8 Virtual Private LAN Service 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 Virtual Private LAN Service (VPLS), also known as Transparent LAN 38 Service, and Virtual Private Switched Network service, is a useful 39 Service Provider offering. The service offered is a Layer 2 Virtual 40 Private Network (VPN); however, in the case of VPLS, the customers in 41 the VPN are connected by a multipoint network, in contrast to the 42 usual Layer 2 VPNs, which are point-to-point in nature. 44 This document describes the functions required to offer VPLS, and 45 describes a mechanism for signaling a VPLS, as well as for forwarding 46 VPLS frames across a packet switched network. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [1]. 54 1. Introduction 56 Virtual Private LAN Service (VPLS), also known as Transparent LAN 57 Service, and Virtual Private Switched Network service, is a useful 58 service offering. A Virtual Private LAN appears in (almost) all 59 respects as a LAN to customers of a Service Provider. However, in a 60 VPLS, the customers are not all connected to a single LAN; the 61 customers may be spread across a metro or wide area. In essence, a 62 VPLS glues several individual LANs across a packet-switched network 63 to appear and function as a single LAN [2]. 65 This document describes the functions needed to offer VPLS, and goes 66 on to describe a mechanism for signaling a VPLS, as well as a 67 mechanism for transport of VPLS frames over tunnels across a packet 68 switched network. The signaling mechanism uses BGP as the control 69 plane protocol. This document also briefly discusses deployment 70 options, in particular, the notion of decoupling functions across 71 devices. 73 Alternative approaches include: [3], which allows one to build a 74 Layer 2 VPN with Ethernet as the interconnect; and [4], which allows 75 one to set up an Ethernet connection across a packet-switched 76 network. Both of these, however, offer point-to-point Ethernet 77 services. What distinguishes VPLS from the above two is that a VPLS 78 offers a multipoint service. A mechanism for setting up pseudowires 79 for VPLS using the Label Distribution Protocol (LDP) is defined in 80 [5]. 82 1.1. Scope of this Document 84 This document has four major parts: defining a VPLS functional model; 85 defining a control plane for setting up VPLS; defining the data plane 86 for VPLS (encapsulation and forwarding of data); and defining various 87 deployment scenarios. 89 The functional model underlying VPLS is laid out in section 2. This 90 describes the service being offered, the network components that 91 interact to provide the service, and at a high level their 92 interactions. 94 The control plane described here (section 3) uses Multiprotocol BGP 96 [6] to establish VPLS service, i.e., for the autodiscovery of VPLS 97 members and for the setup and teardown of the pseudowires that 98 constitute a given VPLS. Section 3 also describes how a VPLS that 99 spans Autonomous System boundaries is set up, as well as how 100 multi-homing is handled. Using BGP as the control plane for VPNs is 101 not new (see [3], [7] and [8]): what is described here is based on 102 the mechanisms proposed in [7]. 104 The forwarding plane and the actions that a participating PE must 105 take is described in section 4. 107 In section 5, the notion of 'decoupled' operation is defined, and the 108 interaction of decoupled and non-decoupled PEs is described. 109 Decoupling allows for more flexible deployment of VPLS. 111 2. Functional Model 113 This will be described with reference to Figure 1. 115 Figure 1: Example of a VPLS 116 ----- 117 / A1 \ 118 ---- ____CE1 | 119 / \ -------- -------- / | | 120 | A2 CE2- / \ / PE1 \ / 121 \ / \ / \___/ | \ ----- 122 ---- ---PE2 | \ 123 | | \ ----- 124 | Service Provider Network | \ / \ 125 | | CE5 A5 | 126 | ___ | / \ / 127 |----| \ / \ PE4_/ ----- 128 |L2PE|--PE3 / \ / 129 |----| -------- ------- 130 ---- / | ---- 131 / \/ \ / \ CE = Customer Edge Device 132 | A3 CE3 --CE4 A4 | PE = Provider Edge Router 133 \ / \ / L2PE = Layer 2 Aggregation 134 ---- ---- 136 2.1. Terminology 138 Terminology similar to that in [7] is used, with the addition of 139 "L2PE", a Layer 2 PE device used for Layer 2 aggregation. An L2PE is 140 owned and operated by the Service Provider (as is the PE). PE and 141 L2PE devices are "VPLS-aware", which means that they know that a VPLS 142 service is being offered. We will call these VPLS edge devices, 143 which could be either a PE or an L2PE, a VE. 145 In contrast, the CE device (which may be owned and operated by either 146 the SP or the customer) is VPLS-unaware; as far as the CE is 147 concerned, it is connected to the other CEs in the VPLS via a Layer 2 148 switched network. This means that there should be no changes to a CE 149 device, either to the hardware or the software, in order to offer 150 VPLS. 152 A CE device may be connected to a PE or an L2PE via Layer 2 switches 153 that are VPLS-unaware. From a VPLS point of view, such Layer 2 154 switches are invisible, and hence will not be discussed further. 155 Furthermore, an L2PE may be connected to a PE via Layer 2 and Layer 3 156 devices; this will be discussed further in a later section. 158 The term "demultiplexor" refers to an identifier in a data packet 159 that identifies both the VPLS to which the packet belongs as well as 160 the ingress PE. In this document, the demultiplexor is an MPLS 161 label. 163 The term "VPLS" will refer to the service as well as a particular 164 instantiation of the service (i.e., an emulated LAN); it should be 165 clear from the context which usage is intended. 167 2.2. Assumptions 169 The Service Provider Network is a packet switched network. The PEs 170 are assumed to be (logically) full-meshed with tunnels over which 171 packets that belong to a service (such as VPLS) are encapsulated and 172 forwarded. These tunnels can be IP tunnels, such as GRE, or MPLS 173 tunnels, established by RSVP-TE or LDP. These tunnels are 174 established independently of the services offered over them; the 175 signaling and establishment of these tunnels are not discussed in 176 this document. 178 "Flooding" and MAC address "learning" (see section 4) are an integral 179 part of VPLS. However, these activities are private to an SP device, 180 i.e., in the VPLS described below, no SP device requests another SP 181 device to flood packets or learn MAC addresses on its behalf. 183 All the PEs participating in a VPLS are assumed to be fully meshed, 184 i.e., every (ingress) PE can send a VPLS packet to the egress PE(s) 185 directly, without the need for an intermediate PE (see the section 186 below on "Split Horizon" Flooding). This assumption reduces (but 187 does not eliminate) the need to run Spanning Tree Protocol among the 188 PEs. 190 2.3. Interactions 192 VPLS is a successful "LAN Service" if CE devices that belong to VPLS 193 V can interact through the SP network as if they were connected by a 194 LAN. VPLS is "private" if CE devices that belong to different VPLSs 195 cannot interact. VPLS is "virtual" if multiple VPLSs can be offered 196 over a common packet switched network. 198 PE devices interact to "discover" all the other PEs participating in 199 the same VPLS (i.e., that are attached to CE devices that belong to 200 the same VPLS), and to exchange demultiplexors. These interactions 201 are control-driven, not data-driven. 203 L2PEs interact with PEs to establish connections with remote PEs or 204 L2PEs in the same VPLS. Again, this interaction is control-driven. 206 3. Control Plane 208 There are two primary functions of the VPLS control plane: 209 autodiscovery, and setup and teardown of the pseudowires that 210 constitute the VPLS, often called signaling. The first two 211 subsections describe these functions. The next subsection describes 212 the setting up of pseudowires that span Autonomous Systems. The last 213 subsection details how multi-homing is handled. 215 3.1. Autodiscovery 217 Autodiscovery refers to the process of finding all the PEs that 218 participate in a given VPLS. A PE can either be configured with the 219 identities of all the other PEs in a given VPLS, or the PE can 220 autodiscover the other PEs. 222 The former approach is fairly configuration-intensive, especially 223 since it is required (in this and other VPLS approaches) that the PEs 224 participating in a given VPLS are fully meshed (i.e., every pair of 225 PEs in a given VPLS establish pseudowires to each other). 226 Furthermore, when the topology of a VPLS changes (i.e., a PE is added 227 to, or removed from the VPLS), the VPLS configuration on all PEs in 228 that VPLS must be changed. 230 In the autodiscovery approach, each PE "discovers" which other PEs 231 are part of a given VPLS by means of some protocol, in this case BGP. 232 This allows each PE's configuration to consist only of the identity 233 of the VPLS that each customer belongs to, not the identity of every 234 other PE in that VPLS. Moreover, when the topology of a VPLS 235 changes, only the affected PE's configuration changes; other PEs 236 automatically find out about the change and adapt. 238 3.1.1. Functions 240 A PE that participates in a given VPLS V must be able to tell all 241 other PEs in VPLS V that it is also a member of V. A PE must also 242 have a means of declaring that it no longer participates in a VPLS. 243 To do both of these, the PE must have a means of identifying a VPLS 244 and a means by which to communicate to all other PEs. 246 L2PE devices also need to know what constitutes a given VPLS; 247 however, they don't need the same level of detail. The PE (or PEs) 248 to which an L2PE is connected gives the L2PE an abstraction of the 249 VPLS; this is described in section 5. 251 3.1.2. Protocol Specification 253 The specific mechanism for autodiscovery described here is based on 254 [3] and [7]; it uses BGP extended communities [9] to identify members 255 of a VPLS. A more generic autodiscovery mechanism is described in 256 [8]. The specific extended community used is the Route Target, whose 257 format is described in [9]. The semantics of the use of Route 258 Targets is described in [7]; their use in VPLS is identical. 260 As it has been assumed that VPLSs are fully meshed, a single Route 261 Target RT suffices for a given VPLS V, and in effect that RT is the 262 identifier for VPLS V. 264 A PE announces (typically via I-BGP) that it belongs to VPLS V by 265 annotating its NLRIs for V (see next subsection) with Route Target 266 RT, and acts on this by accepting NLRIs from other PEs that have 267 Route Target RT. A PE announces that it no longer participates in V 268 by withdrawing all NLRIs that it had advertised with Route Target RT. 270 3.2. Signaling 272 Once discovery is done, each pair of PEs in a VPLS must be able to 273 establish (and tear down) pseudowires to each other, i.e., exchange 274 (and withdraw) demultiplexors. This process is known as signaling. 275 Signaling is also used to initiate "relearning", and to transmit 276 certain characteristics of the PE regarding a given VPLS. 278 Recall that a demultiplexor is used to distinguish among several 279 different streams of traffic carried over a tunnel, each stream 280 possibly representing a different service. In the case of VPLS, the 281 demultiplexor not only says to which specific VPLS a packet belongs, 282 but also identifies the ingress PE. The former information is used 283 for forwarding the packet; the latter information is used for 284 learning MAC addresses. The demultiplexor described here is an MPLS 285 label, even though the PE-to-PE tunnels may not be MPLS tunnels. 287 3.2.1. Setup and Teardown 289 The VPLS BGP NLRI described below, with a new AFI and SAFI (see [6]) 290 is used to exchange demultiplexors. 292 A PE advertises a VPLS NLRI for each VPLS that it participates in. 293 If the PE is doing learning and flooding, i.e., it is the VE, it 294 announces a single set of VPLS NLRIs for each VPLS that it is in. If 295 the PE is connected to several L2PEs, it announces one set of VPLS 296 NLRIs for each L2PE. A hybrid scheme is also possible, where the PE 297 learns MAC addresses on some interfaces (over which it is directly 298 connected to CEs) and delegates learning on other interfaces (over 299 which it is connected to L2PEs). In this case, the PE would announce 300 one set of VPLS NLRIs for each L2PE that has customer ports in a 301 given VPLS, and one set for itself, if it has customer ports in that 302 VPLS. 304 Each set of NLRIs defines the demultiplexors for a range of other PEs 305 in the VPLS. Ideally, a single NLRI suffices to cover all PEs in a 306 VPLS; however, there are cases (such as a newly added PE) where the 307 pre-existing NLRI does not have enough labels. In such cases, 308 advertising an additional NLRI for the same VPLS serves to add labels 309 for the new PEs without disrupting service to the pre-existing PEs. 310 If service disruption is acceptable (or when the PE restarts its BGP 311 process), a PE MAY consider coalescing all NLRIs for a VPLS into a 312 single NLRI. 314 If a PE X is part of VPLS V, and X receives a VPLS NLRI for V from PE 315 Y that includes a demultiplexor that X can use, X sets up its ends of 316 a pair of pseudowires between X and Y. X may also have to advertise 317 a new NLRI for V that includes a demultiplexor that Y can use, if its 318 pre-existing NLRI for V did not include a demultiplexor for Y. 320 If Y's configuration is changed to remove it from VPLS V, or all its 321 links to CEs in V go down, then Y SHOULD withdraw all its NLRIs for 322 V. 324 If Y withdraws an NLRI for V that X was using, then X tears down its 325 ends of the pseudowires between X and Y. 327 The format of the VPLS NLRI is given below. The AFI and SAFI are the 328 same as for the L2 VPN NLRI [3]. 330 Figure 2: BGP NLRI for VPLS Information 332 +------------------------------------+ 333 | Length (2 octets) | 334 +------------------------------------+ 335 | Route Distinguisher (8 octets) | 336 +------------------------------------+ 337 | VE ID (2 octets) | 338 +------------------------------------+ 339 | VE Block Offset (2 octets) | 340 +------------------------------------+ 341 | VE Block Size (2 octets) | 342 +------------------------------------+ 343 | Label Base (3 octets) | 344 +------------------------------------+ 346 3.2.2. Signaling PE Capabilities 348 The Encaps Type and Control Flags are encoded in an extended 349 attribute. The community type also is used in L2 VPNs [3]. 351 There is a new Encaps Type for VPLS (TBD). 353 Figure 3: layer2-info extended community 355 +------------------------------------+ 356 | Extended community type (2 octets) | 357 +------------------------------------+ 358 | Encaps Type (1 octet) | 359 +------------------------------------+ 360 | Control Flags (1 octet) | 361 +------------------------------------+ 362 | Layer-2 MTU (2 octet) | 363 +------------------------------------+ 364 | Reserved (2 octets) | 365 +------------------------------------+ 367 There are three new control flags, Q, F and P defined for VPLS. Q 368 says whether qualified learning occurs (1) or not (0); F which says 369 whether the PE is capable of flooding (1) or not (0). P indicates 370 that the PE will strip the outermost VLAN from the layer 2 customer 371 frame on ingress, and push a VLAN on egress. 373 Figure 4: Control Flags Bit Vector 375 0 1 2 3 4 5 6 7 376 +-+-+-+-+-+-+-+-+ 377 | MBZ |P|Q|F|C|S| (MBZ = MUST Be Zero) 378 +-+-+-+-+-+-+-+-+ 380 3.3. Multi-AS VPLS 382 As in [3] and [7], the above autodiscovery and signaling functions 383 are typically announced via I-BGP. This assumes that all the sites 384 in a VPLS are connected to PEs in a single Autonomous System (AS). 386 However, sites in a VPLS may connect to PEs in different ASes. This 387 leads to two issues: 1) there would not be an I-BGP connection 388 between those PEs, so some means of signaling across ASes may be 389 needed; and 2) there may not be PE-to-PE tunnels between the ASes. 391 A similar problem is solved in [7], Section 10. Three methods are 392 suggested to address issue (1); all these methods have analogs in 393 multi-AS VPLS. 395 Here is a diagram for reference: 397 __________ ____________ ____________ __________ 398 / \ / \ / \ / \ 399 \___/ AS 1 \ / AS 2 \___/ 400 \ / 401 +-----+ +-------+ | +-------+ +-----+ 402 | PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 | 403 +-----+ +-------+ | +-------+ +-----+ 404 ___ / \ ___ 405 / \ / \ / \ 406 \__________/ \____________/ \____________/ \__________/ 408 a) VPLS-to-VPLS connections at the AS border routers. 410 In this method, an AS Border Router (ASBR1) acts as a PE for all 411 VPLSs that span AS1 and an AS to which ASBR1 is connected, such as 412 AS2 here. The ASBR on the neighboring AS (ASBR2) is viewed by 413 ASBR1 as a CE for the VPLSs that span AS1 and AS2; similarly, 414 ASBR2 acts as a PE for this VPLS from AS2's point of view, and 415 views ASBR1 as a CE. 417 This method does not require MPLS on the ASBR1-ASBR2 link, but 418 does require that this link carry Ethernet traffic, and that there 419 be a separate VLAN sub-interface for each VPLS traversing this 420 link. It further requires that ASBR1 does the PE operations 421 (discovery, signaling, MAC address learning, flooding, 422 encapsulation, etc.) for all VPLSs that traverse ASBR1. This 423 imposes a significant burden on ASBR1, both on the control plane 424 and the data plane, which limits the number of multi-AS VPLSs. 426 Note that in general, there will be multiple connections between a 427 pair of ASes, for redundancy. In this case, the Spanning Tree 428 Protocol must be run on each VPLS that spans these ASes, so that a 429 loop-free topology can be constructed in each VPLS. This imposes 430 a further burden on the ASBRs and PEs participating in those 431 VPLSs, as these devices would need to run the Spanning Tree 432 Protocol for each such VPLS.. 434 b) EBGP redistribution of VPLS information between ASBRs. 436 This method requires I-BGP peerings between the PEs in AS1 and 437 ASBR1 in AS1 (perhaps via route reflectors), an E-BGP peering 438 between ASBR1 and ASBR2 in AS2, and I-BGP peerings between ASBR2 439 and the PEs in AS2. In the above example, PE1 sends a VPLS NLRI 440 to ASBR1 with a label block and itself as the BGP nexthop; ASBR1 441 sends the NLRI to ASBR2 with new labels and itself as the BGP 442 nexthop; and ASBR2 sends the NLRI to PE2 with new labels and 443 itself as the nexthop. 445 The VPLS NLRI that ASBR1 sends to ASBR2 (and the NLRI that ASBR2 446 sends to PE2) is identical to the VPLS NLRI that PE1 sends to 447 ASBR1, except for the label block. To be precise, the Length, the 448 Route Distinguisher, the VE ID, the VE Block Offset, and the VE 449 Block Size MUST be the same; the Label Base may be different. 450 Furthermore, ASBR1 must also update its forwarding path as 451 follows: if the Label Base sent by PE1 is L1, the Label-block Size 452 is N, the Label Base sent by ASBR1 is L2, and the tunnel label 453 from ASBR1 to PE1 is T, then ASBR1 must install the following in 454 the forwarding path: 455 swap L2 with L1 and push T, 456 swap L2+1 with L1+1 and push T, 457 ... 458 swap L2+N-1 with L1+N-1 and push T. 460 ASBR2 must act similarly, except that it may not need a tunnel 461 label if it is directly connected with ASBR1. 463 When PE2 wants to send a VPLS packet to PE1, PE2 uses its VE ID to 464 get the right VPLS label from ASBR2's label block for PE1, and 465 uses a tunnel label to reach ASBR2. ASBR2 swaps the VPLS label 466 with the label from ASBR1; ASBR1 then swaps the VPLS label with 467 the label from PE1, and pushes a tunnel label to reach PE1. 469 In this method, one needs MPLS on the ASBR1-ASBR2 interface, but 470 there is no requirement that the link layer be Ethernet. 471 Furthermore, the ASBRs take part in distributing VPLS information. 472 However, the data plane requirements of the ASBRs is much simpler 473 than in method (a), being limited to label operations. Finally, 474 the construction of loop-free VPLS topologies is done by routing 475 decisions, viz. BGP path and nexthop selection, so there is no 476 need to run the Spanning Tree Protocol on a per-VPLS basis. Thus, 477 this method is considerably more scalable than method (a). 479 c) Multi-hop EBGP redistribution of VPLS information between ASes. 481 In this method, there is a multi-hop E-BGP peering between the PEs 482 (or preferably, a Route Reflector) in AS1 and the PEs (or Route 483 Reflector) in AS2. PE1 sends a VPLS NLRI with labels and nexthop 484 self to PE2; if this is via route reflectors, the BGP nexthop is 485 not changed. This requires that there be a tunnel LSP from PE1 to 486 PE2. This tunnel LSP can be created exactly as in [7], section 10 487 (c), for example using E-BGP to exchange labeled IPv4 routes for 488 the PE loopbacks. 490 When PE1 wants to send a VPLS packet to PE2, it pushes the VPLS 491 label corresponding to its own VE ID onto the packet. It then 492 pushes the tunnel label(s) to reach PE2. 494 This method requires no VPLS information (in either the control or 495 the data plane) on the ASBRs. The ASBRs only need to set up 496 PE-to-PE tunnel LSPs in the control plane, and do label operations 497 in the data plane. Again, as in the case of method (b), the 498 construction of loop-free VPLS topologies is done by routing 499 decisions, i.e., BGP path and nexthop selection, so there is no 500 need to run the Spanning Tree Protocol on a per-VPLS basis. This 501 option is likely to be the most scalable of the three methods 502 presented here. 504 In order to ease the allocation of VE IDs for a VPLS that spans 505 multiple ASes, one can allocate ranges for each AS. For example, AS1 506 uses VE IDs in the range 1 to 100, AS2 from 101 to 200, etc. If 507 there are 10 sites attached to AS1 and 20 to AS2, the allocated VE 508 IDs could be 1-10 and 101 to 120. This minimizes the number of VPLS 509 NLRIs that are exchanged while ensuring that VE IDs are kept unique. 511 In the above example, if AS1 needed more than 100 sites, then another 512 range can be allocated to AS1. The only caveat is that there is no 513 overlap between VE ID ranges among ASes. The exception to this rule 514 is multi-homing, which is dealt with below. 516 3.4. Multi-homing and Path Selection 518 It is often desired to multi-home a VPLS site, i.e., to connect it to 519 multiple PEs, perhaps even in different ASes. In such a case, the 520 PEs connected to the same site can either be configured with the same 521 VE ID or with different VE IDs. In the latter case, it is mandatory 522 to run STP on the CE device, and possibly on the PEs, to construct a 523 loop-free VPLS topology. 525 In the case where the PEs connected to the same site are assigned the 526 same VE ID, a loop-free topology is constructed by routing 527 mechanisms, in particular, by BGP path selection. When a BGP speaker 528 receives two equivalent NLRIs (see below for the definition), it 529 applies standard path selection criteria such as Local Preference and 530 AS Path Length to determine which NLRI to choose; it MUST pick only 531 one. If the chosen NLRI is subsequently withdrawn, the BGP speaker 532 applies path selection to the remaining equivalent VPLS NLRIs to pick 533 another; if none remain, the forwarding information associated with 534 that NLRI is removed. 536 Two VPLS NLRIs are considered equivalent from a path selection point 537 of view if the Route Distinguisher, the VE ID and the VE Block Offset 538 are the same. If two PEs are assigned the same VE ID in a given 539 VPLS, they MUST use the same Route Distinguisher, and they MUST 540 announce the same VE Block Size for a given VE Offset. 542 4. Data Plane 544 This section discusses two aspects of the data plane for PEs and 545 L2PEs implementing VPLS: encapsulation and forwarding. 547 4.1. Encapsulation 549 Ethernet frames received from CE devices are encapsulated for 550 transmission over the packet switched network connecting the PEs. 551 The encapsulation is as in [10], with one change: a PE that sets the 552 P bit in the Control Flags strips the outermost VLAN from an Ethernet 553 frame received from a CE before encapsulating it, and pushes a VLAN 554 onto a decapsulated frame before sending it to a CE. 556 4.2. Forwarding 558 Forwarding of VPLS packets is based on the interface over which the 559 packet is received, which determines which VPLS the packet belongs 560 to, and the destination MAC address. The former mapping is 561 determined by configuration. The latter is the focus of this 562 section. 564 4.2.1. MAC address learning 566 As was mentioned earlier, the key distinguishing feature of VPLS is 567 that it is a multipoint service. This means that the entire Service 568 Provider network should appear as a single logical learning bridge 569 for each VPLS that the SP network supports. The logical ports for 570 the SP "bridge" are the connections from the SP edge, be it a PE or 571 an L2PE, to the CE. Just as a learning bridge learns MAC addresses 572 on its ports, the SP bridge must learn MAC addresses at its VEs. 574 Learning consists of associating source MAC addresses of packets with 575 the ports on which they arrive; call this association the Forwarding 576 Information Base (FIB). The FIB is used for forwarding packets. For 577 example, suppose the bridge receives a packet with source MAC address 578 S on port P. If subsequently, the bridge receives a packet with 579 destination MAC address S, it knows that it should send the packet 580 out on port P. 582 There are two modes of learning: qualified and unqualified learning. 584 In qualified learning, the learning decisions at the VE are based on 585 the customer ethernet packet's MAC address and VLAN tag, if one 586 exists. If no VLAN tag exists, the default VLAN is assumed. 587 Effectively, within one VPLS, there are multiple logical FIBs, one 588 for each customer VLAN tag identified in a customer packet. 590 In unqualified learning, learning is based on a customer ethernet 591 packet's MAC address only. In other words, at any VE, there is only 592 one FIB per VPLS. 594 Every VE must have at least one FIB for each VPLS that it 595 participates in. 597 4.2.2. Flooding 599 When a bridge receives a packet to a destination that is not in its 600 FIB, it floods the packet on all the other ports. Similarly, a VE 601 will flood packets to an unknown destination to all other VEs in the 602 VPLS. 604 In Figure 1 above, if CE2 sent an Ethernet frame to PE2, and the 605 destination MAC address on the frame was not in PE2's FIB (for that 606 VPLS), then PE2 would be responsible for flooding that frame to every 607 other PE in the same VPLS. On receiving that frame, PE1 would be 608 responsible for further flooding the frame to CE1 and CE5 (unless PE1 609 knew which CE "owned" that MAC address). 611 On the other hand, if PE3 received the frame, it could delegate 612 further flooding of the frame to its L2PE. If PE3 was connected to 2 613 L2PEs, it would announce that it has two L2PEs. PE3 could either 614 announce that it is incapable of flooding, in which case it would 615 receive two frames, one for each L2PE, or it could announce that it 616 is capable of flooding, in which case it would receive one copy of 617 the frame, which it would then send to both L2PEs. 619 4.2.3. "Split Horizon" Flooding 621 When a PE capable of flooding receives a broadcast Ethernet frame, or 622 one with an unknown destination MAC address, it must flood the frame. 623 If the frame arrived from an attached CE, the PE must send a copy of 624 the frame to every other attached CE, as well as to all PEs 625 participating in the VPLS. If the frame arrived from another PE, 626 however, the PE must only send a copy of the packet to attached CEs. 627 The PE MUST NOT send the frame to other PEs. This notion has been 628 termed "split horizon" flooding, and is a consequence of the PEs 629 being logically full-meshed -- if a broadcast frame is received from 630 PEx, then PEx would have sent a copy to all other PEs. 632 5. Deployment Scenarios 634 In deploying a network that supports VPLS, the SP must decide whether 635 the VPLS-aware device closest to the customer (the VE) is an L2PE or 636 a PE. The default case described in this document is that the VE is 637 a PE. However, there are a number of reasons that the VE might be an 638 L2PE, i.e., a device that does layer 2 functions such as MAC address 639 learning and flooding, and some limited layer 3 functions such as 640 communicating to its PE, but doesn't do full-fledged discovery and 641 PE-to-PE signaling. 643 As both of these cases have benefits, one would like to be able to 644 "mix and match" these scenarios. The signaling mechanism presented 645 here allows this. PE1 may be directly connected to CE devices; PE2 646 may be connected to L2PEs that are connected to CEs; and PE3 may be 647 connected directly to a customer over some interfaces and to L2PEs 648 over others. All these PEs do discovery and signaling in the same 649 manner. How they do learning and forwarding depends on whether or 650 not there is an L2PE; however, this is a local matter, and is not 651 signaled. 653 6. Normative References 655 [ 1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 656 Levels", BCP 14, RFC 2119, March 1997 658 [ 6] Bates, T., Rekhter, Y., Chandra, R., and Katz, D., 659 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000 661 [ 7] Rosen, E., and Rekhter, Y., Editors, "BGP/MPLS VPNs", draft- 662 ietf-l3vpn-rfc2547bis-01.txt, work in progress. 664 [ 9] Sangli, S., D. Tappan, and Y. Rekhter, "BGP Extended Communities 665 Attribute", draft-ietf-idr-bgp-ext-communities-06.txt, work in 666 progress. 668 [10] Martini, L., et al, "Encapsulation Methods for Transport of 669 Ethernet Frames Over IP/MPLS Networks", draft-ietf- 670 pwe3-ethernet-encap-05.txt, work in progress. 672 [11] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 673 Signature Option," RFC 2385, August 1998 675 7. Informative References 677 [ 2] Augustyn, W. (Editor), "Requirements for Virtual Private LAN 678 Services (VPLS)", draft-ietf-l2vpn-vpls-requirements-00.txt, 679 work in progress. 681 [ 3] Kompella, K., (Editor), "Layer 2 VPNs Over Tunnels", draft- 682 kompella-l2vpn-l2vpn-00.txt, work in progress. 684 [ 4] Martini, L., et al, "Pseudowire Setup and Maintenance using LDP" 685 draft-ietf-pwe3-control-protocol-05.txt, work in progress. 687 [ 5] Kompella, V., et al, "Virtual Private LAN Services over MPLS", 688 draft-ietf-ppvpn-vpls-ldp-01.txt, work in progress. 690 [ 8] Ould-Brahim, H. et al, "Using BGP as an Auto-Discovery Mechanism 691 for Network-based VPNs", work in progress. 693 Security Considerations 695 The focus in Virtual Private LAN Service is the privacy of data, 696 i.e., that data in a VPLS is only distributed to other nodes in that 697 VPLS and not to any external agent or other VPLS. Note that VPLS 698 does not offer security or authentication: VPLS packets are sent in 699 the clear in the packet-switched network, and a man-in-the-middle can 700 eavesdrop, and may be able to inject packets into the data stream. 701 If security is desired, the PE-to-PE tunnels can be IPsec tunnels. 702 For more security, the end systems in the VPLS sites can use 703 appropriate means of encryption to secure their data even before it 704 enters the Service Provider network. 706 There are two aspects to achieving data privacy in a VPLS: securing 707 the control plane, and protecting the forwarding path. Compromise of 708 the control plane could result in a PE sending data belonging to some 709 VPLS to another VPLS, or blackholing VPLS data, or even sending it to 710 an eavesdropper, none of which are acceptable from a data privacy 711 point of view. Since all control plane exchanges are via BGP, 712 techniques such as in [11] help authenticate BGP messages, making it 713 harder to spoof updates (which can be used to divert VPLS traffic to 714 the wrong VPLS), or withdraws (denial of service attacks). In the 715 multi-AS options (b) and (c), this also means protecting the inter-AS 716 BGP sessions, between the ASBRs, the PEs or the Route Reflectors. 717 Note that [11] will not help in keeping VPLS labels private -- 718 knowing the labels, one can eavesdrop on VPLS traffic. However, this 719 requires access to the data path within a Service Provider network. 721 Protecting the data plane requires ensuring that PE-to-PE tunnels are 722 well-behaved (this is outside the scope of this document), and that 723 VPLS labels are accepted only from valid interfaces. For a PE, valid 724 interfaces comprise links from P routers. For an ASBR, a valid 725 interface is a link from an ASBR in an AS that is part of a given 726 VPLS. It is especially important in the case of multi-AS VPLSs that 727 one accept VPLS packets only from valid interfaces. 729 IANA Considerations 731 IANA is asked to allocate an AFI for Layer 2 information (suggested 732 value: 25). IANA is also asked to register a SAFI for VPLS of 65 733 from the First-Come-First-Served space for SAFIs. 735 Contributors 737 The following contributed to this document: 739 Javier Achirica, Telefonica 740 Loa Andersson, TLA 741 Chaitanya Kodeboyina, Juniper 742 Giles Heron, Consultant 743 Sunil Khandekar, Alcatel 744 Vach Kompella, Alcatel 745 Marc Lasserre, Riverstone 746 Pierre Lin, Yipes 747 Pascal Menezes, Terabeam 748 Ashwin Moranganti, Appian 749 Hamid Ould-Brahim, Nortel 750 Seo Yeong-il, Korea Tel 752 Acknowledgments 754 Thanks to Joe Regan and Alfred Nothaft for their contributions. 756 Authors' Addresses 758 Kireeti Kompella 759 Juniper Networks 760 1194 N. Mathilda Ave 761 Sunnyvale, CA 94089 762 kireeti@juniper.net 764 Yakov Rekhter 765 Juniper Networks 766 1194 N. Mathilda Ave 767 Sunnyvale, CA 94089 768 yakov@juniper.net 770 IPR Notice 772 The IETF takes no position regarding the validity or scope of any 773 intellectual property or other rights that might be claimed to 774 pertain to the implementation or use of the technology described in 775 this document or the extent to which any license under such rights 776 might or might not be available; neither does it represent that it 777 has made any effort to identify any such rights. Information on the 778 IETF's procedures with respect to rights in standards-track and 779 standards-related documentation can be found in BCP-11. Copies of 780 claims of rights made available for publication and any assurances of 781 licenses to be made available, or the result of an attempt made to 782 obtain a general license or permission for the use of such 783 proprietary rights by implementors or users of this specification can 784 be obtained from the IETF Secretariat. 786 The IETF invites any interested party to bring to its attention any 787 copyrights, patents or patent applications, or other proprietary 788 rights which may cover technology that may be required to practice 789 this standard. Please address the information to the IETF Executive 790 Director. 792 Full Copyright Notice 794 Copyright (C) The Internet Society (2004). All Rights Reserved. 796 This document and translations of it may be copied and furnished to 797 others, and derivative works that comment on or otherwise explain it 798 or assist in its implementation may be prepared, copied, published 799 and distributed, in whole or in part, without restriction of any 800 kind, provided that the above copyright notice and this paragraph are 801 included on all such copies and derivative works. However, this 802 document itself may not be modified in any way, such as by removing 803 the copyright notice or references to the Internet Society or other 804 Internet organizations, except as needed for the purpose of 805 developing Internet standards in which case the procedures for 806 copyrights defined in the Internet Standards process must be 807 followed, or as required to translate it into languages other than 808 English. 810 The limited permissions granted above are perpetual and will not be 811 revoked by the Internet Society or its successors or assignees. 813 This document and the information contained herein is provided on an 814 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 815 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 816 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 817 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 818 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 820 Acknowledgement 822 Funding for the RFC Editor function is currently provided by the 823 Internet Society.