idnits 2.17.1 draft-pdutta-l2vpn-vpls-ldp-mac-opt-04.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.ii 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/.) -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 abstract seems to contain references ([RFC4762]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2009) is 5521 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Proposed Standard RFC: RFC 4762 ** Downref: Normative reference to an Draft Standard RFC: RFC 5036 -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 L2VPN Working Group Pranjal Kumar Dutta 2 Marc Lasserre 3 Internet Draft Alcatel-Lucent 4 Intended status: Standard 5 Expires: September 2009 Olen Stokes 6 Extreme Networks 8 March 8, 2009 10 LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS 11 draft-pdutta-l2vpn-vpls-ldp-mac-opt-04.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may not be modified, 17 and derivative works of it may not be created, and it may not be 18 published except as an Internet-Draft. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-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 September 8, 2009. 37 Abstract 39 [RFC4762] describes a mechanism to remove or unlearn MAC addresses 40 that have been dynamically learned in a VPLS Instance for faster 41 convergence on topology change. The procedure also removes the MAC 42 addresses in the VPLS that does not require relearning due to such 43 topology change. This document defines an extension to MAC Address 44 Withdrawal procedure with empty MAC List [RFC4762], which enables a 45 Provider Edge(PE) device to remove only the MAC addresses that needs 46 to be relearned. 48 Conventions used in this document 50 In examples, "C:" and "S:" indicate lines sent by the client and 51 server respectively. 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Table of Contents 59 1. Introduction.............................................. 3 60 2. Problem Description....................................... 4 61 3. Optimized MAC Flush Mechanism............................. 6 62 4. PE-ID TLV................................................. 7 63 5. Application of PE-ID TLV in Optimized MAC Flush........... 10 64 5.1 PE-ID TLV Processing Rules............................. 10 65 5.2 Optimized MAC Flush Procedures........................... 11 66 6. General Applicability of PE-ID TLV........................ 13 67 7. Security Considerations................................... 13 68 8. IANA Considerations....................................... 14 69 9. Acknowledgments........................................... 14 70 10. References .............................................. 15 71 10.1. Normative References................................ 15 72 10.2. Informative References ............................. 15 73 Author's Addresses........................................... 16 75 Terminology 77 This document uses the terminology defined in [RFC5036], [RFC4447] 78 and [RFC4762]. Throughout this document VPLS means the emulated 79 bridged LAN service offered to a customer. H-VPLS means the 80 hierarchical connectivity or layout of MTU-s and PE devices offering 81 the VPLS[RFC4762]. The terms spoke node and MTU-s in H-VPLS are used 82 interchangeably. 84 1. Introduction 86 A method of Virtual Private LAN Service (VPLS), also known as 87 Transparent LAN Service (TLS) is described in [RFC4762]. A VPLS is 88 created using a collection of one or more point-to-point pseudowires 89 (PWs) [RFC4664] configured in a flat, full-mesh topology. The mesh 90 topology provides a LAN segment or broadcast domain that is fully 91 capable of learning and forwarding on Ethernet MAC addresses at the 92 PE devices. 94 This VPLS full mesh core configuration can be augmented with 95 additional non-meshed spoke nodes to provide a Hierarchical VPLS 96 (H-VPLS) service[RFC4762]. 98 MAC Address Withdrawal mechanism is described in [RFC4762] to 99 remove or unlearn MAC addresses for faster convergence on topology 100 change in dual-homed H-VPLS[RFC4762]. In dual-homed H-VPLS, an edge 101 device termed as MTU-s is connected to two PE devices via primary 102 spoke PW and backup spoke PW respectively. Such redundancy is 103 designed to protect against the failure of primary spoke PW or 104 primary PE device. When MTU-s switches over to backup PW, it is 105 required to flush the MAC addresses learned in the VPLS in upstream 106 PE devices participating in full mesh, to avoid black holing of 107 frames to those addresses. Note that forced switchover to backup PW 108 can be also performed at MTU-s administratively due to maintenance 109 activities on the primary spoke PW. 111 When backup PW is made active by MTU-s, it triggers LDP Address 112 Withdraw Message with list of MAC addresses to be flushed. The 113 message is forwarded over the LDP session(s) associated with the 114 newly activated PW. In order to minimize the impact on LDP 115 convergence time when MAC List TLV contains a large number of MAC 116 addresses, it may be preferable to send a LDP Address Withdraw 117 Message with an empty MAC List. Throughout this document the term 118 MAC Flush Message is used to specify LDP Address Withdraw Message 119 with empty MAC List described in [RFC4762] unless specified 120 otherwise. 122 As per the processing rules in [RFC4762] a PE device on receiving 123 a MAC flush message removes all MAC addresses associated with 124 the specified VPLS instance (as indicated in the FEC TLV) except the 125 MAC addresses learned over the newly activated PW. The PE device 126 further triggers MAC flush message to each remote PE device 127 connected to it in the VPLS full mesh. 129 This method of MAC flushing is modeled after Topology Change 130 Notification (TCN) in Rapid Spanning Tree Protocol (RSTP)[802.1w]. 131 When a bridge switches from failed link to the backup link, the 132 bridge sends out a TCN message over the newly activated link. The 133 upstream bridge upon receiving this message flushes its entire MAC 134 addresses except the ones received over this link and sends the TCN 135 message out of its other ports in that spanning tree instance. The 136 message is further relayed along the spanning tree by the other 137 bridges. 139 When a PE device in the full-mesh of H-VPLS receives a MAC flush 140 message it also flushes the MAC addresses which are not affected 141 due to topology change, thus leading to unnecessary flooding and 142 relearning. This document describes the problem and a solution to 143 optimize the MAC flush procedure in [RFC4762] so that flush only 144 the set of MAC addresses that require relearning when topology 145 changes in H-VPLS. 147 [L2VPN-SIG] describes about inter-AS VPLS deployments models where 148 Multi-Segment PWs (MS-PW) may be used. The solution proposed in 149 this document is generic and is applicable to MS-PWs in H-VPLS. 151 2. Problem Description 153 Figure.1 describes a dual-homed H-VPLS scenerio for a VPLS instance 154 where the problem with the existing MAC flush method in [RFC4762] is 155 explained. 157 PE-1 PE-3 158 +--------+ +--------+ 159 | | | | 160 | -- | | -- | 161 Customer Site 1 | / \ |------------------| / \ |-> 162 CE-1 /------| \ s/ | | \S / | 163 \ primary spoke PW | -- | /------| -- | 164 \ / +--------+ / +--------+ 165 \ (MTU-s)/ | \ / | 166 +--------+/ | \ / | 167 | | | \ / | 168 | -- | | \ / | 169 | / \ | | H-VPLS Full Mesh Core| 170 | \S / | | / \ | 171 | -- | | / \ | 172 /+--------+\ | / \ | 173 / backup spoke PW | / \ | 174 / \ +--------+ \--------+--------+ 175 CE-2 \ | | | | 176 Customer Site 2 \------| -- | | -- | 177 | / \ |------------------| / \ |-> 178 | \s / | | \S / | 179 | -- | | -- | 180 +--------+ +--------+ 181 PE-2 PE-4 183 Figure 1: Dual homed MTU-s in two tier hierarchy H-VPLS 185 In Figure.1, the MTU-s is dual-homed to PE-1 and PE-2. Only the 186 primary spoke PW is active at MTU-s, thus PE-1 acting as the primary 187 device to reach the full mesh in the VPLS instance. The MAC 188 addresses of nodes located at access sites (behind CE1 and CE2) are 189 learned at PE-1 over the primary spoke PW. PE-2, PE-3 and PE-4 learn 190 those MAC addresses on their respective mesh PWs terminating to 191 PE-1. 193 When MTU-s switches to backup spoke PW and activates it, PE-2 194 becomes the primary device to reach the full mesh core. Traffic 195 entering the H-VPLS from CE-1 and CE-2 is diverted by MTU-s to the 196 backup spoke PW. For faster convergence MTU-s may desire to unlearn 197 or remove the MAC addresses that have been learned in the upstream 198 VPLS full-mesh through PE-1. MTU-s may send MAC flush message to 199 PE-2 once the backup PW has been made active. As per the processing 200 rules defined in [RFC4762], PE-2 flushes the entire MAC addresses 201 learned in the VPLS from the PWs terminating at PE-1, PE-3 and PE-4 202 except the ones learned over the newly activated spoke PW. 204 In the H-VPLS core, PE devices are connected in full mesh unlike the 205 spanning tree connectivity in bridges. So the MAC addresses that 206 require flushing and relearning at PE-2 are only the MAC addresses 207 those have been learned on the PW connected to PE-1. 209 PE-2 further relays MAC flush messages to all other PE devices in 210 the full mesh. Same processing rule applies at all those PE devices. 211 For example, at PE-3 the entire MAC addresses learned from the PWs 212 connected to PE-1 and PE-4 are flushed and relearned subsequently. 213 As the number of PE devices in the full-mesh increases, the number 214 of unaffected MAC addresses flushed in a VPLS instance also 215 increases, thus leading to unnecessary flooding and relearning. With 216 large number of VPLS instances provisioned in the H-VPLS network 217 topology the amount of unnecessary flooding and relearning 218 increases. 220 3. Optimized MAC Flush Mechanism 222 The basic principle of the optimized MAC flush mechanism is 223 explained with reference to Figure 1. On switching over to the 224 backup spoke PW when MTU-s triggers MAC flush message to PE-2, it 225 also communicates the unique PW endpoint identifier (PE-ID) in PE-1, 226 the formerly active PE device. In VPLS a PW terminates on a Virtual 227 Switching Instance (VSI) in a PE device. The PE-ID is relayed in all 228 the subsequent MAC flush messages triggered by PE-2 to its peer PE 229 devices in the full mesh. Each PE device that receives the message 230 identifies the VPLS (From FEC TLV) and its respective PW that 231 terminates in PE-1 (from PE-ID). Thus the PE device flushes only the 232 MAC addresses learned from that PW connected to PE-1. 234 4. PE-ID TLV 236 This document defines a PW Endpoint Identifier (PE-ID) TLV for 237 LDP [RFC5036]. The PE-ID TLV carries the unique identifier of a 238 generic PW endpoint. 240 The encoding of PE-ID TLV follows standard LDP TLV encoding in 241 [RFC5036]. A PE-ID TLV contains a list of one or more PE-ID 242 Elements. Its encoding is: 244 0 1 2 3 246 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 |1|0| PE-ID TLV (0x0405) | Length | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | PE-ID Element 1 | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 ~ ~ 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | PE-ID Element n | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 2. PE-ID TLV 262 U (Unknown) bit of thus LDP TLV MUST be set to 1. If the PE-ID TLV 263 is not understood then it is ignored the receiving device. 265 F (Forward) MUST be set to 0. Since the LDP mechanism used here is 266 targeted, the TLV is not forwarded if it is not understood by the 267 receiving device. 269 The Type field MUST be set to 0x405 (subject to IANA approval). This 270 identifies the TLV type as PE-ID TLV. 272 Length field specifies the total length in octets of the Value 273 in PE-ID TLV. 275 PE-ID Element 1 to PE-ID Element n: 276 There are several types of PE-ID Elements. The PE-ID Element 277 Encoding depends on the type of the PE-ID Element. A PE-ID 278 Element uniquely identifies a PW Endpoint. 280 A PE-ID Element value is encoded as 1 octet field that specifies the 281 element type, 1 octet field that identifies the length in octets of 282 the element value, and a variable length field that is type 283 dependent element value. 285 The PE-ID Element value encoding is: 287 PE-ID Element Type Length Value 288 Type name 290 FEC-128 specific 0x01 2 octets See below. 291 FEC-129 specific 0x02 Variable See below. 293 The type of PE-ID Element depends on the type of FEC Element used to 294 provision the respective PW. 296 [RFC4447] defines two types of FEC elements that may be used for 297 provisioning PWs - Pwid FEC (type 128) and the Generalized ID (GID) 298 FEC (type 129). 300 The Pwid FEC element includes a fixed-length 32 bit value called the 301 PWid. The same PWid value must be configured on the local and remote 302 PE prior to PW setup. 304 The GID FEC element includes TLV fields for attachment individual 305 identifiers (AII) that, in conjunction with an attachment group 306 identifier (AGI), serve as PW endpoint identifiers. The endpoint 307 identifier on the local PE (denoted as ) is 308 called the source attachment identifier (SAI) and the endpoint 309 identifier on the remote PE (denoted as ) is 310 called the target attachment identifier (TAI). The SAI and TAI can be 311 distinct values. This is useful for provisioning models where the 312 local PE (with a particular SAI) does not know and must somehow learn 313 (e.g. via MP-BGP auto-discovery) of remote TAI values prior to 314 launching PW setup messages towards the remote PE. 316 FEC-128 specific PE-ID Element 317 This sub-type is to be used to identify a PW endpoint only if 318 Pwid FEC Element is used for signaling the PW. The encoding of 319 this PE-ID element is as follows: 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | 0x01 | Length | PW type | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | PW ID | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Endpoint Address | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 3. FEC-128 specific PE-ID Element 331 PW type 332 The PW Type value from PWid FEC element. 334 PW ID 335 The PW ID value from the Pwid FEC element. 337 Endpoint Address 338 32-bit LSR-ID from the LDP-ID used in LDP signaling session 339 by a PW endpoint. 341 FEC-129 specific PE-ID element 342 This sub-type is to be used to indentify a PW endpoint only if 343 GID FEC Element is used for signaling the PW. The encoding of 344 this PE-ID element is as follows: 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | 0x02 | Length | PW type | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | AGI TLV | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | AII TLV | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Figure 4. FEC-129 specific PE-ID Element 356 PW type 357 The PW Type value from GID FEC element. 359 PW ID 360 The PW ID value from the GID FEC element 362 AGI TLV 363 The AGI from the corresponding GID Element 365 AII TLV 366 The AII associated with the PW endpoint. 368 5. Application of PE-ID TLV in Optimized MAC Flush 370 For optimized MAC flush, the PE-ID TLV MAY be sent as an OPTIONAL 371 parameter in existing LDP Address Withdraw Message with empty MAC 372 List. The PE-ID TLV carries the unique PW endpoint identifier in a 373 VPLS as described in section 4. 375 It is to note that for optimized MAC flush the PE-ID TLV carries 376 sufficient information for identifying the VPLS instance and the 377 unique VSI Identifier. For backward compatibility with MAC flush 378 procedures in [RFC4762] both FEC TLV and PE-ID TLV should be sent in 379 the MAC flush message. However the inclusion of the FEC-TLV should be 380 based on what would be the desired effect should the PE-ID not be 381 understood by the receiver. In cases where the desired action when 382 the PE-ID is not understood would be to behave as described in 383 [RFC4762], then the FEC TLV SHOULD be included. In cases where the 384 desired action when the PE-ID is not understood is to take no 385 action, then the FEC TLV SHOULD NOT be included. The PE-ID TLV 386 SHOULD carry the unique VSI identifier in the VPLS instance 387 (specified in the FEC TLV). The PE-ID TLV SHOULD be placed after the 388 existing TLVs in MAC Flush message in [RFC4762]. 390 5.1 PE-ID TLV Processing Rules 392 This section describes the processing rules of PE-ID TLV that SHOULD 393 be followed in the context of MAC flush procedures in an H-VPLS. 395 When an MTU-s triggers MAC flush after activation of backup spoke 396 PW, it MAY send the PE-ID TLV that identifies VSI in the formerly 397 active PE device. There may be cases where a PE device in full mesh 398 initiates MAC flush torwards the core when it detects a spoke PW 399 failure. In such a case the PE-ID TLV in MAC flush message 400 MAY identify its own VSI in the VPLS instance. Irrespective of 401 whether it is the MTU-s or PE device that initiates the MAC flush, a 402 PE device receiving the PE-ID TLV SHOULD follow the same processing 403 rules as described in this section. 405 If MS-PW signaled with GID Element is used in VPLS then a MAC flush 406 message is processed only at the T-PE nodes. In this section, a PE 407 device signifies only T-PE in MS-PW case unless specified otherwise. 409 When a PE device receives a MAC flush with PE-ID TLV, it SHOULD 410 flush all the MAC addresses learned in the VPLS from the PW that 411 terminates in the remote VSI identified by the PE-ID element. 413 If a PE-ID element received in the MAC flush message identifies the 414 local VSI, it SHOULD flush the MAC addresses learned from its 415 local spoke PW(s) in the VPLS instance. 417 If a PE device receives a MAC flush with the PE-ID TLV option 418 And a valid MAC address list, it SHOULD ignore the option and deal 419 with MAC addresses explicitly as per [RFC4762]. 421 If a PE device that doesn't support PE-ID TLV receives a MAC flush 422 message with this option, it MUST ignore the option and follow the 423 processing rules as per [RFC4762]. 425 5.2 Optimized MAC Flush Procedures 427 This section explains the optimized MAC flush procedure in the 428 scenario in Figure.1. 430 When the backup PW is activated by MTU-s, it may send MAC flush 431 message to PE-2 with the optional PE-ID TLV. The PE-ID element 432 carries the VSI identifier in PE-1 for the VPLS. Upon receipt of the 433 MAC flush message, PE-2 identifies the VPLS instance that requires 434 MAC flush from the FEC element in the FEC TLV. From the PE-ID TLV, 435 PE-2 identifies the PW in the VPLS that terminates in PE-1. PE-2 436 removes all MAC addresses learned from that PW. 438 PE-2 relays MAC flush messages with the received PE-ID to all its 439 peer PE devices. When the message is received at PE-3, it identifies 440 the PW that terminates in the remote VSI in PE-1. PE-3 removes all 441 MAC addresses learned on the PW that terminated in PE1. 443 There may be redundancy scenerios where a PE device in the full mesh 444 may be required to initiate optimized MAC Address Withdrawal. 445 Figure 5. shows a redundant H-VPLS topology to protect against 446 failure of MTU-s device. Provider RSTP may be used as selection 447 algorithm for active and backup PWs in order to maintain the 448 connectivity between MTU devices and PE devices at the edge. It is 449 assumed that PE devices can detect failure on PWs in either 450 direction through OAM mechanisms such as VCCV procedures for 451 instance. 453 MTU-1================PE-1===============PE-3 454 || || \ /|| 455 || Redundancy || \ / || 456 || Provider RSTP || Full-Mesh . || 457 || || / \ || 458 || || / \|| 459 MTU-2----------------PE-2===============PE-4 460 Backup PW 462 Figure 5. Redundancy with Provider RSTP 464 MTU-1, MTU-2, PE-1 and PE-2 participate in provider RSTP. By 465 configuration in RSTP it is ensured that the PW between MTU-1 and 466 PE-1 is active and the PW between MTU-2 and PE-2 is blocked (made 467 backup) at MTU-2 end. When the active PW failure is detected by 468 RSTP, it activates the PW between MTU-2 and PE-2. When PE-1 detects 469 the failing PW to MTU-1, it may trigger MAC flush into the full mesh 470 with PE-ID TLV that carries its own VSI identifier in the VPLS. 471 Other PE devices in the full mesh that receive the MAC flush 472 message identify their respective PWs terminating on PE-1 and 473 flush all the MAC addresses learned from it. 475 By default, MTU-2 should still trigger MAC flush as currently 476 defined in [RFC4762] after the backup PW is made active by RSTP. 477 Mechanisms to prevent two copies of MAC withdraws to be sent in such 478 scenerios is out of scope of this document. 480 [RFC4762] describes multi-domain VPLS service where fully meshed 481 VPLS networks (domains) are connected together by a single spoke 482 PW per VPLS service between the VPLS "border" PE devices. To provide 483 redundancy against failure of the inter-domain spoke, full mesh of 484 inter-domain spokes can be setup between border PE devices and 485 provider RSTP may be used for selection of the active inter-domain 486 spoke. In case of inter-domain spoke PW failure, PE initiated MAC 487 withdrawal may be used for optimized MAC flushing within individual 488 domains. 490 6. General Applicability of PE-ID TLV 492 This document defines the PE-ID TLV and its application in optimized 493 flushing of MAC addresses in H-VPLS on topology change. The use of 494 PE-ID TLV in MAC flush mechanism is OPTIONAL. 496 Different H-VPLS redundancy scenarios are possible. The use of the 497 PE-ID TLV applies to H-VPLS dual-homing scenarios described in this 498 document. The use of the PE-ID TLV in different scenarios is out of 499 scope. The protocols used in redundancy scenarios are outside the 500 scope. The document doesn't specify the device that should trigger 501 optimized MAC flush. The method to select the appropriate PE-ID in 502 various redundancy scenarios is out of scope. 504 There may be other L2VPN applications where PE-ID TLV may be 505 applicable and such applications are outside the scope of this 506 document. 508 7. Security Considerations 510 - Control plane aspects 511 - LDP security (authentication) methods as described in [RFC5036] 512 is applicable here. Further this document implements security 513 considerations as in [RFC4447] and [RFC4762]. 515 - Data plane aspects 516 - This specification does not have any impact on the VPLS 517 forwarding plane. 519 8. IANA Considerations 521 The Type field in PE-ID TLV is defined as 0x405 and is subject to 522 IANA approval. 524 9. Acknowledgments 526 The authors would like to thank the following people who have 527 provided valuable comments and feedback on the topics discussed in 528 this document: 530 Florin Balus 531 Prashanth Ishwar 532 Vipin Jain 533 John Rigby 534 Ali Sajassi 536 This document was prepared using 2-Word-v2.0.template.dot. 538 10. References 540 10.1. Normative References 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14, RFC 2119, March 1997. 545 [RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN 546 Services using LDP", RFC 4762, January 2007. 548 [RFC5036] Andersson, L., et al. "LDP Specification",RFC5036, 549 October 2007. 551 10.2. Informative References 553 [L2VPN-SIG] Rosen, E., et al. .Provisioning, Autodiscovery, and 554 Signaling in L2VPNs., work in progress. 556 [RFC4664] Andersson, L., et al. "Framework for Layer 2 557 Virtual Private Networks (L2VPNs)", RFC 4664, 558 September 2006. 560 [RFC4447] Martini. and et al., "Pseudowire Setup and 561 Maintenance Using Label Distribution Protocol 562 (LDP)", RFC 4447, April 2006. 564 [802.1w] "IEEE Standard for Local and metropolitan area 565 networks. Common specifications Part 3: Media 566 Access Control (MAC) Bridges. Amendment 2: Rapid 567 Reconfiguration", IEEE Std 802.1w-2001. 569 Author's Addresses 571 Pranjal Kumar Dutta 572 Alcatel-Lucent 573 701 E Middlefield Road, 574 Mountain View, CA 94043 575 USA 577 Email: pdutta@alcatel-lucent.com 579 Marc Lasserre 580 Alcatel-Lucent 582 Email: marc.lasserre@alcatel-lucent.com 584 Olen Stokes 585 Extreme Networks 586 PO Box 14129 587 RTP, NC 27709 588 USA 590 Email: ostokes@extremenetworks.com 592 Copyright Notice 594 Copyright (c) 2009 IETF Trust and the persons identified as the 595 document authors. All rights reserved. 597 This document is subject to BCP 78 and the IETF Trust's Legal 598 Provisions Relating to IETF Documents in effect on the date of 599 publication of this document (http://trustee.ietf.org/license-info). 600 Please review these documents carefully, as they describe your rights 601 and restrictions with respect to this document. 603 Acknowledgment 605 Funding for the RFC Editor function is currently provided by the 606 Internet Society.