idnits 2.17.1 draft-ietf-l2vpn-vpls-multihoming-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 20, 2009) is 5272 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) == Unused Reference: 'RFC4447' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'RFC4446' is defined on line 739, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pwe3-redundancy-bit' is defined on line 756, but no explicit reference was found in the text == Unused Reference: 'RFC4456' is defined on line 769, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-bit-01 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 L2VPN Working Group B. Kothari 2 Internet Draft K. Kompella 3 Intended status: Standards Track Juniper Networks 4 Expires: May 2010 W. Henderickx 5 F. Balus 6 Alcatel-Lucent 7 J. Uttaro 8 AT&T 9 November 20, 2009 11 BGP based Multi-homing in Virtual Private LAN Service 12 draft-ietf-l2vpn-vpls-multihoming-00 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on May 20, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private 60 Network (VPN) that gives its customers the appearance that their 61 sites are connected via a Local Area Network (LAN). It is often 62 required for the Service Provider (SP) to give the customer redundant 63 connectivity to some sites, often called "multi-homing". This memo 64 shows how BGP-based multi-homing can be offered in the context of LDP 65 and BGP VPLS solutions. 67 Table of Contents 69 1. Introduction...................................................3 70 1.1. General Terminology.......................................4 71 1.2. Conventions used in this document.........................4 72 2. Background.....................................................4 73 2.1. Scenarios.................................................4 74 2.2. VPLS Multi-homing Considerations..........................5 75 3. Multi-homing Operation.........................................6 76 3.1. Provisioning Model........................................6 77 3.2. Multi-homing NLRI.........................................6 78 3.3. Designated Forwarder Election.............................7 79 3.3.1. Attributes...........................................7 80 3.3.2. Variables Used.......................................8 81 3.3.2.1. RD..............................................8 82 3.3.2.2. MH-ID...........................................8 83 3.3.2.3. VBO.............................................8 84 3.3.2.4. DOM.............................................8 85 3.3.2.5. ACS.............................................8 86 3.3.2.6. PREF............................................8 87 3.3.2.7. PE-ID...........................................9 89 3.3.3. Election Procedures..................................9 90 3.3.3.1. Bucketization for BGP DF Election..............10 91 3.3.3.2. Bucketization for VPLS DF Election.............10 92 3.3.3.3. Tie-breaking Rules.............................10 93 3.4. DF Election on PEs.......................................11 94 4. Multi-AS VPLS.................................................12 95 4.1. Route Origin Extended Community..........................12 96 4.2. VPLS Preference..........................................12 97 4.3. Use of BGP-MH attributes in Inter-AS Methods.............13 98 4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS 99 Information between ASBRs..................................14 100 4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of 101 VPLS Information between ASes..............................15 102 5. MAC Flush Operations..........................................15 103 5.1. MAC List Flush...........................................16 104 5.2. Implicit MAC Flush.......................................16 105 6. Backwards Compatibility.......................................16 106 6.1. BGP based VPLS...........................................17 107 6.2. LDP VPLS with BGP Auto-discovery.........................17 108 7. Security Considerations.......................................17 109 8. IANA Considerations...........................................17 110 9. References....................................................17 111 9.1. Normative References.....................................17 112 9.2. Informative References...................................18 113 10. Acknowledgments..............................................18 115 1. Introduction 117 Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private 118 Network (VPN) that gives its customers the appearance that their 119 sites are connected via a Local Area Network (LAN). It is often 120 required for a Service Provider (SP) to give the customer redundant 121 connectivity to one or more sites, often called "multi-homing". 122 [RFC4761] explains how VPLS can be offered using BGP for auto- 123 discovery and signaling; section 3.5 of that document describes how 124 multi-homing can be achieved in this context. [I-D.ietf-l2vpn- 125 signaling] explains how VPLS can be offered using BGP for auto- 126 discovery (BGP-AD) and [RFC4762] explains how VPLS can be offered 127 using LDP for signaling. This document provides a BGP-based multi- 128 homing solution applicable to both BGP and LDP VPLS technologies. 129 Note that BGP MH can be used for LDP VPLS without the use of the BGP- 130 AD solution. 132 Section 2 lays out some of the scenarios for multi-homing, other ways 133 that this can be achieved, and some of the expectations of BGP-based 134 multi-homing. Section 3 defines the components of BGP-based multi- 135 homing, and the procedures required to achieve this. Section 7 may 136 someday discuss security considerations. 138 1.1. General Terminology 140 Some general terminology is defined here; most is from [RFC4761], 141 [RFC4762] or [RFC4364]. Terminology specific to this memo is 142 introduced as needed in later sections. 144 A "Customer Edge" (CE) device, typically located on customer 145 premises, connects to a "Provider Edge" (PE) device, which is owned 146 and operated by the SP. A "Provider" (P) device is also owned and 147 operated by the SP, but has no direct customer connections. A "VPLS 148 Edge" (VE) device is a PE that offers VPLS services. 150 A VPLS domain represents a bridging domain per customer. A Route 151 Target community as described in [RFC4360] is typically used to 152 identify all the PE routers participating in a particular VPLS 153 domain. A VPLS site is a grouping of ports on a PE that belong to the 154 same VPLS domain. A Multi-homed (MH) site is uniquely identified by a 155 MH site ID (MH-ID). Sites are referred to as local or remote 156 depending on whether they are configured on the PE router in context 157 or on one of the remote PE routers (network peers). 159 1.2. Conventions used in this document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 2. Background 167 This section describes various scenarios where multi-homing may be 168 required, and the implications thereof. It also describes some of the 169 singular properties of VPLS multi-homing, and what that means from 170 both an operational point of view and an implementation point of 171 view. There are other approaches for providing multi-homing such as 172 Spanning Tree Protocol, and this document specifies use of BGP for 173 multi-homing. Comprehensive comparison among the approaches is 174 outside the scope of this document. 176 2.1. Scenarios 178 The most basic scenario is shown in Figure 1. 180 CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant 181 connectivity. 183 ............... 184 . . ___ CE2 185 ___ PE1 . / 186 / : PE3 187 __/ : Service : 188 CE1 __ : Provider PE4 189 \ : : \___ CE3 190 \___ PE2 . 191 . . 192 ............... 194 Figure 1 Scenario 1 196 CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant 197 connectivity. However, CE4, which is also in the same VPLS domain, is 198 single-homed to just PE1. 200 CE4 ------- ............... 201 \ . . ___ CE2 202 ___ PE1 . / 203 / : PE3 204 __/ : Service : 205 CE1 __ : Provider PE4 206 \ : : \___ CE3 207 \___ PE2 . 208 . . 209 ............... 211 Figure 2 Scenario 2 213 2.2. VPLS Multi-homing Considerations 215 The first (perhaps obvious) fact about a multi-homed VPLS CE, such as 216 CE1 in Figure 1 is that if CE1 is an Ethernet switch or bridge, a 217 loop has been created in the customer VPLS. This is a dangerous 218 situation for an Ethernet network, and the loop must be broken. Even 219 if CE1 is a router, it will get duplicates every time a packet is 220 flooded, which is clearly undesirable. 222 The next is that (unlike the case of IP-based multi-homing) only one 223 of PE1 and PE2 can be actively sending traffic, either towards CE1 or 224 into the SP cloud. That is to say, load balancing techniques will not 225 work. All other PEs MUST choose the same designated forwarder for a 226 multi-homed site. Call the PE that is chosen to send traffic to/from 227 CE1 the "designated forwarder". 229 In Figure 2, CE1 and CE4 must be dealt with independently, since CE1 230 is dual-homed, but CE4 is not. 232 3. Multi-homing Operation 234 This section describes procedures for electing a designated forwarder 235 among the set of PEs that are multi-homed to a customer site. The 236 procedures described in this section are applicable to BGP based 237 VPLS, LDP based VPLS with BGP-AD or a VPLS that contains a mix of 238 both BGP and LDP signaled PWs. 240 3.1. Provisioning Model 242 Figure 1 shows a customer site, CE1, multi-homed to two VPLS PEs, PE1 243 and PE2. In order for all VPLS PEs within the same VPLS domain to 244 elect one of the multi-homed PEs as the designated forwarder, an 245 indicator that the PEs are multi-homed to the same customer site is 246 required. This is achieved by assigning the same multi-homed site ID 247 (MH-ID) on PE1 and PE2 for CE1. When remote VPLS PEs receive NLRI 248 advertisement from PE1 and PE2 for CE1, the two NLRI advertisements 249 for CE1 are identified as candidates for designated forwarder 250 selection due to the same MH-ID. Thus, same MH-ID SHOULD be assigned 251 on all VPLS PEs that are multi-homed to the same customer site. Note 252 that a MH-ID=0 is invalid and a PE should discard such an 253 advertisement. 255 3.2. Multi-homing NLRI 257 Section 3.2.2 in [RFC4761] describes the encoding of the BGP VPLS 258 NLRI. This NLRI contains fields VE-ID, VE block offset, VE block size 259 and label base. For multi-homing operation, the same NLRI is used for 260 identifying the multi-homed customers sites. The VE-ID field in the 261 NLRI is set to MH-ID; the VE block offset, VE block size and label 262 base are set to zero. Thus, the NLRI contains 2 octets indicating the 263 length, 8 octets for Route Distinguisher, 2 octets for MH-ID and 7 264 octets with value zero. 266 Figure 2 shows two customer sites, CE1 and CE4, connected to PE1 with 267 CE1 multi-homed to PE1 and PE2. CE4 does not require special 268 addressing, being associated with the base VPLS instance identified 269 by the VSI-ID for LDP VPLS and VE-ID for BGP VPLS. However, CE1 which 270 is multi-homed to PE1 and PE2 requires configuration of MH-ID and 271 both PE1 and PE2 MUST be provisioned with the same MH-ID for CE1. It 272 is valid to have non-zero VE block offset, VE block size and label 273 base in the VPLS NLRI for a multi-homed site. However, multi-homing 274 operations in such a case are outside the scope of this document. 276 3.3. Designated Forwarder Election 278 BGP-based multi-homing for VPLS relies on BGP DF election and VPLS DF 279 election. The net result of doing both BGP and VPLS DF election is 280 that of electing a single designated forwarder (DF) among the set of 281 PEs to which a customer site is multi-homed. All the PEs that are 282 elected as non-designated forwarders MUST keep their attachment 283 circuit to the multi-homed CE in blocked status (no forwarding). 285 These election algorithms operate on VPLS advertisements, which 286 include both the NLRI and attached BGP attributes. In order to 287 simplify the explanation of these algorithms, we will use a number of 288 variables derived from fields in the VPLS advertisement. These 289 variables are: RD, MH-ID, VBO, DOM, ACS, PREF and PE-ID. The notation 290 ADV -> means that from a 291 received VPLS advertisement ADV, the respective variables were 292 derived. The following sections describe two attributes needed for DF 293 election, then describe the variables and how they are derived from 294 fields in VPLS advertisement ADV, and finally describe how DF 295 election is done. 297 3.3.1. Attributes 299 The procedures below refer to two attributes: the Route Origin 300 community (see Section 4.1) and the L2-info community (see Section 301 4.2.1). These attributes are required for inter-AS operation; for 302 generality, the procedures below show how they are to be used. The 303 procedures also say how to handle the case that either or both are 304 not present. 306 3.3.2. Variables Used 308 3.3.2.1. RD 310 RD is simply set to the Route Distinguisher field in the NLRI part of 311 ADV. 313 3.3.2.2. MH-ID 315 MH-ID is simply set to the VE-ID field in the NLRI part of ADV. 317 3.3.2.3. VBO 319 VBO is simply set to the VE Block Offset field in the NLRI part of 320 ADV. This field will typically be zero. 322 3.3.2.4. DOM 324 This variable, indicating the VPLS domain to which ADV belongs, is 325 derived by applying BGP policy to the Route Target extended 326 communities in ADV. The details of how this is done are outside the 327 scope of this document. 329 3.3.2.5. ACS 331 ACS is the status of the attachment circuits for a given site of a 332 VPLS. ACS = 1 if all attachment circuits for the site are down, and 0 333 otherwise. 335 For BGP-based Multi-homing, ADV MUST contain an L2-info extended 336 community; within this community are control flags. One of these 337 flags is the 'D' bit, described in [I-D.kothari-l2vpn-auto-site-id]. 338 ACS is set to the value of the 'D' bit in ADV. 340 3.3.2.6. PREF 342 PREF is derived from the Local Preference (LP) attribute in ADV as 343 well as the VPLS Preference field (VP) in the L2-info extended 344 community. If the Local Preference attribute is missing, LP is set to 345 0; if the L2-info community is missing, VP is set to 0. The following 346 table shows how PREF is computed from LP and VP. 348 +---------+---------------+----------+------------------------------+ 349 | VP | LP Value | PREF | Comment | 350 | Value | | Value | | 351 +---------+---------------+----------+------------------------------+ 352 | 0 | 0 | 0 | malformed advertisement, | 353 | | | | unless ACS=1 | 354 | | | | | 355 | 0 | 1 to (2^16-1) | LP | backwards compatibility | 356 | | | | | 357 | 0 | 2^16 to | (2^16-1) | backwards compatibility | 358 | | (2^32-1) | | | 359 | | | | | 360 | >0 | LP same as VP | VP | Implementation supports VP | 361 | | | | | 362 | >0 | LP != VP | 0 | malformed advertisement | 363 +---------+---------------+----------+------------------------------+ 364 Figure 3 PREF table 366 3.3.2.7. PE-ID 368 If ADV contains a Route Origin (RO) community (see Section 4.1) with 369 type 0x01, then PE-ID is set to the Global Administrator sub-field of 370 the RO. Otherwise, if ADV has an ORIGINATOR_ID attribute, then PE-ID 371 is set to the ORIGINATOR_ID. Otherwise, PE-ID is set to the BGP 372 Identifier. 374 3.3.3. Election Procedures 376 The election procedures described in this section apply equally to 377 BGP VPLS and LDP VPLS. 379 Election occurs in two stages. The first stage divides all received 380 VPLS advertisements into buckets of relevant and comparable 381 advertisements. Distinction MUST NOT be made on whether the NLRI is a 382 multi-homing NLRI or not. In this stage, advertisements may be 383 discarded as not being relevant to DF election. The second stage 384 picks a single "winner" from each bucket by repeatedly applying a 385 tie-breaking algorithm on a pair of advertisements from that bucket. 386 The tie-breaking rules are such that the order in which 387 advertisements are picked from the bucket does not affect the final 388 result. Note that this is a conceptual description of the process; an 389 implementation MAY choose to realize this differently as long as the 390 semantics are preserved. 392 Note: these procedures supersede the tie breaking rules described in 393 (Section 9.1.2.2) [RFC4271] 395 3.3.3.1. Bucketization for BGP DF Election 397 An advertisement 399 ADV -> 401 is discarded if DOM is not of interest to the BGP speaker. Otherwise, 402 ADV is put into the bucket for . In other words, 403 the information in BGP DF election consists of 404 and only advertisements with exact same 405 are candidates for DF election. 407 3.3.3.2. Bucketization for VPLS DF Election 409 An advertisement 411 ADV -> 413 is discarded if DOM is not of interest to the VPLS PE. Otherwise, ADV 414 is put into the bucket for . In other words, all 415 advertisements for a particular VPLS domain that have the same MH-ID 416 are candidates for VPLS DF election. 418 3.3.3.3. Tie-breaking Rules 420 This section describes the tie-breaking rules for both BGP and VPLS 421 DF election. Tie-breaking rules for BGP DF election are applied to 422 candidate advertisements by any BGP speaker. Since RD must be same 423 for advertisements to be candidates for BGP DF election, use of 424 unique RDs will result in no candidate advertisements for BGP tie- 425 breaking rules and thus, a BGP speaker in such a case will simply not 426 do BGP DF election. Tie-breaking rules for VPLS DF election are 427 applied to candidate advertisements by all VPLS PEs and the actions 428 taken by VPLS PEs based on the VPLS DF election result are described 429 in Section 3.4. 431 Given two advertisements ADV1 and ADV2 from a given bucket, first 432 compute the variables needed for DF election: 434 ADV1 -> 436 ADV2 -> 438 Note that MH-ID1 = MH-ID2 and DOM1 = DOM2, since ADV1 and ADV2 came 439 from the same bucket. If this is for BGP DF election, RD1 = RD2 and 440 VBO1 = VBO2 as well. Then the following tie-breaking rules MUST be 441 applied in the given order. 443 1. if (ACS1 != 1) AND (ACS2 == 1) ADV1 wins; stop 445 if (ACS1 == 1) AND (ACS2 != 1) ADV2 wins; stop 447 else continue 449 2. if (PREF1 > PREF2) ADV1 wins; stop; 451 else if (PREF1 < PREF2) ADV2 wins; stop; 453 else continue 455 3. if (PE-ID1 < PE-ID2) ADV1 wins; stop; 457 else if (PE-ID1 > PE-ID2) ADV2 wins; stop; 459 else ADV1 and ADV2 are from the same VPLS PE 461 For BGP DF election, if there is no winner and ADV1 and ADV2 are from 462 the same PE, BGP DF election should simply consider this as an 463 update. 465 For VPLS DF election, if there is no winner and ADV1 and ADV2 are 466 from the same PE, a VPLS PE MUST retain both ADV1 and ADV2. 468 3.4. DF Election on PEs 470 DF election algorithm MUST be run by all multi-homed VPLS PEs. In 471 addition, all other PEs SHOULD also run the DF election algorithm. As 472 a result of the DF election, multi-homed PEs that loose the DF 473 election for a MH-ID MUST put the ACs associated with the MH-ID in 474 non-forwarding state. 476 DF election result on the egress PEs can be used in traffic 477 forwarding decision. Figure 2 shows two customer sites, CE1 and CE4, 478 connected to PE1 with CE1 multi-homed to PE1 and PE2. If PE1 is the 479 designated forwarder for CE1, based on the DF election result, PE3 480 can chose to not send unknown unicast and multicast traffic to PE2 as 481 PE2 is not the designated forwarder for any customer site and it has 482 no other single homed sites connected to it. 484 4. Multi-AS VPLS 486 This section describes multi-homing in an inter-AS context. 488 4.1. Route Origin Extended Community 490 Due to lack of information about the PEs that originate the VPLS 491 NLRIs in inter-AS operations, Route Origin Extended Community 492 [RFC4360] is used to carry the source PE's IP address. 494 To use Route Origin Extended Community for carrying the originator 495 VPLS PE's loopback address, the type field of the community MUST be 496 set to 0x01 and the Global Administrator sub-field MUST be set to the 497 PE's loopback IP address. 499 4.2. VPLS Preference 501 When multiple PEs are assigned the same site ID for multi-homing, it 502 is often desired to be able to control the selection of a particular 503 PE as the designated forwarder. Section 3.5 in [RFC4761] describes 504 the use of BGP Local Preference in path selection to choose a 505 particular NLRI, where Local Preference indicates the degree of 506 preference for a particular VE. The use of Local Preference is 507 inadequate when VPLS PEs are spread across multiple ASes as Local 508 Preference is not carried across AS boundary. A new field, VPLS 509 preference (VP), is introduced in this document that can be used to 510 accomplish this. VPLS preference indicates a degree of preference for 511 a particular customer site. VPLS preference is not mandatory for 512 intra-AS operation; the algorithm explained in Section 3.3 will work 513 with or without the presence of VPLS preference. 515 Section 3.2.4 in [RFC4761] describes the Layer2 Info Extended 516 Community that carries control information about the pseudowires. The 517 last two octets that were reserved now carries VPLS preference as 518 shown in Figure 3. 520 +------------------------------------+ 521 | Extended community type (2 octets) | 522 +------------------------------------+ 523 | Encaps Type (1 octet) | 524 +------------------------------------+ 525 | Control Flags (1 octet) | 526 +------------------------------------+ 527 | Layer-2 MTU (2 octet) | 528 +------------------------------------+ 529 | VPLS Preference (2 octets) | 530 +------------------------------------+ 532 Figure 4 Layer 2 Info Extended Community 534 A VPLS preference is a 2-octets unsigned integer. A value of zero 535 indicates absence of a VP and is not a valid preference value. This 536 interpretation is required for backwards compatibility. 537 Implementations using Layer2 Info Extended Community as described in 538 (Section 3.2.4) [RFC4761] MUST set the last two octets as zero since 539 it was a reserved field. 541 For backwards compatibility, if VP is used, then BGP Local Preference 542 MUST be set to the value of VP. Note that a Local Preference value of 543 zero for a MH-Site is not valid unless 'D' bit in the control flags 544 is set (see [I-D.kothari-l2vpn-auto-site-id]). In addition, Local 545 Preference value greater than or equal to 2^16 for VPLS 546 advertisements is not valid. 548 4.3. Use of BGP-MH attributes in Inter-AS Methods 550 Section 3.4 in [RFC4761] and section 4 in [I-D.ietf-l2vpn-signaling] 551 describe three methods (a, b and c) to connect sites in a VPLS to PEs 552 that are across multiple AS. Since VPLS advertisements in method (a) 553 do not cross AS boundaries, multi-homing operations for method (a) 554 remain exactly the same as they are within as AS. However, for method 555 (b) and (c), VPLS advertisements do cross AS boundary. This section 556 describes the VPLS operations for method (b) and method (c). Consider 557 Figure 5 for inter-AS VPLS with multi-homed customer sites. 559 4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS Information 560 between ASBRs 562 AS1 AS2 563 ........ ........ 564 CE2 _______ . . . . 565 ___ PE1 . . PE3 --- CE3 566 / : . . : 567 __/ : : : : 568 CE1 __ : ASBR1 --- ASBR2 : 569 \ : : : : 570 \___ PE2 . . PE4 ---- CE4 571 . . . . 572 ........ ........ 574 Figure 5 Inter-AS VPLS 576 A customer has four sites, CE1, CE2, CE3 and CE4. CE1 is multi-homed 577 to PE1 and PE2 in AS1. CE2 is single-homed to PE1. CE3 and CE4 are 578 also single homed to PE3 and PE4 respectively in AS2. Assume that in 579 addition to the base LDP/BGP VPLS addressing (VSI-IDs/VE-IDs), MH ID 580 1 is assigned for CE1. After running DF election algorithm, all four 581 VPLS PEs must elect the same designated forwarder for CE1 site. Since 582 BGP Local Preference is not carried across AS boundary, VPLS 583 preference as described in Section 4.2 MUST be used for carrying site 584 preference in inter-AS VPLS operations. 586 For Inter-AS method (b) ASBR1 will send a VPLS NLRI received from PE1 587 to ASBR2 with itself as the BGP nexthop. ASBR2 will send the received 588 NLRI from ASBR1 to PE3 and PE4 with itself as the BGP nexthop. Since 589 VPLS PEs use BGP Local Preference in DF election, for backwards 590 compatibility, ASBR2 MUST set the Local Preference value in the VPLS 591 advertisements it sends to PE3 and PE4 to the VPLS preference value 592 contained in the VPLS advertisement it receives from ASBR1. ASBR1 593 MUST do the same for the NLRIs it sends to PE1 and PE2. If ASBR1 594 receives a VPLS advertisement without a valid VPLS preference from a 595 PE within its AS, then ASBR1 MUST set the VPLS preference in the 596 advertisements to the Local Preference value before sending it to 597 ASBR2. Similarly, ASBR2 must do the same for advertisements without 598 VPLS Preference it receives from PEs within its AS. Thus, in method 599 (b), ASBRs MUST update the VPLS and Local Preference based on the 600 advertisements they receive either from an ASBR or a PE within their 601 AS. 603 In Figure 5, PE1 will send the VPLS advertisements, including the 604 ones for MH site CE1, with Route Origin Extended Community containing 605 its loopback address. PE2 will do the same. Even though PE3 receives 606 the VPLS advertisements from the same BGP nexthop, ASBR2, the source 607 PE address contained in the Route Origin Extended Community is 608 different for the VPLS advertisements received from PE1 and PE2, and 609 thus, PE3 can apply correctly the DF Election algorithm as the 610 resulting PE-IDs are different. 612 4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of VPLS 613 Information between ASes 615 In this method, there is a multi-hop E-BGP peering between the PEs or 616 Route Reflectors in AS1 and the PEs or Route Reflectors in AS2. There 617 is no VPLS state in either control or data plane on the ASBRs. 619 The multi-homing operations on the PEs in this method are exactly the 620 same as they are in intra-AS scenario. However, since Local 621 Preference is not carried across AS boundary, the translation of LP 622 to VP and vice versa MUST be done by RR, if RR is used to reflect 623 VPLS advertisements to other ASes. This is exactly the same as what a 624 ASBR does in case of method (b). A RR must set the VP to the LP value 625 in an advertisement before sending it to other ASes and must set the 626 LP to the VP value in an advertisement that it receives from other 627 ASes before sending to the PEs within the AS. 629 5. MAC Flush Operations 631 In a service provider VPLS network, customer MAC learning is confined 632 to PE devices and any intermediate nodes, such as a Route Reflector, 633 do not have any state for MAC addresses. 635 Topology changes either in the service provider's network or in 636 customer's network can result in the movement of MAC addresses from 637 one PE device to another. Such events can result into traffic being 638 dropped due to stale state of MAC addresses on the PE devices. Age 639 out timers that clear the stale state will resume the traffic 640 forwarding, but age out timers are typically in minutes, and 641 convergence of the order of minutes can severely impact customer's 642 service. To handle such events and expedite convergence of traffic, 643 flushing of affected MAC addresses is highly desirable. 645 This section describes the scenarios where VPLS flush is desirable 646 and the specific VPLS Flush TLVs that provide capability to flush the 647 affected MAC addresses on the PE devices. All operations described in 648 this section are in context of a particular VPLS domain and not 649 across multiple VPLS domains. Mechanisms for MAC flush are described 650 in [I-D.kothari-l2vpn-vpls-flush] for BGP based VPLS and in [RFC4762] 651 for LDP based VPLS. 653 5.1. MAC List Flush 655 If multiple customer sites are connected to the same PE, PE1 as shown 656 in Figure 2, and redundancy per site is desired when multi-homing 657 procedures described in this document are in effect, then it is 658 desirable to flush just the relevant MAC addresses from a particular 659 site when the site connectivity is lost. 661 To flush particular set of MAC addresses, a PE SHOULD originate a 662 flush message with MAC list that contains a list of MAC addresses 663 that needs to be flushed. In Figure 2, if connectivity between CE1 664 and PE1 goes down and if PE1 was the designated forwarder for CE1, 665 PE1 SHOULD send a list of MAC addresses that belong to CE1 to all its 666 BGP peers. 668 It is RECOMMENDED that in case of excessive link flap of customer 669 attachment circuit in a short duration, a PE should have a means to 670 throttle advertisements of flush messages so that excessive flooding 671 of such advertisements do not occur. 673 5.2. Implicit MAC Flush 675 When connectivity to a customer site is lost, remote PEs learn that a 676 particular site is no longer reachable. The local PE either withdraws 677 the VPLS NLRI that it previously advertised for the site or it sends 678 a BGP update message for the site's VPLS NLRI with the 'D' bit set. 680 If a remote PE detects that a multi-homed PE has transitioned from 681 being a DF to a non-DF, then the remote PE can choose to flush all 682 MAC addresses that it learned from the multi-homed PE transitioning 683 from DF to non-DF. Alternatively the remote PE may chose to react 684 when detecting the non-DF to DF transition for a multi-homed PE by 685 flushing in the related VPLS context all the MACs learned with the 686 exception of the MACs associated with the new DF PE. 688 6. Backwards Compatibility 690 No forwarding loops are formed when PEs or Route Reflectors that do 691 not support procedures defined in this section co exist in the 692 network with PEs or Route Reflectors that do support. 694 6.1. BGP based VPLS 696 As explained in this section, multi-homed PEs to the same customer 697 site MUST assign the same MH-ID and related NLRI SHOULD contain the 698 block offset, block size and label base as zero. Remote PEs that lack 699 support of multi-homing operations specified in this document will 700 fail to create any PWs for the multi-homed MH-IDs due to the label 701 value of zero and thus, the multi-homing NLRI should have no impact 702 on the operation of Remote PEs that lack support of multi-homing 703 operations specified in this document. 705 6.2. LDP VPLS with BGP Auto-discovery 707 The BGP-AD NLRI has a prefix length of 12 containing only a 8 bytes 708 RD and a 4 bytes VSI-ID. If a LDP VPLS PEs running BGP AD lacks 709 support of multi-homing operations specified in this document, it 710 SHOULD ignore a MH NLRI with the length field of 17. As a result it 711 will not ask LDP to create any PWs for the multi-homed Site-ID and 712 thus, the multi-homing NLRI should have no impact on LDP VPLS 713 operation. 715 7. Security Considerations 717 No new security issues are introduced beyond those that are described 718 in [RFC4761] and [RFC4762]. 720 8. IANA Considerations 722 At this time, this memo includes no request to IANA. 724 9. References 726 9.1. Normative References 728 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 729 Requirement Levels", BCP 14, RFC 2119, March 1997. 731 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 732 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 733 4761, January 2007. 735 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 736 Heron, "Pseudowire Setup and Maintenance Using the Label 737 Distribution Protocol (LDP)", RFC 4447, April 2006. 739 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 740 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 742 [I-D.ietf-l2vpn-signaling] Rosen, E., "Provisioning, Autodiscovery, 743 and Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08 744 (work in progress), May 2006. 746 [I-D.kothari-l2vpn-vpls-flush] Kothari, B. and R. Fernando, "VPLS 747 Flush in BGP-based Virtual Private LAN Service", draft- 748 kothari-l2vpn-vpls-flush-00 (work in progress), October 749 2008. 751 [I-D.kothari-l2vpn-auto-site-id] Kothari, B., Kompella, K., and T. 752 IV, "Automatic Generation of Site IDs for Virtual Private 753 LAN Service", draft-kothari-l2vpn-auto-site-id-01 (work in 754 progress), October 2008. 756 [I-D.ietf-pwe3-redundancy-bit] Muley, P., Bocci, M., and L. Martini, 757 "Preferential Forwarding Status bit definition", draft- 758 ietf-pwe3-redundancy-bit-01 (work in progress), September 759 2008. 761 9.2. Informative References 763 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 764 Communities Attribute", RFC 4360, February 2006. 766 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 767 Networks (VPNs)", RFC 4364, February 2006. 769 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: 770 An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, 771 April 2006. 773 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 774 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 775 RFC 4762, January 2007. 777 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 778 Protocol 4 (BGP-4)", RFC 4271, January 2006. 780 10. Acknowledgments 782 The authors would like to thank Yakov Rekhter, Nischal Sheth, Mitali 783 Singh, Deven Raut and Nehal Bhau for their insightful comments and 784 probing questions. 786 Authors' Addresses 788 Bhupesh Kothari 789 Juniper Networks 790 1194 N. Mathilda Ave. 791 Sunnyvale, CA 94089 US 793 Email: bhupesh@juniper.net 795 Kireeti Kompella 796 Juniper Networks 797 1194 N. Mathilda Ave. 798 Sunnyvale, CA 94089 US 800 Email: kireeti@juniper.net 802 Wim Henderickx 803 Alcatel-Lucent 804 Copernicuslaan 50 805 2018 Antwerp, Belgium 807 Email: wim.henderickx@alcatel-lucent.be 809 Florin Balus 810 Alcatel-Lucent 811 701 E. Middlefield Road 812 Mountain View, CA, USA 94043 814 Email: florin.balus@alcatel-lucent.com 816 James Uttaro 817 AT&T 818 200 S. Laurel Avenue 819 Middletown, NJ 07748 820 USA 822 Email: uttaro@att.com