idnits 2.17.1 draft-kompella-l2vpn-vpls-multihoming-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 585. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 603. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 609. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4761, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC4761, updated by this document, for RFC5378 checks: 2003-07-22) -- 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 (July 13, 2008) is 5760 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) == Outdated reference: A later version (-01) exists of draft-kothari-l2vpn-auto-site-id-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 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 Updates: 4761 (if approved) Juniper Networks 5 Intended status: Standards Track T. Spencer 6 Expires: January 14, 2009 AT&T 7 July 13, 2008 9 Multi-homing in BGP-based Virtual Private LAN Service 10 draft-kompella-l2vpn-vpls-multihoming-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 14, 2009. 37 Abstract 39 Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private 40 Network (VPN) that gives its customers the appearance that their 41 sites are connected via a Local Area Network (LAN). It is often 42 required for the Service Provider (SP) to give the customer redundant 43 connectivity to some sites, often called "multi-homing". This memo 44 shows how multi-homing can be offered in the context of BGP-based 45 VPLS. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. General Terminology . . . . . . . . . . . . . . . . . . . 3 51 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.2. VPLS Multi-homing Considerations . . . . . . . . . . . . . 5 55 2.3. Using the Spanning Tree Protocol for Multi-homing . . . . 5 56 2.4. Active/Backup Links . . . . . . . . . . . . . . . . . . . 6 57 2.5. Comparisons . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Multi-homing Operation . . . . . . . . . . . . . . . . . . . . 7 59 3.1. VE ID Assignment . . . . . . . . . . . . . . . . . . . . . 7 60 3.2. VE Preference . . . . . . . . . . . . . . . . . . . . . . 7 61 3.3. BGP Local Preference . . . . . . . . . . . . . . . . . . . 8 62 3.4. Designated Forwarder Election . . . . . . . . . . . . . . 8 63 3.4.1. BGP Path Selection . . . . . . . . . . . . . . . . . . 9 64 3.4.2. VPLS Path Selection . . . . . . . . . . . . . . . . . 10 65 4. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . . . 12 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 73 Intellectual Property and Copyright Statements . . . . . . . . . . 18 75 1. Introduction 77 Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private 78 Network (VPN) that gives its customers the appearance that their 79 sites are connected via a Local Area Network (LAN). It is often 80 required for a Service Provider (SP) to give the customer redundant 81 connectivity to one or more sites, often called "multi-homing". 82 [RFC4761] explains how VPLS can be offered using BGP for auto- 83 discovery and signaling; section 3.5 of that document describes how 84 multi-homing can be achieved in this context. Implementation and 85 deployment of multi-homing in BGP-based VPLS has suggested some 86 refinement of the procedures described earlier; this memo details 87 these changes. 89 Section 2 lays out some of the scenarios for multi-homing, other ways 90 that this can be achieved, and some of the expectations of BGP-based 91 multi-homing. Section 3 defines the components of BGP-based multi- 92 homing, and the procedures required to achieve this. Section 5 may 93 someday discuss security considerations. 95 1.1. General Terminology 97 Some general terminology is defined here; most is from [RFC4761] or 98 [RFC4364]. Terminology specific to this memo is introduced as needed 99 in later sections. 101 A "Customer Edge" (CE) device, typically located on customer 102 premises, connects to a "Provider Edge" (PE) device, which is owned 103 and operated by the SP. A "Provider" (P) device is also owned and 104 operated by the SP, but has no direct customer connections. A "VPLS 105 Edge" (VE) device is a PE that offers VPLS services. 107 A VPLS domain represents a bridging domain per customer. A Route 108 Target community as described in [RFC4360] is typically used to 109 identify all the PE routers participating in a particular VPLS 110 domain. A VPLS site is a grouping of ports on a PE that belong to 111 the same VPLS domain. Sites are referred to as local or remote 112 depending on whether they are configured on the PE router in context 113 or on one of the remote PE routers (network peers). 115 1.2. Conventions 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. Background 123 This section describes various scenarios where multi-homing may be 124 required, and the implications thereof. It also describes some of 125 the singular properties of VPLS multi-homing, and what that means 126 from both an operational point of view and an implementation point of 127 view. It describes briefly how the Spanning Tree Protocol can be 128 used to achieve multi-homing, and how that compares with BGP-based 129 multi-homing. 131 2.1. Scenarios 133 The most basic scenario is shown in Figure 1. 135 CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant 136 connectivity. 138 ............... 139 . . ___ CE2 140 ___ PE1 . / 141 / : PE3 142 __/ : Service : 143 CE1 __ : Provider PE4 144 \ : : \___ CE3 145 \___ PE2 . 146 . . 147 ............... 149 Figure 1: Scenario 1 151 CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant 152 connectivity. However, CE4, which is also in the same VPLS domain, 153 is single-homed to just PE1. 155 CE4 ------- ............... 156 \ . . ___ CE2 157 ___ PE1 . / 158 / : PE3 159 __/ : Service : 160 CE1 __ : Provider PE4 161 \ : : \___ CE3 162 \___ PE2 . 163 . . 164 ............... 166 Figure 2: Scenario 2 168 2.2. VPLS Multi-homing Considerations 170 The first (perhaps obvious) fact about a multi-homed VPLS CE, such as 171 CE1 in Figure 1 is that if CE1 is an Ethernet switch or bridge, a 172 loop has been created in the customer VPLS. This is a dangerous 173 situation for an Ethernet network, and the loop must be broken. Even 174 if CE1 is a router, it will get duplicates every time a packet is 175 flooded, which is clearly undesirable. 177 The next is that (unlike the case of IP-based multi-homing) only one 178 of PE1 and PE2 can be actively sending traffic, either towards CE1 or 179 into the SP cloud. That is to say, load balancing techniques will 180 not work. All other PEs MUST choose the same designated forwarder 181 for a multi-homed site. Call the PE that is chosen to send traffic 182 to/from CE1 the "designated forwarder". 184 In Figure 2, CE1 and CE4 must be dealt with independently, since CE1 185 is dual-homed, but CE4 is not. 187 2.3. Using the Spanning Tree Protocol for Multi-homing 189 It is quite common to have redundant links in Ethernet networks; here 190 too, redundancy leads to loops, but these can be broken by the use of 191 the Spanning Tree Protocol (STP). This technique can also be applied 192 in the case of multi-homed CEs in a VPLS domain. One approach is to 193 run STP on the multi-homed CE (say CE1 in Figure 1). CE1 would thus 194 detect a potential loop in the virtual LAN, and "block" either the 195 link to PE1 or to PE2, breaking the loop. Blocking the link to PE2 196 would effectively pick PE1 to be the designated forwarder, since (a) 197 PE2 will not get any traffic from CE1 to forward; (b) PE2's traffic 198 to CE1 will be ignored. 200 There are several operational disadvantages to the STP approach: 202 1. The SP has to trust the customer to run STP correctly and manage 203 changes carefully. If the customer makes a mistake, the SP will 204 pay for it by carrying the customer's "broadcast storm" across 205 the SP network. 207 2. The choice of whether PE1 or PE2 will be the "designated 208 forwarder" is made by the customer; however, the SP may feel that 209 they should make this choice, and in fact may be in a better 210 position to do so, as they know their network topology better. 212 3. STP has several characteristics that make it unsuitable for 213 carrier networks. 215 Another approach is to run STP on the PEs. However, the whole point 216 of having a full mesh of PE-PE connections, and of "split horizon" 217 forwarding (Section 4.2.5 [RFC4761]; Section 4.4 [RFC4762]) is so 218 that STP is not needed on PEs. Furthermore, in Figure 2, PE1 must 219 not block the pseudowires to PE3 and PE4 in order to break the loop. 221 2.4. Active/Backup Links 223 Another approach is to define "active" and "backup" links from a 224 multi-homed CE to the PEs. For example, in Figure 1, CE1 could 225 define the link to PE1 as active and the link to PE2 as backup. If 226 the link to PE1, or PE1 itself, fails, the CE1 could detect this and 227 switch to the backup. However, again, the SP has to trust the 228 customer's staff to handle this correctly; also, the choice of 229 whether to use PE1 or PE2 remains with the customer. 231 2.5. Comparisons 233 One of the above methods may be acceptable in some cases. The 234 technique described in this memo is for those who are unsatisfied 235 with these methods. This technique relies on BGP mechanisms; 236 furthermore, the choice of "designated forwarder" is retained by the 237 SP. Finally, this technique can be used in conjunction with STP to 238 get further "insurance" against the possibility of loops. 240 3. Multi-homing Operation 242 This section describes procedures for electing a designated forwarder 243 among the set of PEs that are multi-homed to a customer site. It is 244 imperative that all VPLS PEs elect the same designated forwarder 245 otherwise either a loop will be formed or traffic will be dropped. 246 Thus, procedures defined here MUST be supported by all BGP speakers 247 that are required to process VPLS NLRI advertisements. 249 3.1. VE ID Assignment 251 Figure 1 shows a customer site, CE1, multi-homed to two VPLS PEs, PE1 252 and PE2. In order for all VPLS PEs within the same VPLS domain to 253 elect one of the multi-homed PEs as the designated forwarder, an 254 indicator that the PEs are multi-homed is required. This is achieved 255 by assigning the same VE ID on PE1 and PE2 for CE1. When remote VPLS 256 PEs receive NLRI advertisement from PE1 and PE2 for CE1, the two NLRI 257 advertisements for CE1 are identified as candidates for designated 258 forwarder selection due to the same VE ID. Thus, same VE ID MUST be 259 assigned on all VPLS PEs that are multi-homed to the same customer 260 site. 262 Figure 2 shows two customer sites, CE1 and CE4, connected to PE1 and 263 CE1 multi-homed to PE1 and PE2. In such a case, PE1 SHOULD assign 264 different VE IDs to CE1 and CE4, but the VE ID for CE1 on both PE1 265 and PE2 MUST be same. 267 3.2. VE Preference 269 When multiple PEs are assigned the same VE ID for multi-homing, it is 270 often desired to make a particular PE as the designated forwarder. A 271 VE preference is introduced in this document that can be used to 272 control the selection of the designated forwarder. A VE preference 273 indicates a degree of preference for a particular customer site. 274 Absence of this preference will still elect a designated forwarder 275 based on the algorithm explained in Section 3.4. 277 Section 3.2.4 in [RFC4761] describes the Layer2 Info Extended 278 Community that carries control information about the pseudowires. 279 The last two octets that were reserved now carries VE preference as 280 shown in Figure 3. 282 +------------------------------------+ 283 | Extended community type (2 octets) | 284 +------------------------------------+ 285 | Encaps Type (1 octet) | 286 +------------------------------------+ 287 | Control Flags (1 octet) | 288 +------------------------------------+ 289 | Layer-2 MTU (2 octet) | 290 +------------------------------------+ 291 | VE Preference (2 octets) | 292 +------------------------------------+ 294 Figure 3: Layer2 Info Extended Community 296 A VE preference value of zero indicates absence of VE preference and 297 is not a valid preference value. This interpretation is required for 298 backwards compatibility. Implementations using Layer2 Info Extended 299 Community as described in (Section 3.2.4) [RFC4761] MUST set the last 300 two octets as zero since it was a reserved field. A VPLS 301 advertisement with a higher VE preference MUST be preferred. 303 3.3. BGP Local Preference 305 Section 3.5 in [RFC4761] describes the use of BGP Local Preference in 306 path selection to choose a particular NLRI, where Local Preference 307 indicates the degree of preference for a particular VE. The use of 308 Local Preference is inadequate when VPLS PEs are spread across 309 multiple ASes as Local Preference is not carried across AS boundary. 311 For backwards compatibility, if VE preference as described in 312 Section 3.2 is used, then BGP Local Preference MUST be set to the 313 value of VE preference. Note that a Local Preference value of zero 314 for a VE is not valid unless 'D' bit in the control flags is set (see 315 [I-D.kothari-l2vpn-auto-site-id]) 317 3.4. Designated Forwarder Election 319 BGP-based multi-homing for VPLS relies on BGP path selection and VPLS 320 path selection. BGP path selection MUST be done by any BGP speaker 321 that is required to process VPLS NRLI advertisements. Thus, a Route 322 Reflector, [RFC4456], MUST support the procedures defined in this 323 document for BGP path selection for VPLS. Similarly, a BGP speaker 324 that is also a VPLS PE MUST also do BGP path selection for VPLS 325 advertisements. VPLS path selection, however, is done only by a VPLS 326 PE. The net result of doing both BGP and VPLS path selection is that 327 of electing a single designated forwarder among the set of PEs to 328 which a customer site is multi-homed. 330 In order to explain how these two path selection algorithms work, one 331 must refer to the format of the VPLS NLRI. This NLRI contains: 332 (Section 3.2.2) [RFC4761]. These components are referred as 334 RD, VE-ID, VBO, VBS and LB, respectively. In addition, a VPLS 335 advertisement contains some attributes, among them the BGP nexthop 336 (BNH), control flags (CF), VE Preference (VP), and Local Preference 337 (LP). Finally, the VPLS domain (DOM) is needed; this is not carried 338 explicitly in a VPLS advertisement, but is derived, typically from 339 BGP policies applied on Route Targets carried in the advertisement. 340 Taken all together, this yields: 342 344 Note that an advertisement with VE-ID = 0 is invalid. 346 Both BGP and VPLS path selection algorithms are described in two 347 stages. For each algorithm, the first stage divides all received 348 VPLS advertisements into buckets of relevant and comparable 349 advertisements. In this stage, advertisements may be discarded as 350 not being relevant to path selection. The second stage picks a 351 single "winner" from each bucket by repeatedly applying a tie- 352 breaking algorithm on a pair of advertisements from that bucket. The 353 tie-breaking rules are such that the order in which advertisements 354 are picked from the bucket does not affect the final result. Note 355 that this is a conceptual description of the process; an 356 implementation MAY choose to realize this differently as long as the 357 semantics are preserved. 359 3.4.1. BGP Path Selection 361 3.4.1.1. Bucketization 363 An advertisement 365 AD = 367 is discarded if DOM is not of interest to the BGP speaker. 368 Otherwise, AD is put into the bucket for . In other 369 words, the prefix to use for comparison in BGP path selection 370 consists of and only advertisements with exact same 371 are candidates for path selection. 373 3.4.1.2. Tie-breaking Rules 375 Given two advertisements AD1 and AD2 as below, the following tie- 376 breaking rules MUST be applied in the given order (note that the RDs, 377 VE-IDs and VBOs are the same): 379 AD1 = 380 AD2 = 382 where CF:D is the 'D' bit in the control flags 384 1. if (CF1:D != 1) AND (CF2:D == 1) AD1 wins; stop 385 if (CF1:D == 1) AND (CF2:D != 1) AD2 wins; stop 386 else continue 388 2. if (VP1 == 0) OR (VP2 == 0) continue 389 else if (VP1 > VP2) AD1 wins; stop 390 else if (VP1 < VP2) AD2 wins; stop 391 else continue 393 3. if (LP1 > LP2) AD1 wins; stop; 394 else if (LP1 < LP2) AD2 wins; stop; 395 else continue 397 4. if (BNH1 < BNH2) AD1 wins; stop; 398 else if (BNH1 > BNH2) AD2 wins; stop; 399 else AD1 and AD2 are equivalent; BGP will consider this as an 400 update 402 Note that all other BGP path selection criteria, such as IGP metric, 403 MUST be ignored while doing path selection for VPLS advertisements. 405 3.4.2. VPLS Path Selection 407 3.4.2.1. Bucketization 409 An advertisement 411 AD = 413 is discarded if DOM is not of interest to the VPLS PE. Otherwise, AD 414 is put into the bucket for . In other words, all 415 advertisements for a particular VPLS domain that have the same VE-ID 416 are candidates for VPLS path selection. 418 3.4.2.2. Tie-breaking Rules 420 Given two advertisements AD1 and AD2 as below, the following tie- 421 breaking rules MUST be applied in the given order (note that VE-IDs 422 are same). 424 AD1 = 425 AD2 = 427 where CF:D is the 'D' bit in the control flags 429 1. if (CF1:D != 1) AND (CF2:D == 1) AD1 wins; stop 430 if (CF1:D == 1) AND (CF2:D != 1) AD2 wins; stop 431 else continue 433 2. if (VP1 == 0) OR (VP2 == 0) continue 434 else if (VP1 > VP2) AD1 wins; stop 435 else if (VP1 < VP2) AD2 wins; stop 436 else continue 438 3. if (LP1 > LP2) AD1 wins; stop; 439 else if (LP1 < LP2) AD2 wins; stop; 440 else continue 442 4. if (BNH1 < BNH2) AD1 wins; stop; 443 else if (BNH1 > BNH2) AD2 wins; stop; 444 else AD1 and AD2 are from the same VPLS PE; AD1 and AD2 should 445 both be retained and an implementation MAY sort the 446 advertisements by other criteria such as VBO 448 If the final "winning" advertisement has VE-ID = 0 OR VBO = 0 OR VBS 449 = 0, it is discarded. 451 4. Multi-AS VPLS 453 Section 3.4 in [RFC4761] describes three methods (a, b and c) to 454 connect sites in a VPLS to PEs that are across multiple AS. Since 455 VPLS advertisements in method (a) do not cross AS boundaries, multi- 456 homing operations for method (a) remain exactly the same as they are 457 within as AS. However, both for method (b) and (c), VPLS 458 advertisements do cross AS boundary. Consider Figure 4 for inter-AS 459 VPLS with multi-homed customer sites. 461 AS1 AS2 462 ........ ........ 463 . . . . 464 ___ PE1 . . PE3 ___ 465 / : . . : \ 466 __/ : : : : \__ 467 CE1 __ : ASBR1 --- ASBR2 : __ CE2 468 \ : : : : / 469 \___ PE2 . . PE4 ___/ 470 . . . . 471 ........ ........ 473 Figure 4: Inter-AS VPLS 475 A customer has two sites, CE1 and CE2. CE1 is multi-homed to PE1 and 476 PE2 in AS1. CE2 is multi-homed to PE3 and PE4 in AS2. After running 477 path selection algorithm, all four VPLS PEs must elect the same set 478 of designated forwarder for CE1 and CE2. Since BGP Local Preference 479 is not carried across AS boundary, VE preference as described in 480 Section 3.2 MUST be used for carrying site preference in inter-AS 481 VPLS operations. 483 In method (b), there is control plane VPLS state on the ASBRs. As 484 explained in (Section 3.4.2) [RFC4761], ASBR1 will send a VPLS NLRI 485 received from PE1 to ASBR2 with new labels and itself as the BGP 486 nexthop. ASBR2 will send the received NLRI from ASBR1 to PE3 and PE4 487 with new labels and itself as the BGP nexthop. Since VPLS PEs use 488 BGP Local Preference in path selection, for backwards compatibility, 489 ASBR2 MUST set the Local Preference value in the VPLS advertisements 490 it sends to PE3 and PE4 to the VE preference value contained in the 491 VPLS advertisement it receives from ASBR1. ASBR1 MUST do the same 492 for the NLRIs it sends to PE1 and PE2. Thus, in method (b), ASBRs 493 MUST set the BGP Local Preference in VPLS advertisements to the VE 494 preference value, if specified in the NLRIs received from other 495 ASBRs. 497 In method (c), there is no state of any kind on the ASBRs. Thus, 498 multi-homing operations do not apply to ASBRs in this method. 500 5. Security Considerations 502 No new security issues are introduced beyond those that are described 503 in [RFC4761]. 505 6. IANA Considerations 507 At this time, this memo includes no request to IANA. 509 7. Acknowledgments 511 The authors would like to thank Chaitanya Kodeboyina, Yakov Rekhter, 512 Nischal Sheth and Amit Shukla for their insightful comments and 513 probing questions. 515 8. References 517 8.1. Normative References 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, March 1997. 522 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 523 (VPLS) Using BGP for Auto-Discovery and Signaling", 524 RFC 4761, January 2007. 526 [I-D.kothari-l2vpn-auto-site-id] 527 Kothari, B., Kompella, K., and T. IV, "Automatic 528 Generation of Site IDs for Virtual Private LAN Service", 529 draft-kothari-l2vpn-auto-site-id-00 (work in progress), 530 November 2007. 532 8.2. Informative References 534 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 535 Communities Attribute", RFC 4360, February 2006. 537 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 538 Networks (VPNs)", RFC 4364, February 2006. 540 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 541 Reflection: An Alternative to Full Mesh Internal BGP 542 (IBGP)", RFC 4456, April 2006. 544 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 545 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 546 RFC 4762, January 2007. 548 Authors' Addresses 550 Kireeti Kompella 551 Juniper Networks 552 1194 N. Mathilda Ave. 553 Sunnyvale, CA 94089 554 US 556 Email: kireeti@juniper.net 558 Bhupesh Kothari 559 Juniper Networks 560 1194 N. Mathilda Ave. 561 Sunnyvale, CA 94089 562 US 564 Email: bhupesh@juniper.net 566 Tom Spencer 567 AT&T 569 Email: tsiv@att.com 571 Full Copyright Statement 573 Copyright (C) The IETF Trust (2008). 575 This document is subject to the rights, licenses and restrictions 576 contained in BCP 78, and except as set forth therein, the authors 577 retain all their rights. 579 This document and the information contained herein are provided on an 580 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 581 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 582 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 583 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 584 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 585 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 587 Intellectual Property 589 The IETF takes no position regarding the validity or scope of any 590 Intellectual Property Rights or other rights that might be claimed to 591 pertain to the implementation or use of the technology described in 592 this document or the extent to which any license under such rights 593 might or might not be available; nor does it represent that it has 594 made any independent effort to identify any such rights. Information 595 on the procedures with respect to rights in RFC documents can be 596 found in BCP 78 and BCP 79. 598 Copies of IPR disclosures made to the IETF Secretariat and any 599 assurances of licenses to be made available, or the result of an 600 attempt made to obtain a general license or permission for the use of 601 such proprietary rights by implementers or users of this 602 specification can be obtained from the IETF on-line IPR repository at 603 http://www.ietf.org/ipr. 605 The IETF invites any interested party to bring to its attention any 606 copyrights, patents or patent applications, or other proprietary 607 rights that may cover technology that may be required to implement 608 this standard. Please address the information to the IETF at 609 ietf-ipr@ietf.org.