idnits 2.17.1 draft-kothari-l2vpn-auto-site-id-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 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 610. 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 (October 29, 2008) is 5656 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Kothari 3 Internet-Draft K. Kompella 4 Updates: 4761 (if approved) Juniper Networks 5 Intended status: Standards Track T. Spencer 6 Expires: May 2, 2009 AT&T 7 October 29, 2008 9 Automatic Generation of Site IDs for Virtual Private LAN Service 10 draft-kothari-l2vpn-auto-site-id-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 May 2, 2009. 37 Abstract 39 This document defines procedures that allow for Virtual Private LAN 40 Service (VPLS) provider edge (PE) devices that use BGP in the control 41 plane to automatically generate VE ID values in a consistent manner. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 2.1. Conventions Used in This Document . . . . . . . . . . . . 4 48 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3.1. Keeping track of site IDs in use . . . . . . . . . . . . . 5 50 3.2. Claiming an unused site ID . . . . . . . . . . . . . . . . 6 51 3.3. Collision Detection . . . . . . . . . . . . . . . . . . . 6 52 3.4. Resolving a Collision . . . . . . . . . . . . . . . . . . 7 53 3.4.1. New control flags in a VPLS site advertisement . . . . 7 54 3.4.2. Collision Resolution Rules . . . . . . . . . . . . . . 8 55 3.5. Interaction with BGP path selection . . . . . . . . . . . 8 56 3.6. Lifetime of a claimed site ID . . . . . . . . . . . . . . 9 57 3.7. Graceful Restart . . . . . . . . . . . . . . . . . . . . . 9 58 3.8. Timers used in this approach . . . . . . . . . . . . . . . 9 59 3.9. Interoperating with explicitly configured site IDs . . . . 10 60 3.10. Operation over a Multi-AS/Multi-provider MPLS core . . . . 11 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 68 Intellectual Property and Copyright Statements . . . . . . . . . . 14 70 1. Introduction 72 Service providers are actively deploying VPLS in their networks. 73 [RFC4761] describes mechanisms that allow VPLS PEs to use the BGP 74 protocol to automatically discover PE membership in VPLS domains and 75 to signal pseudowires required to carry VPLS traffic. These 76 mechanisms make VPLS much easier to deploy and manage compared to 77 when manual configuration of a full mesh of pseudowires is required. 79 A VPLS domain is an instantiation of an emulated LAN. A VPLS domain 80 consists of a number of VPLS instances, one on each PE to which a 81 customer site of the VPLS domain is attached. For each VPLS instance 82 on a given PE, [RFC4761] requires a service provider to configure a 83 route distinguisher (RD), a route target (RT) that identifies the 84 VPLS domain, and a VE ID that is used to uniquely identify the VPLS 85 site in the VPLS domain. The VE IDs configured must generally be 86 unique per VPLS domain. The exception to having unique VE IDs in a 87 VPLS domain is when a particular VPLS site is multi-homed to two or 88 more PEs. Having the same VE ID on all the PEs to which the site is 89 attached can be used to indicate multi-homing. 91 Site IDs are used by a VPLS PE to index into label blocks in order to 92 derive the transmit and receive pseudowire labels for the pseudowires 93 needed for transport of VPLS traffic. Thus, it is desirable for VE 94 ID allocation in each VPLS domain to be in dense clusters in order to 95 both minimize the number of label blocks advertised per VPLS domain 96 and to maximize the usage of labels in a label block. For example, 97 the set of VE IDs 1, 2, 3, 4, 5, 101, 102, 103, 104 and 105 is an 98 efficient allocation of VE IDs for a VPLS domain. 100 This document describes procedures by which PEs that are offering 101 VPLS service using BGP, as described in [RFC4761], can automatically 102 generate VE IDs in dense clusters, thereby easing the burden on the 103 service provider to configure and manage VE IDs per VPLS domain. The 104 procedures to automatically generate route distinguishers for VPLS or 105 IP VPN [RFC4364] instances on each PE are already well known. Thus, 106 from a control plane perspective, a service provider is only required 107 to provision route targets for each VPLS domain. 109 The procedures are designed to be backward compatible with the 110 current approach of explicitly configured VE IDs. In other words, it 111 is perfectly acceptable to have some sites in a VPLS domain with 112 explicitly configured VE IDs (for example, to indicate multi-homing), 113 while others have their VE IDs automatically generated. The 114 procedures are also designed to work not only in a single autonomous 115 system, but also in scenarios where VPLS domains span multiple 116 autonomous systems. 118 2. Terminology 120 Terminology as described in [RFC4761] is used in this document. 121 Additional terms are describe below. 123 VPLS domain: A VPLS domain represents a bridging domain 124 per customer. A Route Target community as 125 described in [RFC4360] is used to identify 126 all the PE routers participating in a 127 particular VPLS domain. 129 VPLS site: A VPLS site is a set of attachment circuits 130 (ports) on a PE that belong to the same 131 VPLS domain. Sites are referred to as 132 local or remote depending on whether they 133 belong to the PE router in context or to 134 one of the remote PE routers (network 135 peers). 137 Site ID: VE ID as encoded in VPLS BGP NLRI. 139 Real advertisement: A VPLS BGP NLRI that contains a non-zero 140 value for VE ID, VE block offset and VE 141 block size. Information contained in a 142 real advertisement is required to bring up 143 pseudowires between PEs in the same VPLS 144 domain. 146 Claim advertisement: A VPLS BGP NLRI that contains VE block 147 offset of zero and VE block size of zero. 148 Information contained in a claim 149 advertisement is insufficient to bring up 150 pseudowires between PEs in the same VPLS 151 domain. 153 2.1. Conventions Used in This Document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 3. Solution 161 The central idea of this solution is that within a VPLS domain, each 162 PE that is configured for automatic negotiation of site identifiers 163 will allocate an unused site ID for the VPLS site configured on the 164 PE. It accomplishes this by keeping track of all site IDs used 165 within the VPLS domain based on received advertisements. A Route 166 Target community (RT), as described in [RFC4360], is used to identify 167 all the PE routers participating in a particular VPLS domain. When 168 the PE needs a new site ID for an RT, it picks one of the unused site 169 IDs for that RT and tries to claim it for a certain time period by a 170 "claim advertisement" for this site ID. A collision occurs if this 171 PE receives another advertisement within this time period with the 172 same site ID and route target. 174 If no collision occurs, the PE takes ownership of the claimed site ID 175 by a real advertisement for that site ID, and begins using it 176 (establishing pseudowires, etc.). In case of a collision, the PE 177 runs procedures as outlined in this document to resolve the 178 collision, whereby it would either use the site ID or pick a new one 179 based on whether it won or lost the collision resolution. 181 It is expected that the chance of a collision is small, especially if 182 optimizations such as those described in this document are 183 implemented. 185 The following sections provide details on the procedures required for 186 automatic negotiation of site IDs among PEs participating in a VPLS 187 domain. 189 3.1. Keeping track of site IDs in use 191 When a PE comes up, it SHOULD wait for time period T1 to receive 192 advertisements from all other PEs participating in the same VPLS 193 domain. Similarly, when a new VPLS site is configured, it SHOULD 194 wait for time period T2 to receive advertisements from all other PEs 195 participating in the same VPLS domain. For either of these, a PE may 196 use BGP route refresh as described in [RFC2918] or other similar 197 mechanisms. 199 The time to wait (T1 or T2) to receive relevant information can be 200 based on configurable timers in addition to implementation specific 201 heuristics. For example, if BGP End-of-RIB marker functionality as 202 described in [RFC4724] is in use, the PE knows exactly when it has 203 received all VPLS advertisements after it has come up. 205 A PE synthesizes a list of site IDs in use per route target from the 206 advertisements it receives from other PEs. Note that maintaining a 207 list of site IDs in use within a VPLS domain adds very little extra 208 state on the VPLS PE since a VPLS PE is required to keep all VPLS 209 advertisements for configured route targets. 211 When all advertisements for a site with a particular site ID are 212 withdrawn, the site ID is deemed to be no longer in use, and MUST be 213 removed from the list of used site IDs. Note that a PE may advertise 214 a single site using multiple advertisements with each advertisement 215 carrying the label block to be used by a different set of remote 216 sites in the VPLS domain. If the site is multi-homed, multiple PEs 217 may advertise the same site ID. 219 3.2. Claiming an unused site ID 221 When either timer T1 or T2 expires, a PE SHOULD pick an unused site 222 ID based on the list of site IDs in use within that VPLS domain. To 223 indicate its interest in the selected site ID, a PE MUST send a 224 "claim advertisement" for this site ID to all other PEs participating 225 in the same VPLS domain. A VPLS BGP NLRI, as described in [RFC4761], 226 for a claim advertisement MUST contain a site ID that a PE is 227 interested in, a block offset of zero and a block size of zero. 229 Optimizations are possible to reduce the chance of collisions when 230 selecting an unused site ID. For example, an implementation could 231 determine a subset of unused site IDs and randomly select one of them 232 instead of always selecting the unused site ID with the lowest value. 233 An implementation might also decide to use heuristics designed to 234 minimize the number of label blocks per VPLS domain by selecting an 235 unused site ID that falls in the range of VPLS site advertisements 236 from other PEs. 238 3.3. Collision Detection 240 After a claim advertisement has been send to all other PEs in a VPLS 241 domain, a PE SHOULD wait for time period T3 to detect any collision 242 of site ID. 244 A collision occurs if a PE receives any advertisement that contains 245 the same site ID that was send in the claim advertisement. In case 246 of a collision, a PE MUST follow the collision resolution procedures 247 described in Section 3.4. 249 If a PE does not receive any advertisement with the same site ID from 250 other PEs within time interval T3, the PE can then start using the 251 site ID it claimed for "real advertisements". A BGP VPLS NLRI for a 252 real advertisement MUST contain a valid site ID, a non-zero block 253 offset and a non-zero block size in addition to valid label base 254 value. Note that a claim advertisement contains a block offset and a 255 block size of zero. Thus, a PE MUST withdraw a claim advertisement 256 it previously advertised after it has send a real advertisement for 257 its site ID. 259 Even after a PE starts using the site ID, it is still possible for it 260 to receive advertisements from other PEs using the same site ID. 262 This can happen for example, if two PEs are trying to claim the same 263 site ID, but neither has received each other's claim advertisements 264 within interval interval T3. The collision resolution procedures 265 described in Section 3.4 will handle this case as well. 267 3.4. Resolving a Collision 269 When a PE that is using a site ID or trying to claim it for its use 270 detects a collision, it MUST run collision resolution procedures to 271 resolve the collision. The collision could be caused by another PE 272 using the site ID or trying to claim the site ID for its use. The 273 collision is resolved in favor of the PE that has a better site 274 advertisement. 276 Two new control flags are defined in Section 3.4.1 and collision 277 resolution rules are described in Section 3.4.2 279 3.4.1. New control flags in a VPLS site advertisement 281 Two new control flags are proposed in this document. 283 1. 'A' (Automatic): Indicates whether an advertisement is for a site 284 with explicit site ID configuration or with automatic site ID 285 negotiation. The bit MUST be set to one in both a claim and a 286 real advertisement for a site that is negotiating site ID by 287 using procedures described in this document, otherwise the bit 288 MUST be set to zero. 290 2. 'D' (Down): Indicates connectivity status between a CE site and a 291 VPLS PE. The bit MUST be set to one if all the attachment 292 circuits connecting a CE site to a VPLS PE are down. 294 Figure 1 shows the position of 'A' and 'D' bits in the control flags 295 field. 297 Control Flags Bit Vector 299 0 1 2 3 4 5 6 7 300 +-+-+-+-+-+-+-+-+ 301 |D|A|Z|Z|Z|Z|C|S| (Z = MUST Be Zero) 302 +-+-+-+-+-+-+-+-+ 304 Figure 1 306 3.4.2. Collision Resolution Rules 308 The algorithm to compare two site advertisements with the same site 309 ID is as follows: 311 1. An advertisement with the 'A' bit clear in the control flags is 312 always better than an advertisement with the A bit set to one. 314 2. For advertisements with the same A bit value, a real 315 advertisement is always better than a claim advertisement. 317 3. Between real advertisements, an advertisement with the higher BGP 318 local preference is better. Similarly, between claim 319 advertisements, an advertisement with the higher BGP local 320 preference is better. 322 4. For advertisements with the same BGP local preference value, an 323 advertisement with the lowest BGP next hop value is better. 325 The rules above MUST be applied in the order specified. The rules 326 will pick the best advertisement in a deterministic manner, and the 327 PE that has the best advertisement will end up using the site ID. 329 The PEs that have worse advertisements must withdraw all 330 advertisements for their site ID and SHOULD try to claim another 331 unused site ID for their use. Optimizations are possible to reduce 332 chance of further collisions. It is recommended that a PE that lost 333 a collision resolution wait for a short time period before making an 334 attempt to claim another site ID. A PE that has experienced multiple 335 collisions in succession could consider to select an unused site ID 336 that does not fall within the range of other PEs label block 337 advertisements, even though this would potentially result in the 338 expansion of existing label blocks from other PEs. 340 3.5. Interaction with BGP path selection 342 In order to avoid unnecessary interaction between the rules in the 343 previous sections and those of BGP path selection, it is recommended 344 that PEs use unique route distinguishers (RDs) when advertising VPLS 345 site information. This will prevent BGP route reflectors (RRs) from 346 inadvertently filtering VPLS site advertisement information that the 347 PEs need to receive. The procedures to automatically generate unique 348 route distinguishers for VPLS or IP VPN [RFC4364] instances on each 349 PE are already well known. 351 3.6. Lifetime of a claimed site ID 353 The lifetime of a claimed site ID is the duration for which the site 354 is being advertised by the PE using a real advertisement. In other 355 words, if all advertisements for a site that is allocated an 356 automatically generated site ID are withdrawn, the site ID is 357 implicitly released. 359 If all interfaces that connect a VPLS site to a PE are down, VPLS 360 requires that the PE signal this event to other PEs by either 361 withdrawing all site advertisements, or by some other means. Since 362 withdrawing all site advertisements for a site with an automatically 363 generated site ID has a side effect of relinquishing the site ID, it 364 is RECOMMENDED to re-advertise the site advertisements with a "down" 365 bit ('D' bit) set to one in the control flags instead of withdrawing 366 the advertisements. Upon receiving a site advertisement with the 'D' 367 bit set to one, a PE SHOULD remove all pseudowires to the advertising 368 PE for this site ID, but MUST still consider the site ID in the 369 advertisement to be in use. However since the new 'D' bit will not 370 be understood by older implementations, a configurable knob should be 371 provided in newer implementations for backward compatibility to force 372 the withdrawal of site advertisements when all attachment circuits 373 connecting a site to the PE go down. 375 3.7. Graceful Restart 377 When graceful restart procedures are in use for VPLS, a restarting PE 378 SHOULD select the same site ID that it used before the restart. If a 379 PE selects a different site ID than the one it used before the 380 restart, VPLS forwarding will be disrupted as all other PEs within 381 the same VPLS domain will bring down the pseudowires that were 382 established based on the old site ID. 384 Without graceful restart, a restarting PE SHOULD use the procedures 385 defined in this document for site ID negotiation. 387 3.8. Timers used in this approach 389 The procedures described in this document relies on three timers. It 390 is RECOMMENDED that these timers be configurable. A brief 391 description of each timer along with default values for each is given 392 below. Note that the default values are worst case values and as 393 such the corresponding events could be triggered by implementation 394 specific heuristics even before the corresponding timers expire. 396 o T1: time to wait at startup to receive all VPLS information for 397 configured route targets from other PEs. If End-of-RIB marker 398 functionality [RFC4724] is in use, the PE could terminate its wait 399 earlier than T1 if it receives End-of-RIB markers for VPLS NLRI 400 from all other BGP peers. The default value for T1 is recommended 401 to be 2 minutes. 403 o T2: time to wait to receive VPLS information for a newly 404 configured route target or a newly configured site for automatic 405 site ID negotiation. The default value for T2 is recommended to 406 be 20 seconds. 408 o T3: time to wait after issuing a "claim advertisement" before the 409 PE can start using the site ID if it does not hear a competing 410 claim. If the PE hears a competing claim within this time 411 interval, it runs collision resolution procedures. The default 412 value for T3 is recommended to be 30 seconds. 414 With the default values as specified above, a newly configured site 415 on an operational PE will take T2 + T3 = 50 seconds before it can 416 claim a site ID and start using it, assuming that there are no 417 collisions with other PEs trying to use the same site ID. Similarly 418 a PE that is restarting will take T1 + T3 = 150 seconds in the worst 419 case before it can claim site IDs for all its sites and start using 420 them, assuming that there are no collisions with other PEs. 422 3.9. Interoperating with explicitly configured site IDs 424 The solution presented in this document allows for automatic 425 generation of unique site IDs per VPLS domain. However the service 426 provider might want to explicitly configure site IDs in the network 427 for the following reasons: 429 o When a site is multi-homed to two or more PEs, then the site MUST 430 be configured with the same site ID on all the PEs. Since the 431 solution presented here always generates unique site IDs, a 432 service provider has to explicitly configure site IDs for multi- 433 homed sites. 435 o The service provider might have PEs in the network that do not 436 support the functionality for automatic generation of site IDs. 437 This could be because the service provider network is multi-vendor 438 and one or more vendors do not support this functionality, or 439 because some PEs have older versions of software running on them 440 that do not support the new functionality. 442 The procedures described in this document for sites with automatic 443 negotiation of site IDs will interoperate with sites with explicit 444 site configuration. Sites with explicitly configured site IDs will 445 always use the site ID as configured. For example, if a PE detects 446 that one of the automatically generated site IDs that it is already 447 using (or in the process of claiming) conflicts with an explicit site 448 ID, it will stop using the site ID by withdrawing all advertisements 449 with this site ID and try to claim another available site ID for its 450 use. This behavior is achieved by the first rule in the site 451 advertisement comparison algorithm that mandates that site 452 advertisements with explicitly configured site IDs always win over 453 site advertisements with automatically generated site IDs. In order 454 for PEs to distinguish between explicitly configured and 455 automatically generated site IDs, PEs that use automatically 456 generated site IDs MUST set a new 'A' bit in the control flags bit- 457 vector in advertisements for sites using automatically generated site 458 IDs. 460 The compatibility of this approach with implementations that do not 461 support this functionality also relies on these implementations 462 ignoring claim advertisements. As explained in Section 3.2, a VPLS 463 BGP NLRI for a claim advertisements contains a label block size of 464 zero and a block offset of zero. An implementation that do not 465 support automatic negotiation of site IDs SHOULD ignore an 466 advertisement that has either a block size of zero or a block offset 467 of zero. A claim advertisement does not have any valid labels 468 advertised with it due to the block size of zero. In addition the 469 block offset of zero is an invalid block offset for a real 470 advertisement. Thus, a claim advertisement cannot be used by a 471 remote PE to bring up a pseudowire to the site advertising the claim. 473 Also see the note on the 'D' bit at the end of Section 3.6. 475 3.10. Operation over a Multi-AS/Multi-provider MPLS core 477 The solution presented in this document works over a multi-AS and 478 multi-provider core. 480 Section 3.4 in [RFC4761] describes three methods (a, b and c) to 481 connect sites in a VPLS to PEs that are across multiple AS. Since 482 VPLS advertisements in method (a) do not cross AS boundaries, 483 procedures defined in this document for automatic site ID work in 484 exactly the same manner as they work within an AS. In methods (b) 485 and (c), the VPLS advertisement do cross AS boundaries, but the VE ID 486 contained in the VPLS BGP NLRI is not changed by the intermediate 487 ASBRs or RRs if any. Thus, each VPLS PE will receive site 488 advertisements from all other PEs for each VPLS domain, and as 489 described in this document, each PE will synthesize a list of site 490 IDs in use per VPLS domain based on the remote PEs site 491 advertisements. In such scenarios, since the advertisements have to 492 cross AS boundaries, it is recommended to increase the time that a PE 493 waits to hear advertisements from other PEs, both when it starts up 494 (T1, T2) and when it waits to hear competing claims after it has 495 issued a claim of its own (T3). 497 Note that this solution only ensures that automatically generated 498 site IDs are unique across AS boundaries. However, managing 499 uniqueness of explicitly configured site IDs across multiple AS is 500 outside the scope of this document. 502 4. Security Considerations 504 The procedures defined in this document allow VPLS PEs to 505 automatically generate site IDs per VPLS domain without the service 506 provider having to explicitly configure them. As such, no new 507 security issues are raised beyond those that already exist in 508 networks that use BGP-4 for exchanging VPN and VPLS membership and 509 signaling information. Moreover, since real advertisements have 510 priority over claim advertisements, the procedures defined in this 511 document do not introduce new means of disrupting VPLS traffic. 513 5. IANA Considerations 515 At this time, this memo includes no request to IANA. 517 6. Acknowledgments 519 The authors would like to thank Chaitanya Kodeboyina, Nischal Sheth, 520 Yakov Rekhter, Amit Shukla and others for the useful discussions on 521 the subject, their review and comments. 523 7. References 525 7.1. Normative References 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, March 1997. 530 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 531 September 2000. 533 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 534 (VPLS) Using BGP for Auto-Discovery and Signaling", 535 RFC 4761, January 2007. 537 7.2. Informative References 539 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 540 Communities Attribute", RFC 4360, February 2006. 542 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 543 Networks (VPNs)", RFC 4364, February 2006. 545 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 546 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 547 January 2007. 549 Authors' Addresses 551 Bhupesh Kothari 552 Juniper Networks 553 1194 N. Mathilda Ave. 554 Sunnyvale, CA 94089 555 US 557 Email: bhupesh@juniper.net 559 Kireeti Kompella 560 Juniper Networks 561 1194 N. Mathilda Ave. 562 Sunnyvale, CA 94089 563 US 565 Email: kireeti@juniper.net 567 Thomas Spencer 568 AT&T 570 Email: tsiv@att.com 572 Full Copyright Statement 574 Copyright (C) The IETF Trust (2008). 576 This document is subject to the rights, licenses and restrictions 577 contained in BCP 78, and except as set forth therein, the authors 578 retain all their rights. 580 This document and the information contained herein are provided on an 581 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 582 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 583 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 584 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 585 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 586 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 588 Intellectual Property 590 The IETF takes no position regarding the validity or scope of any 591 Intellectual Property Rights or other rights that might be claimed to 592 pertain to the implementation or use of the technology described in 593 this document or the extent to which any license under such rights 594 might or might not be available; nor does it represent that it has 595 made any independent effort to identify any such rights. Information 596 on the procedures with respect to rights in RFC documents can be 597 found in BCP 78 and BCP 79. 599 Copies of IPR disclosures made to the IETF Secretariat and any 600 assurances of licenses to be made available, or the result of an 601 attempt made to obtain a general license or permission for the use of 602 such proprietary rights by implementers or users of this 603 specification can be obtained from the IETF on-line IPR repository at 604 http://www.ietf.org/ipr. 606 The IETF invites any interested party to bring to its attention any 607 copyrights, patents or patent applications, or other proprietary 608 rights that may cover technology that may be required to implement 609 this standard. Please address the information to the IETF at 610 ietf-ipr@ietf.org.