idnits 2.17.1 draft-ietf-l2vpn-vpls-bgp-00.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. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '1' is mentioned on line 61, but not defined == Missing Reference: '2' is mentioned on line 149, but not defined == Missing Reference: '3' is mentioned on line 467, but not defined == Missing Reference: '4' is mentioned on line 415, but not defined == Missing Reference: '5' is mentioned on line 86, but not defined == Missing Reference: '6' is mentioned on line 91, but not defined == Missing Reference: '7' is mentioned on line 434, but not defined == Missing Reference: '8' is mentioned on line 269, but not defined == Missing Reference: '9' is mentioned on line 262, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella (Juniper) 3 Internet Draft Y. Rekhter (Juniper) 4 V. Kompella (TiMetra) 5 Expires: November 2003 J. Achirica (Telefonica) 6 draft-ietf-l2vpn-vpls-bgp-00.txt L. Andersson (Utfors) 7 G. Heron (PacketExchange) 8 S. Khandekar (TiMetra) 9 M. Lasserre (Riverstone) 10 P. Lin (Yipes) 11 P. Menezes (Terabeam) 12 A. Moranganti (Appian) 13 H. Ould-Brahim (Nortel) 14 S. Yeong-il (Korea Tel) 16 Virtual Private LAN Service 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 Virtual Private LAN Service (VPLS), also known as Transparent LAN 46 Service, and Virtual Private Switched Network service, is a useful 47 Service Provider offering. The service offered is a Layer 2 VPN; 48 however, in the case of VPLS, the customers in the VPN are connected 49 by a multipoint network, in contrast to the usual Layer 2 VPNs, which 50 are point-to-point in nature. 52 This document describes the functions required to offer VPLS, and 53 proposes a mechanism for signaling a VPLS, as well as for forwarding 54 VPLS frames across a packet switched network. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC-2119 [1]. 62 The terms P (Provider router, VPN-unaware), PE (Provider Edge 63 router), VE (VPLS Edge device), CE (Customer Edge device), etc. are 64 defined in [2]. 66 1. Introduction 68 Virtual Private LAN Service (VPLS), also known as Transparent LAN 69 Service, and Virtual Private Switched Network service, is a useful 70 service offering. A Virtual Private LAN appears in (almost) all 71 respects as a LAN to customers of a Service Provider. However, in a 72 VPLS, the customers are not all connected to a single LAN; the 73 customers may be spread across a metro or wide area. In essence, a 74 VPLS glues several individual LANs across a metro area to appear and 75 function as a single LAN [3]. 77 This document describes the functions needed to offer VPLS, and goes 78 on to propose a mechanism for signaling a VPLS, as well as a 79 mechanism for transport of VPLS frames over tunnels across a packet 80 switched network. The signaling mechanism is taken from [4]; BGP is 81 used as the control plane protocol. This document also discusses 82 deployment options, in particular, the notion of decoupling functions 83 across devices. 85 Alternative approaches include: [4], which allows one to build a 86 Layer 2 VPN with Ethernet as the interconnect; and [5], which allows 87 one to set up an Ethernet connection across a packet switched 88 network. Both of these, however, offer point-to-point Ethernet 89 services. What distinguishes VPLS from the above two is that a VPLS 90 offers a multipoint service. A mechanism for setting up pseudowires 91 for VPLS using LDP is defined in [6]. 93 1.1. Scope of this Document 95 This document has four major parts: defining a VPLS functional model; 96 defining a control plane for setting up VPLS; defining the data plane 97 for VPLS (encapsulation and forwarding of data); and defining various 98 deployment scenarios. 100 The functional model underlying VPLS is laid out in section 2. This 101 describes the service being offered, the network components that 102 interact to provide the service, and at a high level their 103 interactions. 105 The control plane proposed here (section 3) uses BGP to establish 106 VPLS service, i.e., for autodiscovery of VPLS members and for the 107 setup and teardown of the pseudowires that constitute a given VPLS. 108 Section 3 also describes how a VPLS that spans Autonomous System 109 boundaries is set up. Using BGP as the control plane for VPNs is not 110 new (see [4], [7] and [8]): what is described here is identical to 111 what is in [4], which itself is based on the mechanisms proposed in 112 [7]. 114 The forwarding plane and the actions that a participating PE must 115 take is described in section 4. 117 In section 5, the notion of 'decoupled' operation is defined, and the 118 interaction of decoupled and non-decoupled PEs is described. 119 Decoupling allows for more flexible deployment of VPLS. 121 2. Functional Model 123 This will be described with reference to Figure 1. 125 Figure 1: Example of a VPLS 126 ----- 127 / A1 \ 128 ---- ____CE1 | 129 / \ -------- -------- / | | 130 | A2 CE2- / \ / PE1 \ / 131 \ / \ / \___/ | \ ----- 132 ---- ---PE2 | \ 133 | | \ ----- 134 | Service Provider Network | \ / \ 135 | | CE5 A5 | 136 | ___ | / \ / 137 |----| \ / \ PE4_/ ----- 138 |L2PE|--PE3 / \ / 139 |----| -------- ------- 140 ---- / | ---- 141 / \/ \ / \ CE = Customer Edge Device 142 | A3 CE3 --CE4 A4 | PE = Provider Edge Router 143 \ / \ / L2PE = Layer 2 Aggregation 144 ---- ---- 146 2.1. Terminology 148 (NOTE: the terminology here has not quite been fully harmonized with 149 the terminology in the VPN terminology document [2] or the PWE3 150 framework document; this will be done in a later version.) 152 The terminology of [4] is used, with the addition of "L2PE", a Layer 153 2 PE device used for Layer 2 aggregation. An L2PE is owned and 154 operated by the Service Provider (as is the PE). PE and L2PE devices 155 are "VPLS-aware", which means that they know that a VPLS service is 156 being offered. We will call these VPLS edge devices, which could be 157 either a PE or an L2PE, a VE. 159 In contrast, the CE device (which may be owned and operated by either 160 the SP or the customer) is VPLS-unaware; as far as the CE is 161 concerned, it is connected to the other CEs in the VPLS via a Layer 2 162 switched network. This means that there should be no changes to a CE 163 device, either to the hardware or the software, in order to offer 164 VPLS. 166 A CE device may be connected to a PE or an L2PE via Layer 2 switches 167 that are VPLS-unaware. From a VPLS point of view, such Layer 2 168 switches are invisible, and hence will not be discussed further. 170 Furthermore, an L2PE may be connected to a PE via Layer 2 and Layer 3 171 devices; this will be discussed further in a later section. 173 The term "demultiplexor" refers to an identifier in a data packet 174 that identifies both the VPLS to which the packet belongs as well as 175 the ingress PE. In this document, the demultiplexor is an MPLS 176 label. 178 The term "VPLS" will refer to the service as well as a particular 179 instantiation of the service (i.e., an emulated LAN); it should be 180 clear from the context which usage is intended. 182 2.2. Assumptions 184 The Service Provider Network is a packet switched network. The PEs 185 are assumed to be full meshed with tunnels over which packets that 186 belong to a service (such as VPLS) are encapsulated and forwarded. 187 These tunnels can be IP tunnels, such as GRE, or MPLS tunnels, 188 established by RSVP-TE or LDP. These tunnels are established 189 independently of the services offered over them; the signaling and 190 establishment of these tunnels are not discussed in this document. 192 "Flooding" and MAC address "learning" (see section 4) are an integral 193 part of VPLS. However, these activities are private to an SP device, 194 i.e., in the VPLS described below, no SP device requests another SP 195 device to flood packets or learn MAC addresses on its behalf. 197 All the PEs participating in a VPLS are assumed to be fully meshed, 198 i.e., every (ingress) PE can send a VPLS packet to the egress PE(s) 199 directly, without the need for an intermediate PE. This assumption 200 reduces (but does not eliminate) the need to run Spanning Tree 201 Protocol among the PEs. 203 2.3. Interactions 205 VPLS is a successful "LAN Service" if CE devices that belong to VPLS 206 V can interact through the SP network as if they were connected by a 207 LAN. VPLS is "private" if CE devices that belong to different VPLSs 208 cannot interact. VPLS is "virtual" if multiple VPLSs can be offered 209 over a common packet switched network. 211 PE devices interact to "discover" who all participate in the same 212 VPLS (i.e., are attached to CE devices that belong to the same VPLS), 213 and to exchange demultiplexors. These interactions are control- 214 driven, not data-driven. 216 L2PEs interact with PEs to establish connections with remote PEs or 217 L2PEs in the same VPLS. Again, this interaction is control-driven. 219 3. Control Plane 221 There are two primary functions of the VPLS control plane: 222 autodiscovery, and setup and teardown of the pseudowires that 223 constitute the VPLS, often called signaling. The first two 224 subsections describe these functions. The last subsection describes 225 the setting up of pseudowires that span Autonomous Systems. 227 3.1. Autodiscovery 229 Autodiscovery refers to the process of finding all the PEs that 230 participate in a given VPLS. A PE can either be configured with the 231 identities of all the other PEs in a given VPLS, or the PE can 232 autodiscover the other PEs. 234 The former approach is fairly configuration-intensive, especially 235 since it is required (in this and other VPLS approaches) that the PEs 236 participating in a given VPLS are fully meshed (i.e., every pair of 237 PEs in a given VPLS establish pseudowires to each other). 238 Furthermore, when the topology of a VPLS changes (i.e., a PE is added 239 to, or removed from the VPLS), the VPLS configuration on all PEs in 240 that VPLS must be changed. 242 In the autodiscovery approach, each PE "discovers" which other PEs 243 are part of a given VPLS by means of some protocol. In this 244 approach, each PE's configuration consists only of the identity of 245 the VPLS that each customer belongs to, not the identity of every 246 other PE in that VPLS. Moreover, when the topology of a VPLS 247 changes, only the affected PE's configuration changes; other PEs 248 automatically find out about the change and adapt. 250 3.1.1. Functions 252 A PE that participates in a given VPLS V must be able to tell all 253 other PEs in VPLS V that it is also a member of V. A PE must also 254 have a means of declaring that it no longer participates in a VPLS. 255 To do both of these, the PE must have a means of identifying a VPLS 256 and a means by which to communicate to all other PEs. 258 L2PE devices also need to know what constitutes a given VPLS; 259 however, they don't need the same level of detail. The PE (or PEs) 260 to which an L2PE is connected gives the L2PE an abstraction of the 261 VPLS; this is described in section 5. One protocol mechanism to 262 achieve this is described in [9]. 264 3.1.2. Protocol Specification 266 The specific mechanism for autodiscovery described here, borrowed 267 essentially unchanged from [4] and [7], uses BGP extended communities 268 [10] to identify a VPLS. This mechanism is described more 269 generically in [8]. The specific extended community used is the 270 Route Target, whose format is described in [10]. The semantics of 271 the use of Route Targets is described in [7]; their use in VPLS is 272 identical. 274 As it has been assumed that VPLSs are fully meshed, a single Route 275 Target RT suffices for a given VPLS V, and in effect that RT is the 276 identifier for VPLS V. 278 A PE announces (typically via I-BGP) that it belongs to VPLS V by 279 annotating its NLRIs for V (see next subsection) with Route Target 280 RT, and acts on this by accepting NLRIs from other PEs that have 281 Route Target RT. A PE announces that it no longer participates in V 282 by withdrawing all NLRIs that it had advertised with Route Target RT. 284 3.2. Signaling 286 Once discovery is done, each pair of PEs in a VPLS must be able to 287 establish (and tear down) pseudowires to each other, i.e., exchange 288 (and withdraw) demultiplexors. This process is known as signaling. 289 Signaling is also used to initiate "relearning", and to transmit 290 certain characteristics of the PE regarding a given VPLS. 292 Recall that a demultiplexor is used to distinguish among several 293 different streams of traffic carried over a tunnel, each stream 294 possibly representing a different service. In the case of VPLS, the 295 demultiplexor not only says to which specific VPLS a packet belongs, 296 but also identifies the ingress PE. The former information is used 297 for forwarding the packet; the latter information is used for 298 learning MAC addresses. The demultiplexor described here is an MPLS 299 label, even though the PE-to-PE tunnels may not be MPLS tunnels. 301 3.2.1. Setup and Teardown 303 A BGP NLRI, the VPLS NLRI, is used to exchange demultiplexors, using 304 the mechanism described in [4]. 306 A PE advertises a VPLS NLRI for each VPLS that it participates in. 307 If the PE is doing learning and flooding, i.e., it is the VE, it 308 announces a single set of VPLS NLRIs for each VPLS that it is in. If 309 the PE is connected to several L2PEs, it announces one set of VPLS 310 NLRIs for each L2PE. A hybrid scheme is also possible, where the PE 311 learns MAC addresses on some interfaces (over which it is directly 312 connected to CEs) and delegates learning on other interfaces (over 313 which it is connected to L2PEs). In this case, the PE would announce 314 one set of VPLS NLRIs for each L2PE that has customer ports in a 315 given VPLS, and one set for itself, if it has customer ports in that 316 VPLS. 318 Each set of NLRIs defines the demultiplexors for a range of other PEs 319 in the VPLS. Ideally, a single NLRI suffices for all PEs in a VPLS; 320 however, there are cases (such as a newly added PE) where the pre- 321 existing NLRI does not have enough labels. In such cases, 322 advertising an additional NLRI for the same VPLS serves to add labels 323 for the new PEs without disrupting service to the pre-existing PEs. 324 If service disruption is acceptable (or when the PE restarts its BGP 325 process), a PE MAY consider coalescing all NLRIs for a VPLS into a 326 single NLRI. 328 If a PE X is part of VPLS V, and X receives a VPLS NLRI for V from PE 329 Y that includes a demultiplexor that X can use, X sets up its ends of 330 a pair of pseudowires between X and Y. X may also have to advertise 331 a new NLRI for V that includes a demultiplexor that Y can use, if its 332 pre-existing NLRI for V did not include a demultiplexor for Y. 334 If Y withdraws its NLRI for V that X was using, then X tears down its 335 ends of the pseudowires between X and Y. 337 The format of the VPLS NLRI is given below; it is essentially 338 identical to the L2 VPN NLRI [4]. The AFI and SAFI are the same as 339 for the L2 VPN NLRI. 341 Figure 2: BGP NLRI for VPLS Information 343 +------------------------------------+ 344 | Length (2 octets) | 345 +------------------------------------+ 346 | Route Distinguisher (8 octets) | 347 +------------------------------------+ 348 | VE ID (2 octets) | 349 +------------------------------------+ 350 | Label-block Offset (2 octets) | 351 +------------------------------------+ 352 | Label Base (3 octets) | 353 +------------------------------------+ 354 | Variable TLVs (0 to N octets) | 355 | ... | 356 +------------------------------------+ 358 3.2.2. Relearning MAC Addresses 360 Once a MAC address has been learned by VE A, VE A no longer needs to 361 flood packets destined to that MAC address; instead VE A can send 362 those packets directly to the VE "owning" that MAC address, say B. 363 However, it is possible that a CE "move" from VE B to VE C; one 364 example scenario is that the CE is dual-homed to VE B and C, and the 365 link over which the CE is attached to VE B goes down. In this case, 366 VE B may want to signal to other VEs in the VPLS that MAC addresses 367 that they learned from VE B (for the given VPLS) are no longer valid. 368 While aging timers will eventually enforce this, they may often be 369 too slow. The Relearn Sequence Number (RSN) TLV will help speed up 370 relearning. 372 The RSN TLV is an optional TLV with Type TBD, Length 4 and Value a 32 373 bit RSN, a monotonically increasing unsigned number. When an RSN TLV 374 is received, the RSN number is compared against the existing one for 375 that VPLS and PE. If the new number is higher than the previous one, 376 or no previous RSN exists, the PE SHOULD flush all existing MAC 377 address to VC bindings for that VPLS and PE. 379 3.2.3. Signaling PE Capabilities 381 The Encaps Type and Control Flags are encoded in an extended 382 attribute, just as in [4]. The community type remains the same. 384 There is a new Encaps Type for VPLS (TBD). 386 Figure 3: layer2-info extended community 388 +------------------------------------+ 389 | Extended community type (2 octets) | 390 +------------------------------------+ 391 | Encaps Type (1 octet) | 392 +------------------------------------+ 393 | Control Flags (1 octet) | 394 +------------------------------------+ 395 | Layer-2 MTU (2 octet) | 396 +------------------------------------+ 397 | Reserved (2 octets) | 398 +------------------------------------+ 400 There are three new control flags, Q, F and P defined for VPLS. Q 401 says whether qualified learning occurs (1) or not (0); F which says 402 whether the PE is capable of flooding (1) or not (0). P indicates 403 that the PE will strip the outermost VLAN from the layer 2 customer 404 frame on ingress, and push a VLAN on egress. 406 Figure 4: Control Flags Bit Vector 408 0 1 2 3 4 5 6 7 409 +-+-+-+-+-+-+-+-+ 410 | MBZ |P|Q|F|C|S| (MBZ = MUST Be Zero) 411 +-+-+-+-+-+-+-+-+ 413 3.3. Inter-Provider VPLS 415 As in [4] and [7], the above autodiscovery and signaling functions 416 are typically announced via I-BGP. This assumes that all the sites 417 in a VPLS are connected to PEs in a single Autonomous System (AS). 419 However, sites in a VPLS may occasionally connect to PEs in different 420 ASes. This leads to two issues: a) there would not be an I-BGP 421 connection between those PEs, so some means of signaling inter-AS is 422 needed; and b) there may not be PE-to-PE tunnels between the ASes. 424 The former problem is solved in [7], Section 10. Three methods are 425 suggested; of these, the last two Just Work for Inter-Provider VPLS. 426 Method (b) requires an I-BGP peering between the PEs in AS1 and ASBR1 427 in AS1, an E-BGP peering between ASBR1 and ASBR2 in AS2, and I-BGP 428 peerings between ASBR2 and the PEs in AS2. Method (c) requires a 429 multi-hop E-BGP peering between the PEs (or preferably, a Route 430 Reflector) in AS1 and the PEs (or Route Reflector) in AS2. 432 The latter is easy if the PE-to-PE tunnels are IP. If the tunnels 433 are MPLS, labeled IPv4 distribution of PE loopback addresses by ASBRs 434 (as described in part (c) of Section 10 of [7]) can be used to create 435 PE-to-PE MPLS LSPs that traverses the ASes. 437 4. Data Plane 439 This section discusses two aspects of the data plane for PEs and 440 L2PEs implementing VPLS: encapsulation and forwarding. 442 4.1. Encapsulation 444 Ethernet frames received from CE devices are encapsulated for 445 transmission over the packet switched network connecting the PEs. 446 The encapsulation is as in [11], with one change: a PE that sets the 447 P bit in the Control Flags strips the outermost VLAN from an Ethernet 448 frame received from a CE before encapsulating it, and pushes a VLAN 449 onto a decapsulated frame before sending it to a CE. 451 4.2. Forwarding 453 Forwarding of VPLS packets is based on the interface over which the 454 packet is received, which determines which VPLS the packet belongs 455 to, and the destination MAC address. The former mapping is 456 determined by configuration. The latter is the focus of this 457 section. 459 4.2.1. MAC address learning 461 As was mentioned earlier, the key distinguishing feature of VPLS is 462 that it is a multipoint service. This means that the entire Service 463 Provider network should appear as a single logical learning bridge 464 for each VPLS that the SP network supports. The logical ports for 465 the SP "bridge" are the connections from the SP edge, be it a PE or 466 an L2PE, to the CE. Just as a learning bridge learns MAC addresses 467 on its ports, the SP bridge must learn MAC addresses at its VEs [3]. 469 Learning consists of associating source MAC addresses of packets with 470 the ports on which they arrive; call this association the Forwarding 471 Information Base (FIB). The FIB is used for forwarding packets. For 472 example, suppose the bridge receives a packet with source MAC address 473 S on port P. If subsequently, the bridge receives a packet with 474 destination MAC address S, it knows that it should send the packet 475 out on port P. 477 There are two modes of learning: qualified and unqualified learning. 479 In qualified learning, the learning decisions at the VE are based on 480 the customer ethernet packet's MAC address and VLAN tag, if one 481 exists. If no VLAN tag exists, the default VLAN is assumed. 482 Effectively, within one VPLS, there are multiple logical FIBs, one 483 for each customer VLAN tag identified in a customer packet. 485 In unqualified learning, learning is based on a customer ethernet 486 packet's MAC address only. In other words, at any VE, there is only 487 one FIB per VPLS. 489 Every VE must have at least one FIB for each VPLS that it 490 participates in. 492 4.2.2. Flooding 494 When a bridge receives a packet to a destination that is not in its 495 FIB, it floods the packet on all the other ports. Similarly, a VE 496 will flood packets to an unknown destination to all other VEs in the 497 VPLS. 499 In Figure 1 above, if CE2 sent an Ethernet frame to PE2, and the 500 destination MAC address on the frame was not in PE2's FIB (for that 501 VPLS), then PE2 would be responsible for flooding that frame to every 502 other PE in the same VPLS. On receiving that frame, PE1 would be 503 responsible for further flooding the frame to CE1 and CE5 (unless PE1 504 knew which CE "owned" that MAC address). 506 On the other hand, if PE3 received the frame, it could delegate 507 further flooding of the frame to its L2PE. If PE3 was connected to 2 508 L2PEs, it would announce that it has two L2PEs. PE3 could either 509 announce that it is incapable of flooding, in which case it would 510 receive two frames, one for each L2PE, or it could announce that it 511 is capable of flooding, in which case it would receive one copy of 512 the frame, which it would then send to both L2PEs. 514 5. Deployment Scenarios 516 In deploying a network that supports VPLS, the SP must decide whether 517 the VPLS-aware device closest to the customer (the VE) is an L2PE or 518 a PE. The default case described in this document is that the VE is 519 a PE. However, there are a number of reasons that the VE might be an 520 L2PE, i.e., a device that does layer 2 functions such as MAC address 521 learning and flooding, and some limited layer 3 functions such as 522 communicating to its PE, but doesn't do full-fledged discovery and 523 PE-to-PE signaling [12]. 525 As both of these cases have benefits, one would like to be able to 526 "mix and match" these scenarios. The signaling mechanism presented 527 here allows this. PE1 may be directly connected to CE devices; PE2 528 may be connected to L2PEs that are connected to CEs; and PE3 may be 529 connected directly to a customer over some interfaces and to L2PEs 530 over others. All these PEs do discovery and signaling in the same 531 manner. How they do learning and forwarding depends on whether or 532 not there is an L2PE; however, this is a local matter, and is not 533 signaled. 535 6. Normative References 537 [ 1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 538 Levels", BCP 14, RFC 2119, March 1997 540 [ 2] Andersson, L. and T. Madsen, "PPVPN Terminology", work in 541 progress. 543 [ 3] Andersson, L. (Editor), "PPVPN L2 Framework", work in progress. 545 [ 4] Kompella, K., et al, "MPLS-based Layer 2 VPNs", work in 546 progress. 548 [ 7] Rosen, E., et al, "BGP/MPLS VPNs", work in progress. 550 [10] Sangli, S., D. Tappan, and Y. Rekhter, "BGP Extended Communities 551 Attribute", (work in progress). 553 [11] Martini, L., et al, "Encapsulation Methods for Transport of 554 Layer 2 Frames Over IP and MPLS Networks", work in progress. 556 [12] Kompella, K., et al, "Decoupled TLS", work in progress. 558 7. Informative References 560 [ 5] Martini, L., et al, "Transport of Layer 2 Frames Over MPLS", 561 work in progress. 563 [ 6] Kompella, V., et al, "Virtual Private Switched Network Services 564 over an MPLS Network", work in progress. 566 [ 8] Ould-Brahim, H. et al, "Using BGP as an Auto-Discovery Mechanism 567 for Network-based VPNs", work in progress. 569 [ 9] Shah, H. et al, "Signaling between PE and L2PE/MTU for Decoupled 570 VPLS and Hierarchical VPLS", work in progress. 572 Security Considerations 574 To be filled in in a later version. 576 IANA Considerations 578 To be filled in in a later version. 580 Acknowledgments 582 Thanks to Joe Regan and Alfred Nothaft for their contributions. 584 Authors' Addresses 586 Yeong-il,Seo 587 Korea Telecom 588 Telecommunication Network Laboratory 589 Member of Technical Staff 590 463-1 Junmin-dong, Yusung-gu, Taejeon, Korea 591 Tel : +82-42-870-8333 / FAX : +82-42-870-8339 592 Mobile : 016-235-0135 / E-mail : syi@hana.ne.kr 594 Hamid Ould-Brahim 595 Nortel Networks 596 P O Box 3511 Station C 597 Ottawa ON K1Y 4H7 Canada 598 Phone: +1 (613) 765 3418 599 Email: hbrahim@nortelnetworks.com 601 Ashwin Moranganti 602 Appian Communications 603 email: amoranganti@appiancom.com 604 phone: 978 206-7248 606 Pascal Menezes 607 Terabeam Networks, Inc. 608 14833 NE 87th St. 609 Redmond, WA, USA 610 phone: (206) 686-2001 611 email: Pascal.Menezes@Terabeam.com 613 Pierre Lin 614 Yipes Communications, Inc. 615 114 Sansome St. 616 San Francisco CA 94104 617 email: pierre.lin@yipes.com 619 Marc Lasserre 620 Riverstone Networks 621 5200 Great America Parkway 622 Santa Clara CA 95054 623 marc@riverstonenet.com 625 Sunil Khandekar 626 TiMetra Networks 627 274 Ferguson Dr. 628 Mountain View, CA 94043 630 Giles Heron 631 PacketExchange Ltd. 632 The Truman Brewery 633 91 Brick Lane 634 LONDON E1 6QL 635 United Kingdom 636 Email: giles@packetexchange.net 638 Loa Andersson 639 Utfors AB 640 Box 525, 169 29 Solna 641 Sweden 642 phone: +46 8 5270 5038 643 email: loa.andersson@utfors.se 645 Javier Achirica 646 Telefonica Data 647 javier.achirica@telefonica-data.com 649 Vach Kompella 650 TiMetra Networks 651 274 Ferguson Dr. 652 Mountain View, CA 94043 653 Email: vkompella@timetra.com 655 Yakov Rekhter 656 Juniper Networks 657 1194 N. Mathilda Ave 658 Sunnyvale, CA 94089 659 yakov@juniper.net 661 Kireeti Kompella 662 Juniper Networks 663 1194 N. Mathilda Ave 664 Sunnyvale, CA 94089 665 kireeti@juniper.net 667 IPR Notice 669 The IETF takes no position regarding the validity or scope of any 670 intellectual property or other rights that might be claimed to 671 pertain to the implementation or use of the technology described in 672 this document or the extent to which any license under such rights 673 might or might not be available; neither does it represent that it 674 has made any effort to identify any such rights. Information on the 675 IETF's procedures with respect to rights in standards-track and 676 standards-related documentation can be found in BCP-11. Copies of 677 claims of rights made available for publication and any assurances of 678 licenses to be made available, or the result of an attempt made to 679 obtain a general license or permission for the use of such 680 proprietary rights by implementors or users of this specification can 681 be obtained from the IETF Secretariat. 683 The IETF invites any interested party to bring to its attention any 684 copyrights, patents or patent applications, or other proprietary 685 rights which may cover technology that may be required to practice 686 this standard. Please address the information to the IETF Executive 687 Director. 689 Full Copyright Notice 691 Copyright (C) The Internet Society (2003). All Rights Reserved. 693 This document and translations of it may be copied and furnished to 694 others, and derivative works that comment on or otherwise explain it 695 or assist in its implementation may be prepared, copied, published 696 and distributed, in whole or in part, without restriction of any 697 kind, provided that the above copyright notice and this paragraph are 698 included on all such copies and derivative works. However, this 699 document itself may not be modified in any way, such as by removing 700 the copyright notice or references to the Internet Society or other 701 Internet organizations, except as needed for the purpose of 702 developing Internet standards in which case the procedures for 703 copyrights defined in the Internet Standards process must be 704 followed, or as required to translate it into languages other than 705 English. 707 The limited permissions granted above are perpetual and will not be 708 revoked by the Internet Society or its successors or assigns. 710 This document and the information contained herein is provided on an 711 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 712 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 713 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 714 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 715 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 717 Acknowledgement 719 Funding for the RFC Editor function is currently provided by the 720 Internet Society.