idnits 2.17.1 draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (March 25, 2014) is 3684 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-vpls-multihoming-06 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Dutta 3 Internet-Draft F. Balus 4 Intended status: Standards Track Alcatel-Lucent 5 Expires: September 26, 2014 O. Stokes 6 Extreme Networks 7 G. Calvinac 8 France Telecom 9 March 25, 2014 11 LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS 12 draft-ietf-l2vpn-vpls-ldp-mac-opt-11 14 Abstract 16 RFC4762 describes a mechanism to remove or unlearn MAC addresses that 17 have been dynamically learned in a Virtual Private LAN Service (VPLS) 18 Instance for faster convergence on topology change. The procedure 19 also removes MAC addresses in the VPLS that do not require relearning 20 due to such topology change. This document defines an enhancement to 21 the MAC Address Withdrawal procedure with empty MAC List from 22 RFC4762, which enables a Provider Edge(PE) device to remove only the 23 MAC addresses that need to be relearned. Additional extensions to 24 RFC4762 MAC Withdrawal procedures are specified to provide optimized 25 MAC flushing for the Provider Backbone Bridging (PBB)VPLS specified 26 in RFC7041. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 31, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. MAC Flush on activation of backup spoke PW . . . . . . . . 6 71 3.1.1. PE-rs initiated MAC Flush . . . . . . . . . . . . . . 7 72 3.1.2. MTU-s initiatied MAC flush . . . . . . . . . . . . . . 7 73 3.2. MAC Flush on failure . . . . . . . . . . . . . . . . . . . 8 74 3.3. MAC Flush in PBB-VPLS . . . . . . . . . . . . . . . . . . 8 75 4. Problem Description . . . . . . . . . . . . . . . . . . . . . 9 76 4.1. MAC Flush Optimization in VPLS Resiliency . . . . . . . . 9 77 4.1.1. MAC Flush Optimization for regular H-VPLS . . . . . . 9 78 4.1.2. MAC Flush Optimization for native Ethernet access . . 11 79 4.2. Black holing issue in PBB-VPLS . . . . . . . . . . . . . . 12 80 5. Solution Description . . . . . . . . . . . . . . . . . . . . . 13 81 5.1. MAC Flush Optimization for VPLS Resiliency . . . . . . . . 13 82 5.1.1. MAC Flush Parameters TLV . . . . . . . . . . . . . . . 14 83 5.1.2. Application of MAC Flush TLV in Optimized MAC Flush . 15 84 5.1.3. MAC Flush TLV Processing Rules for Regular VPLS . . . 15 85 5.1.4. Optimized MAC Flush Procedures . . . . . . . . . . . . 16 86 5.2. LDP MAC Flush Extensions for PBB-VPLS . . . . . . . . . . 17 87 5.2.1. MAC Flush TLV Processing Rules for PBB-VPLS . . . . . 18 88 5.2.2. Applicability of MAC Flush Parameters TLV . . . . . . 20 89 6. Operational Considerations . . . . . . . . . . . . . . . . . . 20 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 91 7.1 New LDP TLV . . . . . . . . . . . . . . . . . . . . . . . . 21 92 7.2 New Registry for MAC Flush Flags . . . . . . . . . . . . . . 21 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 94 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 22 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 98 11.2. Informative References . . . . . . . . . . . . . . . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 101 1. Introduction 103 A method of Virtual Private LAN Service (VPLS), also known as 104 Transparent LAN Service (TLS) is described in [RFC4762]. A VPLS is 105 created using a collection of one or more point-to-point pseudowires 106 (PWs) [RFC4664] configured in a flat, full-mesh topology. The mesh 107 topology provides a LAN segment or broadcast domain that is fully 108 capable of learning and forwarding on Ethernet MAC addresses at the 109 PE devices. 111 This VPLS full mesh core configuration can be augmented with 112 additional non-meshed spoke nodes to provide a Hierarchical VPLS 113 (H-VPLS) service [RFC4762]. Throughout this document this 114 configuration is referred to as "regular" H-VPLS. 116 [RFC7041] describes how Provider Backbone Bridging (PBB) can be 117 integrated with VPLS to allow for useful PBB capabilities while 118 continuing to avoid the use of Multiple Spanning Tree Protocol (MSTP) 119 in the backbone. The combined solution referred to as PBB-VPLS 120 results in better scalability in terms of number of service 121 instances, PWs and C-MAC (Customer MAC) Addresses that need to be 122 handled in the VPLS PEs depending on the location of the I-component 123 in the PBB-VPLS topology. 125 A MAC Address Withdrawal mechanism for VPLS is described in [RFC4762] 126 to remove or unlearn MAC addresses for faster convergence on topology 127 change in resilient H-VPLS topologies. Note that the H-VPLS topology 128 in [RFC4762] describes two tier hierarchy to VPLS as the basic 129 building block of H-VPLS, but it is possible to have multi-tier 130 hierarchy in an H-VPLS. 132 The figure 1. described below is taken from [RFC4762] that describes 133 dual-homing in H-VPLS. 135 PE2-rs 136 +--------+ 137 | | 138 | -- | 139 | / \ | 140 CE-1 | \S / | 141 \ | -- | 142 \ +--------+ 143 \ MTU-s PE1-rs / | 144 +--------+ +--------+ / | 145 | | | | / | 146 | -- | Primary PW | -- |---/ | 147 | / \ |- - - - - - - - - - - | / \ | | 148 | \S / | | \S / | | 149 | -- | | -- |---\ | 150 +--------+ +--------+ \ | 151 / \ \ | 152 / \ +--------+ 153 / \ | | 154 CE-2 \ | -- | 155 \ Secondary PW | / \ | 156 - - - - - - - - - - - - - - - - - | \S / | 157 | -- | 158 +--------+ 159 PE3-rs 160 Figure 1: An example of a dual-homed MTU-s 162 An example of usage of the MAC Flush mechanism is the dual-homed 163 H-VPLS where an edge device termed as MTU-s is connected to two PE 164 devices via primary spoke PW and backup spoke PW respectively. Such 165 redundancy is designed to protect against the failure of primary 166 spoke PW or primary PE device. There could be multiple methods of 167 dual homing in H-VPLS that are not described in [RFC4762]. For 168 example, note the following statement from section 10.2.1 in 169 [RFC4762]. 171 "How a spoke is designated primary or secondary is outside the scope 172 of this document. For example, a spanning tree instance running 173 between only the MTU-s and the two PE-rs nodes is one possible 174 method. Another method could be configuration". 176 This document intends to clarify several H-VPLS dual-homing models 177 that are deployed in practice and various use cases of LDP based MAC 178 flush in these models. 179 2. Terminology 181 This document uses the terminology defined in [RFC7041], [RFC5036], 182 [RFC4447] and [RFC4762]. 184 Throughout this document Virtual Private LAN Service (VPLS) means the 185 emulated bridged LAN service offered to a customer. H-VPLS means the 186 hierarchical connectivity or layout of Multi Tenant Unit switch (MTU- 187 s) and Provider Edge Routing and switching capable (PE-rs) devices 188 offering the VPLS [RFC4762]. 190 The terms "Spoke Node" and "MTU-s" in H-VPLS are used 191 interchangeably. 193 "Spoke PW" means the Pseudowire PW that provides connectivity between 194 MTU-s and PE-rs nodes. 196 "Mesh PW" means the PW that provides connectivity between PE-rs nodes 197 in a VPLS full mesh core. 199 "MAC Flush Message" means Label Distribution Protocol (LDP) Address 200 Withdraw Message without MAC List TLV. 202 MAC Flush Message in the "context of a Pseudo Wire (PW)" means the 203 Message that has been received over the LDP session that is used to 204 set up the PW used to provide connectivity in VPLS. The MAC Flush 205 Message carries the context of the PW in terms of Forwarding 206 Equivalence Class (FEC) TLV associated with the PW 207 [RFC4762][RFC4447]. 209 In general, "MAC Flush" means the method of initiating and processing 210 of MAC Flush Messages across a VPLS instance. 212 3. Overview 214 When the MTU-s switches over to the backup PW, the requirement is to 215 flush the MAC addresses learned in the corresponding Virtual Switch 216 Instance (VSI) in peer PE devices participating in the full mesh, to 217 avoid black holing of frames to those addresses. This is 218 accomplished by sending an LDP Address Withdraw Message from the PE 219 that is no longer connected to the MTU-s with the primary PW, with 220 the list of MAC addresses to be removed to all other PEs over the 221 corresponding LDP sessions [RFC4762]. 223 In order to minimize the impact on LDP convergence time and 224 scalability when a MAC List TLV contains a large number of MAC 225 addresses, many implementations use a LDP Address Withdraw Message 226 with an empty MAC List. Throughout this document the term "MAC Flush 227 Message" is used to specify LDP Address Withdraw Message with an 228 empty MAC List described in [RFC4762] unless specified otherwise. The 229 solutions described in this document are applicable only to LDP 230 Address Withdraw Message with empty MAC List. 232 In a VPLS topology, the core PWs remain active and learning happens 233 on the PE-rs nodes. However when the VPLS topology changes, the 234 PE-rs must relearn using MAC Addresses withdrawal or flush. As per 235 the MAC Address Withdrawal processing rules in [RFC4762] a PE device 236 on receiving a MAC Flush Message removes all MAC addresses associated 237 with the specified VPLS instance (as indicated in the FEC TLV) except 238 the MAC addresses learned over the PW associated with this signaling 239 session over which the message was received. Throughout this 240 document we use the terminology "Positive" MAC Flush or "Flush-all- 241 but-mine" for this type of MAC Flush Message and its actions. 243 3.1. MAC Flush on activation of backup spoke PW 245 This section describes scenarios where MAC Flush withdrawal is 246 initiated on activation of backup PW in H-VPLS. 248 3.1.1. PE-rs initiated MAC Flush 250 [RFC4762] specifies that on failure of the primary PW, it is the 251 PE3-rs (Figure 1) that initiates MAC flush towards the core. However 252 note that PE3-rs can initiate MAC Flush only when PE3-rs is dual 253 homing "aware" - that is, there is some redundancy management 254 protocol running between MTU-s and its host PE-rs devices. The scope 255 of this document is not specific to any dual homing protocols. One 256 example could be BGP based multi-homing in LDP based VPLS that uses 257 the procedures defined in [I-D.ietf-l2vpn-vpls-multihoming]. In this 258 method of dual-homing, PE3-rs would neither forward any traffic to 259 MTU-s nor would it receive any traffic from MTU-s while PE1-rs is 260 acting as a primary (or designated forwarder). 262 3.1.2. MTU-s initiatied MAC flush 264 When dual homing is achieved by manual configuration in MTU-s, the 265 hosting PE-rs devices are dual homing "agnostic" and PE3-rs can not 266 initiate MAC Flush message. PE3-rs can send or receive traffic over 267 the backup PW since the dual-homing control is with MTU-s only. When 268 the backup PW is made active by the MTU-s, the MTU-s triggers MAC 269 Flush Message. The message is sent over the LDP session associated 270 with the newly activated PW. On receiving the MAC Flush Message from 271 MTU-s, PE3-rs (PE-rs device with now-active PW) would flush all the 272 MAC addresses it has learned except the ones learned over the newly 273 activated spoke PW. PE3-rs further initiates a MAC Flush Message to 274 all other PE devices in the core. Note that forced switchover to 275 backup PW can be also performed at MTU-s administratively due to 276 maintenance activities on the former primary spoke PW. 278 MTU-s initiated method of MAC flushing is modeled after Topology 279 Change Notification (TCN) in Rapid Spanning Tree Protocol (RSTP) 280 [IEEE.802.1Q-2011]. When a bridge switches from a failed link to the 281 backup link, the bridge sends out a TCN message over the newly 282 activated link. The upstream bridge upon receiving this message 283 flushes its entire MAC addresses except the ones received over this 284 link and sends the TCN message out of its other ports in that 285 spanning tree instance. The message is further relayed along the 286 spanning tree by the other bridges. 288 The MAC Flush information is propagated in the control plane. The 289 control plane message propagation is associated with the data path 290 and hence follows similar rules for propagation as the forwarding in 291 the LDP data plane. For example PE-rs nodes follow the data plane 292 "split-horizon" forwarding rules in H-VPLS (Refer to section 4.4 in 293 [RFC4762]). Therefore a MAC Flush is propagated in the context of 294 mesh PW(s) when it is received in the context of a spoke PW. When a 295 PE-rs node receives a MAC Flush in the context of a mesh PW then it 296 is not propagated to other mesh PWs. 298 Irrespective of whether a MAC Flush is initiated by a PE-rs or MTU-s, 299 when a PE-rs device in the full-mesh of H-VPLS receives a MAC flush 300 message it also flushes MAC addresses which are not affected due to 301 topology change, thus leading to unnecessary flooding and relearning. 302 This document describes an optional mechanism to optimize the MAC 303 flush procedure in [RFC4762] so that it flushes only the set of MAC 304 addresses that require relearning when topology changes in H-VPLS. 306 3.2. MAC Flush on failure 308 MAC Flush on failure is introduced in this document. In this model, 309 the MAC Flush is initiated by PE1-rs (Figure 1) on detection of 310 failure of the primary spoke PW and is sent to all participating 311 PE-rs devices in the VPLS full-mesh. PE1-rs SHOULD initiate MAC 312 flush only if PE1-rs is dual homing aware. (If PE1-rs is dual homing 313 agnostic, the policy is do not initiate a MAC flush on failure, since 314 that could cause unnecessary flushing in the case of single homed 315 MTU-s.) The dual-homing protocols for this scenario are outside the 316 scope of this document. For example, the case of PE1-rs initiated 317 MAC flush on failure may arise when the dual-homing segment is native 318 ethernet as opposed to spoke PWs. In this case the PE-rs devices 319 that receive the MAC flush from PE1-rs are required to flush all the 320 MAC addresses learned over the PW connected to PE1-rs. This cannot 321 be achieved with the MAC Address Withdraw Message defined in 322 [RFC4762]. This document describes extensions to MAC Flush 323 procedures defined in [RFC4762] in order to implement MAC Flush on 324 Failure. We use the term "negative" MAC flush or "Flush-all-from-me" 325 for this kind of flushing action as opposed to "positive" MAC Flush 326 action in [RFC4762]. The negative MAC flush typically results is a 327 smaller set of MACs to be flushed. 329 Note that in the case of negative flush the list SHOULD be only the 330 MACs for the affected MTU-s. If the list is empty then the negative 331 flush will result in flushing and relearning all attached MTU-s's for 332 the originating PE-rs. 334 3.3. MAC Flush in PBB-VPLS 336 [RFC7041] describes how PBB can be integrated with VPLS to allow for 337 useful PBB capabilities while continuing to avoid the use of MSTP in 338 the backbone. The combined solution referred to as "PBB-VPLS" 339 results in better scalability in terms of number of service 340 instances, PWs and C-MACs that need to be handled in the VPLS PE-rs 341 devices. This document describes extensions to LDP MAC Flush 342 procedures described in [RFC4762] required to build desirable 343 capabilities to PBB-VPLS solution. 345 The solution proposed in this document is generic and is applicable 346 when MS-PWs are used in interconnecting PE devices in H-VPLS. There 347 could be other H-VPLS models not defined in this document where the 348 solution may be applicable. 350 4. Problem Description 352 This section describes the problems in detail with respective to 353 various MAC flush actions described in section 2. 355 4.1. MAC Flush Optimization in VPLS Resiliency 357 This section describes the optimizations required in MAC flush 358 procedures when H-VPLS resiliency is provided by primary and backup 359 spoke PWs. 361 4.1.1. MAC Flush Optimization for regular H-VPLS 363 Figure 2. describes a dual-homed H-VPLS scenario for a VPLS instance 364 where the problem with the existing MAC flush method explained in 365 section 3. 367 PE1-rs PE3-rs 368 +--------+ +--------+ 369 | | | | 370 | -- | | -- | 371 Customer Site 1 | / \ |------------------| / \ |->Z 372 X->CE-1 /-----| \s / | | \s / | 373 \ primary spoke PW | -- | /------| -- | 374 \ / +--------+ / +--------+ 375 \ (MTU-s)/ | \ / | 376 +--------+/ | \ / | 377 | | | \ / | 378 | -- | | \ / | 379 | / \ | | H-VPLS Full Mesh Core| 380 | \s / | | / \ | 381 | -- | | / \ | 382 /+--------+\ | / \ | 383 / backup spoke PW | / \ | 384 / \ +--------+ \--------+--------+ 385 Y->CE-2 \ | | | | 386 Customer Site 2 \------| -- | | -- | 387 | / \ |------------------| / \ |-> 388 | \s / | | \s / | 389 | -- | | -- | 390 +--------+ +--------+ 391 PE2-rs PE4-rs 393 Figure 2: Dual homed MTU-s in two tier hierarchy H-VPLS 395 In Figure 2, the MTU-s is dual-homed to PE1-rs and PE2-rs. Only the 396 primary spoke PW is active at MTU-s, thus PE1-rs is acting as the 397 active device (designated forwarder) to reach the full mesh in the 398 VPLS instance. The MAC addresses of nodes located at access sites 399 (behind CE1 and CE2) are learned at PE1-rs over the primary spoke PW. 400 Let's say X represents a set of such MAC addresses located behind 401 CE-1. As packets flow from X to other MACs in the VPLS network, 402 PE2-rs, PE3-rs and PE4-rs learn about X on their respective mesh PWs 403 terminating at PE1-rs. When MTU-s switches to the backup spoke PW 404 and activates it, PE2-rs becomes the active device (designated 405 forwarder) to reach the full mesh core for MTU-s. Traffic entering 406 the H-VPLS from CE-1 and CE-2 is diverted by the MTU-s to the spoke 407 PW to PE2-rs. Traffic destined from PE2-rs, PE3-rs and PE4-rs to X 408 will be blackholed till MAC address aging timer expires (default is 5 409 minutes) or a packet flows from X to other addresses through PE2-rs. 411 For example, if after the backup spoke PW is active, if a packet 412 flows from MAC Z to MAC X, packets from MAC Z travel from PE3-rs to 413 PE-1rs and are dropped. However, if a packet with MAC X as source 414 and MAC Z as destination arrives at PE2-rs, PE2-rs will now learn MAC 415 X is on the backup spoke PW and will forward to MAC Z. At this point 416 traffic from PE3-rs to MAC X will go to PE2-rs, since PE-3rs has also 417 learned about MAC X. Therefore a mechanism is required to make this 418 learning more timely in cases where traffic is not bidirectional. 420 To avoid traffic blackholing the MAC addresses that have been learned 421 in the upstream VPLS full-mesh through PE1-rs, must be relearned or 422 removed from the MAC FIBs in the VSIs at PE2-rs, PE3-rs and PE4-rs. 423 If PE1-rs and PE2-rs are dual-homing agnostic then on activation of 424 the standby PW from MTU-s, a MAC flush message will be sent by MTU-s 425 to PE2-rs that will flush all the MAC addresses learned in the VPLS 426 instance at PE2-rs from all the other PWs but the PW connected to 427 MTU-s. 429 PE2-rs further relays MAC flush messages to all other PE-rs devices 430 in the full mesh. The same processing rule applies at all those 431 PE-rs devices: all the MAC addresses are flushed but the ones learned 432 on the PW connected to PE2-rs. For example, at PE3-rs all of the MAC 433 addresses learned from the PWs connected to PE1-rs and PE4-rs are 434 flushed and relearned subsequently. Before the relearning happens 435 flooding of unknown destination MAC addresses takes place throughout 436 the network. As the number of PE-rs devices in the full-mesh 437 increases, the number of unaffected MAC addresses flushed in a VPLS 438 instance also increases, thus leading to unnecessary flooding and 439 relearning. With large number of VPLS instances provisioned in the 440 H-VPLS network topology the amount of unnecessary flooding and 441 relearning increases. An optimization, described below, is required 442 that will flush only the MAC addresses learned from the respective 443 PWs between PE1-rs and other PE devices in the full-mesh minimizing 444 the relearning and flooding in the network. In the example above, 445 only the MAC addresses in set X and Y need to be flushed across the 446 core. 448 The same case is applicable when PE1-rs and PE2-rs are dual homing 449 aware and participate in a designated forwarder election. When 450 PE2-rs becomes the active device for MTU-s then PE2-rs MAY initiate 451 MAC flush towards the core. The receiving action of the MAC Flush in 452 other PE-rs devices is the same as in MTU-s initiated MAC Flush. This 453 is the [RFC4762] specified behavior. 455 4.1.2. MAC Flush Optimization for native Ethernet access 457 The analysis in section 3.1.1 applies also to the native Ethernet 458 access into a VPLS. In such a scenario one active and one or more 459 standby endpoints terminate into two or more VPLS or H-VPLS PE-rs 460 devices. Examples of these dual homed access are ITU-T [ITU.G8032] 461 access rings or any proprietary multi-chassis LAG emulations. Upon 462 failure of the active native Ethernet endpoint on PE1-rs, an 463 optimized MAC flush is required to be initiated by PE1-rs to ensure 464 that on PE2-rs, PE3-rs and PE4-rs only the MAC addresses learned from 465 the respective PWs connected to PE1-rs are being flushed. 467 4.2. Black holing issue in PBB-VPLS 469 In a PBB-VPLS deployment a B-component VPLS (B-VPLS) may be used as 470 infrastructure to support one or more I-component instances. The 471 B-VPLS control plane (LDP Signaling) and learning of "Backbone" MACs 472 (BMACs) replaces I-component control plane and learning of customer 473 MACs (CMACs) throughout the MPLS core. This raises an additional 474 challenge related to black hole avoidance in the I-component domain 475 as described in this section. Figure 3 describes the case of a CE 476 device (node A) dual-homed to two I-component instances located on 477 two PBB-VPLS PEs (PE1-rs and PE2-rs). 479 IP/MPLS Core 480 +--------------+ 481 |PE2-rs | 482 +----+ | 483 |PBB | +-+ | 484 |VPLS|---|P| | 485 S/+----+ /+-+\ |PE3-rs 486 / +----+ / \+----+ 487 +---+/ |PBB |/ +-+ |PBB | +---+ 488 CMAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--CMAC Y 489 +---+ A +----+ +-+ +----+ +---+ 490 A |PE1-rs | B 491 | | 492 +--------------+ 493 Figure 3: PBB Black holing Issue - CE Dual-Homing use case 495 The link between PE1-rs and CE-A is active (marked with A) while the 496 link between CE-A and PE2-rs is in Standby/Blocked status. In the 497 network diagram CMAC X is one of the MAC addresses located behind 498 CE-A in the customer domain, CMAC Y is behind CE-B and the B-VPLS 499 instances on PE1-rs are associated with BMAC B1 and PE2-rs with BMAC 500 B2. 502 As the packets flow from CMAC X to CMAC Y through PE1-rs with BMAC 503 B1, the remote PE-rs devices participating in the B-VPLS with the 504 same I-SID (for example, PE3-rs) will learn the CMAC X associated 505 with BMAC B1 on PE1-rs. Under a failure condition of the link 506 between CE-A and PE1-rs and on activation of the link to PE2-rs, the 507 remote PE-rs devices (for example, PE3-rs) will forward the traffic 508 destined for customer MAC X to BMAC B1 resulting in PE1-rs 509 blackholing that traffic until the aging timer expires or a packet 510 flows from X to Y through the PE2-rs, BMAC B2. This may take a long 511 time (default aging timer is 5 minutes) and may affect a large number 512 of flows across multiple I-components. 514 A possible solution to this issue is to use the existing LDP MAC 515 Flush as specified in [RFC4762] to flush the BMAC associated with the 516 PE-rs in the B-VPLS domain where the failure occurred. This will 517 automatically flush the CMAC to BMAC association in the remote PE-rs 518 devices. This solution has the disadvantage of producing a lot of 519 unnecessary MAC flush in the B-VPLS domain as there was no failure or 520 topology change affecting the Backbone domain. 522 A better solution which propagates the I-component events through the 523 backbone infrastructure (B-VPLS) is required in order to flush only 524 the CMAC to BMAC associations in the remote PBB-VPLS capable PE-rs 525 devices. Since there are no I-component control plane exchanges 526 across the PBB backbone, extensions to B-VPLS control plane are 527 required to propagate the I-component MAC Flush events across the 528 B-VPLS. 530 5. Solution Description 532 This section describes the solution for the requirements described in 533 section 4. 535 5.1. MAC Flush Optimization for VPLS Resiliency 537 The basic principle of the optimized MAC flush mechanism is explained 538 with reference to Figure 2. The optimization is achieved by 539 initiating MAC Flush on failure as described in section 2.2. 541 PE1-rs would initiate MAC Flush towards the core on detection of 542 failure of primary spoke PW between MTU-s and PE1-rs (or status 543 change from active to standby [RFC6718] ). This method is referred 544 to as "MAC Flush on Failure" throughout this document. The MAC Flush 545 message would indicate to receiving PE-rs devices to flush all MACs 546 learned over the PW in the context of the VPLS for which the MAC 547 flush message is received. Each PE-rs device in the full mesh that 548 receives the message identifies the VPLS instance and its respective 549 PW that terminates in PE1-rs from the FEC TLV received in the message 550 and/or LDP session. Thus the PE-rs device flushes only the MAC 551 addresses learned from that PW connected to PE1-rs, minimizing the 552 required relearning and the flooding throughout the VPLS domain. 554 This section defines a generic MAC Flush Parameters TLV for LDP 555 [RFC5036]. Through out this document the MAC Flush Parameters TLV is 556 referred as MAC Flush TLV. A MAC Flush TLV carries information on 557 the desired action at the PE-rs device receiving the message and is 558 used for optimized MAC flushing in VPLS. The MAC Flush TLV can also 559 be used for [RFC4762] style of MAC Flush as explained in section 2. 561 5.1.1. MAC Flush Parameters TLV 563 The MAC Flush Parameters TLV is described as below: 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 |1|1| MAC Flush Params TLV(TBDA)| Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Flags | Sub-TLV Type | Sub-TLV Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Sub-TLV Variable Length Value | 573 | " | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 The U and F bits are set to forward if unknown so that potential 577 intermediate VPLS PE-rs devices unaware of the new TLV can just 578 propagate it transparently. In the case of an B-VPLS network that 579 has PBB-VPLS in the core with no I-components attached this message 580 can still be useful to edge B-VPLS that do have the I-components with 581 the ISIDs and understand the message. The MAC Flush Parameters TLV 582 type is to be assigned by IANA. The encoding of the TLV follows the 583 standard LDP TLV encoding in [RFC5036] 585 The TLV value field contains a one byte Flag field used as described 586 below. Further the TLV value MAY carry one or more sub-TLVs. Any 587 sub-TLV definition to the above TLV MUST address the actions in 588 combination with other existing sub-TLVs. 590 The detailed format for the Flags bit vector is described below: 592 0 1 2 3 4 5 6 7 593 +-+-+-+-+-+-+-+-+ 594 |C|N| MBZ | (MBZ = MUST Be Zero) 595 +-+-+-+-+-+-+-+-+ 597 1 Byte Flag field is mandatory. The following flags are defined: 599 C flag, used to indicate the context of the PBB-VPLS component in 600 which MAC flush is required. For PBB-VPLS there are two contexts of 601 MAC flushing - The Backbone VPLS (B-component VPLS) and Customer VPLS 602 (I-component VPLS). C flag MUST be ZERO (C=0) when a MAC Flush for 603 the B-VPLS is required. C flag MUST be set (C=1) when the MAC Flush 604 for I-component is required. In the regular H-VPLS case the C flag 605 MUST be ZERO (C=0) to indicate the flush applies to the current VPLS 606 context. 608 N flag, used to indicate whether a positive (N=0, Flush-all-but-mine) 609 or negative (N=1 Flush-all-from-me) MAC Flush is required. The 610 source (mine/me) is defined either as the PW associated with the LDP 611 session on which the LDP MAC Withdraw was received or with the 612 BMAC(s) listed in the BMAC Sub-TLV. For the optimized MAC Flush 613 procedure described in this section the flag MUST be set (N=1). 615 Detailed usage in the context of PBB-VPLS is explained in section 616 4.2. 618 MBZ flags, the rest of the flags SHOULD be set to zero on 619 transmission and ignored on reception. 621 The MAC Flush TLV SHOULD be placed after the existing TLVs in MAC 622 Flush message in [RFC4762]. 624 5.1.2. Application of MAC Flush TLV in Optimized MAC Flush 626 For optimized MAC flush, the MAC Flush TLV MAY be sent as in existing 627 LDP Address Withdraw Message with empty MAC List but from the core 628 PE-rs on detection of failure of its local/primary spoke PW. The N 629 bit in TLV MUST be set to 1 to indicate Flush-all-from-me. If the 630 optimized MAC Flush procedure is used in a Backbone VPLS or regular 631 VPLS/H-VPLS context the C bit MUST be ZERO (C=0). If it is used in 632 an I-component context the C bit MUST be set (C= 1). See section 4.2 633 for details of its usage in PBB-VPLS context. 635 Note that the assumption is the MAC flush TLV is understood by all 636 devices before it is turned on in any network. See Operational 637 Considerations section 5. 639 The MAC withdraw procedures defined in [RFC4762], MTU-s or PE2-rs 640 SHOULD be sent in cases where the network is being upgraded and 641 devices are not capable of understanding the optimized MAC flush. 642 This would result in the same flushing action as [RFC4762] at the 643 receiving PE-rs devices. 645 For the case of B-VPLS devices optimized MAC flush message SHOULD be 646 supported. 648 5.1.3. MAC Flush TLV Processing Rules for Regular VPLS 650 This section describes the processing rules of MAC Flush TLV that 651 SHOULD be followed in the context of MAC flush procedures in VPLS. 653 For optimized MAC Flush a multi-homing PE-rs initiates MAC flush 654 message towards the other related VPLS PE-rs devices when it detects 655 a transition (failure or to standby) in its active spoke PW. In such 656 case the MAC Flush TLV MUST be sent with N= 1. A PE-rs device 657 receiving the MAC Flush TLV SHOULD follow the same processing rules 658 as described in this section. 660 Note that if MS-PW is used in VPLS then a MAC flush message is 661 processed only at the T-PE nodes since S-PE(s) traversed by the MS-PW 662 propagate MAC flush messages without any action. In this section, a 663 PE-rs device signifies only T-PE in MS-PW case unless specified 664 otherwise. 666 When a PE-rs device receives a MAC Flush TLV with N = 1, it SHOULD 667 flush all the MAC addresses learned from the PW in the VPLS in the 668 context on which the MAC Flush message is received. 670 If a MAC Flush TLV is received with N = 0 in the MAC flush message 671 then the receiving PE-rs SHOULD flush the MAC addresses learned from 672 all PWs in the VPLS instance except the ones learned over the PW on 673 which the message is received. 675 If a PE-rs device receives a MAC flush with the MAC Flush TLV option 676 and a valid MAC address list, it SHOULD ignore the option and deal 677 with MAC addresses explicitly as per [RFC4762]. It is assumed when 678 these procedures are used all nodes support the MAC Flush Message. 679 See section 5 Operational Considerations for details. 681 5.1.4. Optimized MAC Flush Procedures 683 This section explains the optimized MAC flush procedure in the 684 scenario in Figure 2. When the primary spoke PW transition (failure 685 or standby transition) is detected by PE1-rs, it MAY send MAC flush 686 messages to PE2-rs, PE3-rs and PE4-rs with MAC Flush TLV and N = 1. 687 Upon receipt of the MAC flush message, PE2-rs identifies the VPLS 688 instance that requires MAC flush from the FEC element in the FEC TLV. 689 On receiving N=1, PE-2 removes all MAC addresses learned from that PW 690 over which the message is received. The same action is followed by 691 PE3-rs and PE4-rs. 693 Figure 4 shows another redundant H-VPLS topology to protect against 694 failure of MTU-s device. Provider RSTP [IEEE.802.1Q-2011] may be 695 used as selection algorithm for active and backup PWs in order to 696 maintain the connectivity between MTU-s devices and PE-rs devices at 697 the edge. It is assumed that PE-rs devices can detect failure on PWs 698 in either direction through OAM mechanisms such as VCCV procedures 699 for instance. 701 MTU-1================PE-1-rs=============PE-3-rs 702 || || \ /|| 703 || Redundancy || \ / || 704 || Provider RSTP || Full-Mesh . || 705 || || / \ || 706 || || / \|| 707 MTU-2----------------PE-2-rs=============PE-4-rs 708 Backup PW 710 Figure 4: Redundancy with Provider RSTP 712 MTU-1, MTU-2, PE1-rs and PE2-rs participate in provider RSTP. By 713 configuration in RSTP it is ensured that the PW between MTU-1 and 714 PE1-rs is active and the PW between MTU-2 and PE2-rs is blocked (made 715 backup) at MTU-2 end. When the active PW failure is detected by 716 RSTP, it activates the PW between MTU-2 and PE2-rs. When PE1-rs 717 detects the failing PW to MTU-1, it MAY trigger MAC flush into the 718 full mesh with MAC Flush TLV that carries N=1. Other PE-rs devices 719 in the full mesh that receive the MAC flush message identify their 720 respective PWs terminating on PE1-rs and flush all the MAC addresses 721 learned from it. 723 [RFC4762] describes multi-domain VPLS service where fully meshed VPLS 724 networks (domains) are connected together by a single spoke PW per 725 VPLS service between the VPLS "border" PE-rs devices. To provide 726 redundancy against failure of the inter-domain spoke, full mesh of 727 inter-domain spokes can be setup between border PE-rs devices and 728 provider RSTP may be used for selection of the active inter-domain 729 spoke. In case of inter-domain spoke PW failure, PE-rs initiated MAC 730 withdrawal MAY be used for optimized MAC flushing within individual 731 domains. 733 Further, the procedures are applicable with any native Ethernet 734 access topologies multi-homed to two or more VPLS PE-rs devices. The 735 text in this section applies for the native Ethernet case where 736 active/standby PWs are replaced with the active/standby Ethernet 737 endpoints. An optimized MAC Flush message can be generated by the 738 VPLS PE-rs that detects the failure in the primary Ethernet access. 740 5.2. LDP MAC Flush Extensions for PBB-VPLS 742 The use of Address Withdraw message with MAC List TLV is proposed in 743 [RFC4762] as a way to expedite removal of MAC addresses as the result 744 of a topology change (e.g. failure of a primary link of a VPLS PE-rs 745 device and implicitly the activation of an alternate link in a dual- 746 homing use case). These existing procedures apply individually to 747 B-VPLS and I-component domains. 749 When it comes to reflecting topology changes in access networks 750 connected to I-component across the B-VPLS domain certain additions 751 should be considered as described below. 753 MAC Switching in PBB is based on the mapping of Customer MACs (CMACs) 754 to Backbone MAC(s) (BMACs). A topology change in the access 755 (I-domain) should just invoke the flushing of CMAC entries in PBB 756 PEs' FIB(s) associated with the I-component(s) impacted by the 757 failure. There is a need to indicate the PBB PE (BMAC source) that 758 originated the MAC Flush message to selectively flush only the MACs 759 that are affected. 761 These goals can be achieved by including the MAC Flush Parameters TLV 762 in the LDP Address Withdraw message to indicate the particular 763 domain(s) requiring MAC flush. On the other end, the receiving PEs 764 SHOULD use the information from the new TLV to flush only the related 765 FIB entry/entries in the I-component instance(s). 767 At least one of the following sub-TLVs MUST be included in the MAC 768 Flush Parameters TLV if the C-flag is set to 1: 770 o PBB BMAC List Sub-TLV: 772 Type: IANA TBDB 774 Length: value length in octets. At least one BMAC address MUST be 775 present in the list. 777 Value: one or a list of 48 bits BMAC addresses. These are the source 778 BMAC addresses associated with the B-VPLS instance that originated 779 the MAC Withdraw message. It will be used to identify the CMAC(s) 780 mapped to the BMAC(s) listed in the sub-TLV. 782 o PBB ISID List Sub-TLV: 784 Type: IANA TBDC 786 Length: value length in octets. Zero indicates an empty ISID list. 787 An empty ISID list means that the flush applies to all the ISIDs 788 mapped to the B-VPLS indicated by the FEC TLV. 790 Value: one or a list of 24 bits ISIDs that represent the I-component 791 FIB(s) where the MAC Flush needs to take place. 793 5.2.1. MAC Flush TLV Processing Rules for PBB-VPLS 795 The following steps describe the details of the processing rules for 796 MAC Flush TLV in the context of PBB-VPLS: 798 The MAC Flush can be for the B-VPLS B-component (which applies to the 799 BMACs and the corresponding CMACs) or the B-VPLS I-component (which 800 applies to the CMACs) which is described in more detail here. 802 - The MAC Flush Message, including the MAC Flush Parameters TLV is 803 initiated by the PBB PE(s) experiencing a Topology Change event in 804 one or multiple customer I-component(s). 806 - The flags are set accordingly to indicate the type of MAC Flush 807 required for this event: For example for an B-VPLS I-Component N=0 808 (Flush-all-but-mine), C=1 (Flush only CMAC FIBs). 810 - The PBB Sub-TLVs (BMAC and ISID Lists) are included according to 811 the context of topology change. 813 - On reception of the MAC Flush message, the B-VPLS instances 814 corresponding to the FEC TLV in the message must interpret the 815 content of MAC Flush Parameters TLV. If the C-bit is set to 1 then 816 Backbone Core Bridges (BCB) in the PBB-VPLS SHOULD NOT flush their 817 BMAC FIBs. The B-VPLS control plane SHOULD propagate the MAC Flush 818 following the data-plane split-horizon rules to the established 819 B-VPLS topology. 821 - The usage and processing rules of MAC Flush Parameters TLV in the 822 context of Backbone Edge Bridges (BEB) is as follows: 824 - The PBB ISID List is used to determine the particular ISID FIBs 825 (I-component) that need to be considered for flushing action. If the 826 PBB ISID List sub-tlv is not included in a received message then all 827 the ISID FIBs associated with the receiving B-VPLS SHOULD be 828 considered for flushing action. 830 - The PBB BMAC List is used to identify from the ISID FIBs in the 831 previous step to selectively flush BMAC to CMAC associations 832 depending on the N flag specified below. If PBB BMAC List Sub-TLV is 833 not included in a received message then all BMAC to CMAC association 834 in all ISID FIBs (I-component) as specified by the ISID List are 835 considered for required flushing action, again depending on the N 836 flag specified below. 838 - Next, depending on the N flag value the following actions apply: 840 - N=0, all the CMACs in the selected ISID FIBs SHOULD be flushed with 841 the exception of the resulted CMAC list from the BMAC List mentioned 842 in the message. ("Flush all but the CMACs associated with the 843 BMAC(s) in the BMAC List Sub-TLV from the FIBs associated with the 844 ISID list"). 846 - N=1, all the resulted CMACs SHOULD be flushed ("Flush all the CMACs 847 associated with the BMAC(s) in the BMAC List Sub-TLV from the FIBs 848 associated with the ISID list"). 850 5.2.2. Applicability of MAC Flush Parameters TLV 852 If MAC Flush Parameters TLV is received by a Backbone Edge Bridges 853 (BEB) in a PBB-VPLS that does not understand the TLV then it may 854 result in undesirable MAC flushing action. It is RECOMMENDED that 855 all PE-rs devices participating in PBB-VPLS support MAC Flush 856 Parameters TLV. If this is not possible the MAC Flush Parameters TLV 857 SHOULD be disabled as mentioned in section 5 Operational 858 Considerations. 860 The MAC Flush Parameters TLV is also applicable to regular VPLS 861 context as well as explained in section 3.1.1. To achieve negative 862 MAC Flush (flush-all-from-me) in regular VPLS context, the MAC Flush 863 Parameters TLV SHOULD be encoded with C=0 and N = 1 without inclusion 864 of any Sub-TLVs. Negative MAC flush is highly desirable in scenarios 865 when VPLS access redundancy is provided by Ethernet Ring Protection 866 as specified in ITU-T [ITU.G8032]specification. 868 6. Operational Considerations 870 As mentioned before, if MAC Flush Parameters TLV is not understood by 871 a receiver then it would result in undesired flushing action. To 872 avoid this one solution is to develop an LDP based capability 873 negotiation mechanism to negotiate support of various MAC Flushing 874 capability between PE-rs devices in a VPLS instance. A negotiation 875 mechanism is outside the scope of this document but is not required 876 to deploy this optimized MAC flush as described below. 878 VPLS may be used with or without the optimization. For the case of 879 PBB-VPLS this operation is the only method supported for ISIDs. If 880 an operator wants the optimizations for VPLS it is the operator's 881 responsibility to make sure the VPLS that are capable of supporting 882 the optimization are properly configured. From operational 883 standpoint, it is RECOMMENDED that implementations of the solution 884 provide administrative control to select the desired MAC Flushing 885 action towards a PE-rs device in the VPLS. Thus in the topology 886 described in figure 2, it is possible that PE1-rs would initiate 887 optimized MAC Flush towards the PE-rs devices that support the 888 solution whereas PE2-rs would initiate [RFC4762] style of MAC Flush 889 towards the PE-rs devices that do not support the optimized solution. 890 The PE-rs that supports the MAC Flush Parameters TLV MUST support the 891 RFC4762 MAC flush procedure for completeness. 893 7. IANA Considerations 895 7.1 New LDP TLV 897 IANA maintains a registry called "Label Distribution Protocol (LDP) 898 Parameters" with a sub-registry called "TLV Type Name Space". 900 IANA is requested to allocate three new code points from the 901 unassigned range 0x0405-0x04FF as follows. IANA is requested to 902 allocate consecutive numbers. 904 Value | Description | Reference | Notes 905 ------+--------------------------+------------+----------- 906 TBDA | MAC Flush Parameters TLV | [This.I-D] | 907 TBDB | PBB BMAC List Sub-TLV | [This.I-D] | 908 TBDC | PBB ISID List Sub-TLV | [This.I-D] | 910 7.2 New Registry for MAC Flush Flags 912 IANA is requested to create a new sub-registry under "Label 913 Distribution Protocol (LDP) Parameters" called "MAC Flush Flags". 915 IANA is requested to populate the registry as follows: 917 Bit number | Hex | Abbreviation | Description | Reference 918 -----------+------+--------------+------------------+------------ 919 0 | 0x80 | C | Context | [This.I-D] 920 1 | 0x40 | N | Negative flush | [This.I-D] 921 2-7 | | | Unassigned | 923 Other new bits are to be assigned by Standards Action. 925 8. Security Considerations 927 Control plane aspects: 929 LDP security (authentication) methods as described in [RFC5036] is 930 applicable here. Further this document implements security 931 considerations as in [RFC4447] and [RFC4762]. The extensions defined 932 here optimize the flushing and so the risk of security attacks is 933 reduced. However, in the event that the configuration of support for 934 the new TLV can be spoofed, sub-optimal behavior will be seen. 936 Data plane aspects: 938 This specification does not have any impact on the VPLS forwarding 939 plane but can improve MAC flushing behavior. 941 9. Contributing Authors 943 The authors would like to thank Marc Lasserre and Don Fedyk who made 944 a major contribution to the development of this document. 946 Marc Lasserre 948 Alcatel-Lucent 950 Email: marc.lasserre@alcatel-lucent.com 952 Don Fedyk 954 Hewlett-Packard Company 956 Email: don.fedyk@hp.com 958 10. Acknowledgements 960 The authors would like to thank the following people who have 961 provided valuable comments and feedback on the topics discussed in 962 this document: Dimitri Papadimitriou, Jorge Rabadan, Prashanth 963 Ishwar, Vipin Jain, John Rigby, Ali Sajassi, Wim Henderickx, Paul 964 Kwok, Maarten Vissers, Daniel Cohn, Nabil Bitar, Giles Heron and 965 Adrian Farrel. 967 11. References 969 11.1. Normative References 971 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 972 Requirement Levels", BCP 14, RFC 2119, March 1997. 974 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 975 Heron, "Pseudowire Setup and Maintenance Using the Label 976 Distribution Protocol (LDP)", RFC 4447, April 2006. 978 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 979 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 980 RFC 4762, January 2007. 982 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 983 Specification", RFC 5036, October 2007. 985 11.2. Informative References 987 [RFC7041] Balus, F., Sajassi, A., and N. Bitar, "Extensions to the 988 Virtual Private LAN Service (VPLS) Provider Edge (PE) 989 Model for Provider Backbone Bridging",RFC 7041, 990 November 2013. 992 [I-D.ietf-l2vpn-vpls-multihoming] 993 Kothari, B., Kompella, K., Henderickx, W., Balus, F., 994 Palislamovic, S., Uttaro, J., and W. Lin, "BGP based 995 Multi-homing in Virtual Private LAN Service", 996 draft-ietf-l2vpn-vpls-multihoming-06 (work in progress), 997 October 2012. 999 [IEEE.802.1Q-2011] 1000 IEEE, "IEEE Standard for Local and metropolitan area 1001 networks -- Media Access Control (MAC) Bridges and Virtual 1002 Bridged Local Area Networks", IEEE Std 802.1Q, 2011. 1004 [ITU.G8032] 1005 International Telecommunications Union, "Ethernet ring 1006 protection switching", ITU-T Recommendation G.8032, 1007 March 2010. 1009 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1010 Private Networks (L2VPNs)", RFC 4664, September 2006. 1012 [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire 1013 Redundancy", RFC 6718, August 2012. 1015 Authors' Addresses 1017 Pranjal Kumar Dutta 1018 Alcatel-Lucent 1019 701 E Middlefield Road 1020 Mountain View, California 94043 1021 USA 1023 Email: pranjal.dutta@alcatel-lucent.com 1025 Florin Balus 1026 Alcatel-Lucent 1027 701 E Middlefield Road 1028 Mountain View, California 94043 1029 USA 1031 Email: florin.balus@alcatel-lucent.com 1032 Olen Stokes 1033 Extreme Networks 1034 PO Box 14129, RTP 1035 Raleigh, North Carolina 27709 1036 USA 1038 Email: ostokes@extremenetworks.com 1040 Geraldine Calvinac 1041 France Telecom 1042 2, avenue Pierre-Marzin 1043 Lannion Cedex, 22307 1044 France 1046 Email: geraldine.calvignac@orange-ftgroup.com