idnits 2.17.1 draft-ietf-l2vpn-vpls-ldp-mac-opt-13.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 (June 27, 2014) is 3583 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: 'I-D.ietf-l2vpn-vpls-multihoming' is defined on line 1054, but no explicit reference was found in the text ** 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 (~~), 3 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: December 29, 2014 O. Stokes 6 Extreme Networks 7 G. Calvignac 8 Orange 9 D. Fedyk 10 Hewlett-Packard 11 June 27, 2014 13 LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS 14 draft-ietf-l2vpn-vpls-ldp-mac-opt-13 16 Abstract 18 RFC4762 describes a mechanism to remove or unlearn MAC addresses that 19 have been dynamically learned in a Virtual Private LAN Service (VPLS) 20 Instance for faster convergence on topology change. The procedure 21 also removes MAC addresses in the VPLS that do not require relearning 22 due to such topology change. This document defines an enhancement to 23 the MAC Address Withdrawal procedure with empty MAC List from 24 RFC4762, which enables a Provider Edge(PE) device to remove only the 25 MAC addresses that need to be relearned. Additional extensions to 26 RFC4762 MAC Withdrawal procedures are specified to provide optimized 27 MAC flushing for the Provider Backbone Bridging (PBB)VPLS specified 28 in RFC7041. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in [RFC2119]. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 31, 2014. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1. MAC Flush on activation of backup spoke PW . . . . . . . . 7 74 3.1.1. PE-rs initiated MAC Flush . . . . . . . . . . . . . . 8 75 3.1.2. MTU-s initiated MAC flush . . . . . . . . . . . . . . 8 76 3.2. MAC Flush on failure . . . . . . . . . . . . . . . . . . . 9 77 3.3. MAC Flush in PBB-VPLS . . . . . . . . . . . . . . . . . . 9 78 4. Problem Description . . . . . . . . . . . . . . . . . . . . . 10 79 4.1. MAC Flush Optimization in VPLS Resiliency . . . . . . . . 10 80 4.1.1. MAC Flush Optimization for regular H-VPLS . . . . . . 10 81 4.1.2. MAC Flush Optimization for native Ethernet access . . 12 82 4.2. Black holing issue in PBB-VPLS . . . . . . . . . . . . . . 13 83 5. Solution Description . . . . . . . . . . . . . . . . . . . . . 14 84 5.1. MAC Flush Optimization for VPLS Resiliency . . . . . . . . 14 85 5.1.1. MAC Flush Parameters TLV . . . . . . . . . . . . . . . 15 86 5.1.2. Application of the MAC Flush TLV in Optimized MAC 87 Flush . . . . . . . . . . . . . . . . . . . . . . . . 16 88 5.1.3. MAC Flush TLV Processing Rules for Regular VPLS . . . 16 89 5.1.4. Optimized MAC Flush Procedures . . . . . . . . . . . . 17 90 5.2. LDP MAC Flush Extensions for PBB-VPLS . . . . . . . . . . 18 91 5.2.1. MAC Flush TLV Processing Rules for PBB-VPLS . . . . . 20 92 5.2.2. Applicability of the MAC Flush Parameters TLV . . . . 21 93 6. Operational Considerations . . . . . . . . . . . . . . . . . . 22 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 95 7.1 New LDP TLV . . . . . . . . . . . . . . . . . . . . . . . . 23 96 7.2 New Registry for MAC Flush Flags . . . . . . . . . . . . . . 23 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 98 9. Contributing Author . . . . . . . . . . . . . . . . . . . . . 24 99 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 102 11.2. Informative References . . . . . . . . . . . . . . . . . 24 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 105 1. Introduction 107 A method of Virtual Private LAN Service (VPLS), also known as 108 Transparent LAN Service (TLS) is described in [RFC4762]. A VPLS is 109 created using a collection of one or more point-to-point pseudowires 110 (PWs) [RFC4664] configured in a flat, full-mesh topology. The mesh 111 topology provides a LAN segment or broadcast domain that is fully 112 capable of learning and forwarding on Ethernet MAC addresses at the 113 PE devices. 115 This VPLS full mesh core configuration can be augmented with 116 additional non-meshed spoke nodes to provide a Hierarchical VPLS 117 (H-VPLS) service [RFC4762]. Throughout this document this 118 configuration is referred to as "regular" H-VPLS. 120 [RFC7041] describes how Provider Backbone Bridging (PBB) can be 121 integrated with VPLS to allow for useful PBB capabilities while 122 continuing to avoid the use of Multiple Spanning Tree Protocol (MSTP) 123 in the backbone. The combined solution referred to as PBB-VPLS 124 results in better scalability in terms of number of service 125 instances, PWs and C-MAC (Customer MAC) Addresses that need to be 126 handled in the VPLS PEs depending on the location of the I-component 127 in the PBB-VPLS topology. 129 A MAC Address Withdrawal mechanism for VPLS is described in [RFC4762] 130 to remove or unlearn MAC addresses for faster convergence on topology 131 change in resilient H-VPLS topologies. Note that the H-VPLS topology 132 in [RFC4762] describes two tier hierarchy to VPLS as the basic 133 building block of H-VPLS, but it is possible to have multi-tier 134 hierarchy in an H-VPLS. 136 Figure 1, is reproduced below from [RFC4762] illustrating dual-homing 137 in H-VPLS. 139 PE2-rs 140 +--------+ 141 | | 142 | -- | 143 | / \ | 144 CE-1 | \S / | 145 \ | -- | 146 \ +--------+ 147 \ MTU-s PE1-rs / | 148 +--------+ +--------+ / | 149 | | | | / | 150 | -- | Primary PW | -- |---/ | 151 | / \ |- - - - - - - - - - - | / \ | | 152 | \S / | | \S / | | 153 | -- | | -- |---\ | 154 +--------+ +--------+ \ | 155 / \ \ | 156 / \ +--------+ 157 / \ | | 158 CE-2 \ | -- | 159 \ Secondary PW | / \ | 160 - - - - - - - - - - - - - - - - - | \S / | 161 | -- | 162 +--------+ 163 PE3-rs 164 Figure 1: An example of a dual-homed MTU-s 166 An example usage of the MAC Flush mechanism is the dual-homed H-VPLS 167 where an edge device termed as Multi Tenant Unit switch (MTU- 168 s)[RFC4762], is connected to two PE devices via primary spoke PW and 169 backup spoke PW respectively. Such redundancy is designed to protect 170 against the failure of primary spoke PW or primary PE device. There 171 could be multiple methods of dual homing in H-VPLS that are not 172 described in [RFC4762]. For example, note the following statement 173 from section 10.2.1 in [RFC4762]. 175 "How a spoke is designated primary or secondary is outside the scope 176 of this document. For example, a spanning tree instance running 177 between only the MTU-s and the two PE-rs nodes is one possible 178 method. Another method could be configuration". 180 This document intends to clarify several H-VPLS dual-homing models 181 that are deployed in practice and various use cases of LDP based MAC 182 flush in these models. 183 2. Terminology 184 This document uses the terminology defined in [RFC7041], [RFC5036], 185 [RFC4447] and [RFC4762]. 187 Throughout this document Virtual Private LAN Service (VPLS) means the 188 emulated bridged LAN service offered to a customer. H-VPLS means the 189 hierarchical connectivity or layout of Multi Tenant Unit switch (MTU- 190 s) and Provider Edge Routing and switching capable (PE-rs) devices 191 offering the VPLS [RFC4762]. 193 The terms "Spoke Node" and "MTU-s" in H-VPLS are used 194 interchangeably. 196 "Spoke PW" means the Pseudowire PW that provides connectivity between 197 MTU-s and PE-rs nodes. 199 "Mesh PW" means the PW that provides connectivity between PE-rs nodes 200 in a VPLS full mesh core. 202 "MAC Flush Message" means Label Distribution Protocol (LDP) Address 203 Withdraw Message without MAC List TLV. 205 A MAC Flush Message in the "context of a Pseudo Wire (PW)" means the 206 Message that has been received over the LDP session that is used to 207 set up the PW used to provide connectivity in VPLS. The MAC Flush 208 Message carries the context of the PW in terms of Forwarding 209 Equivalence Class (FEC) TLV associated with the PW 210 [RFC4762][RFC4447]. 212 In general, "MAC Flush" means the method of initiating and processing 213 of MAC Flush Messages across a VPLS instance. 215 3. Overview 217 When the MTU-s switches over to the backup PW, the requirement is to 218 flush the MAC addresses learned in the corresponding Virtual Switch 219 Instance (VSI) in peer PE devices participating in the full mesh, to 220 avoid black holing of frames to those addresses. This is 221 accomplished by sending an LDP Address Withdraw Message, a new 222 message defined in this document, from the PE that is no longer 223 connected to the MTU-s with the primary PW. The new message has the 224 list of MAC addresses to be removed to all other PEs over the 225 corresponding LDP sessions. 227 In order to minimize the impact on LDP convergence time and 228 scalability when a MAC List TLV contains a large number of MAC 229 addresses, many implementations use a LDP Address Withdraw Message 230 with an empty MAC List. When a PE-rs switch in the full-mesh of H- 231 VPLS receive this message it also flushes MAC addresses which are not 232 affected due to topology change, thus leading to unnecessary flooding 233 and relearning. Throughout this document the term "MAC Flush Message" 234 is used to specify LDP Address Withdraw Message with an empty MAC 235 List described in [RFC4762]. The solutions described in this document 236 are applicable only to LDP Address Withdraw Message with empty MAC 237 List. 239 In a VPLS topology, the core PWs remain active and learning happens 240 on the PE-rs nodes. However when the VPLS topology changes, the 241 PE-rs must relearn using MAC Addresses withdrawal or flush. As per 242 the MAC Address Withdrawal processing rules in [RFC4762] a PE device 243 on receiving a MAC Flush Message removes all MAC addresses associated 244 with the specified VPLS instance (as indicated in the FEC TLV) except 245 the MAC addresses learned over the PW associated with this signaling 246 session over which the message was received. Throughout this 247 document we use the terminology "Positive" MAC Flush or "Flush-all- 248 but-mine" for this type of MAC Flush Message and its actions. 250 This document introduces an optimized "Negative" MAC flush described 251 in section 3.2 that can be configured to improve the response to 252 topology change in a number of Ethernet topologies where the SLA is 253 dependent on minimal disruption and fast restoration of affected 254 traffic. This new message is used in the case of Provider Backbone 255 Bridging (PBB) topologies to restrict the flushing to a set of 256 Service Instances (ISIDs). It is also important to note that the 257 Positive MAC Flush described in [RFC4762] MUST always be handled for 258 BMACs in cases where the core nodes change or fail. Where there is 259 dual or multihomed edge topology, the procedures in this document 260 augment [RFC4762] messages providing less disruption for those cases. 262 3.1. MAC Flush on activation of backup spoke PW 264 This section describes scenarios where MAC Flush withdrawal is 265 initiated on activation of backup PW in H-VPLS. 267 3.1.1. PE-rs initiated MAC Flush 269 [RFC4762] specifies that on failure of the primary PW, it is the 270 PE3-rs (Figure 1) that initiates MAC flush towards the core. However 271 note that PE3-rs can initiate MAC Flush only when PE3-rs is dual 272 homing "aware" - that is, there is some redundancy management 273 protocol running between MTU-s and its host PE-rs devices. The scope 274 of this document is applicable to several dual-homing or multihoming 275 protocols. The document illustrates that multihoming can be improved 276 with the Negative MAC flush. One example is BGP based multi-homing 277 in LDP based VPLS that uses the procedures defined in [I-D.ietf- 278 l2vpn-vpls-multihoming]. In this method of dual-homing, PE3-rs would 279 neither forward any traffic to MTU-s nor would it receive any traffic 280 from MTU-s while PE1-rs is acting as a primary (or designated 281 forwarder). 283 3.1.2. MTU-s initiated MAC flush 285 When dual homing is achieved by manual configuration in MTU-s, the 286 hosting PE-rs devices are dual homing "agnostic" and PE3-rs can not 287 initiate MAC Flush messages. PE3-rs can send or receive traffic over 288 the backup PW since the dual-homing control is with MTU-s only. When 289 the backup PW is made active by the MTU-s, the MTU-s triggers a MAC 290 Flush Message. The message is sent over the LDP session associated 291 with the newly activated PW. On receiving the MAC Flush Message from 292 MTU-s, PE3-rs (PE-rs device with now-active PW) would flush all the 293 MAC addresses it has learned except the ones learned over the newly 294 activated spoke PW. PE3-rs further initiates a MAC Flush Message to 295 all other PE devices in the core. Note that forced switchover to 296 backup PW can be also performed at MTU-s administratively due to 297 maintenance activities on the former primary spoke PW. 299 MTU-s initiated method of MAC flushing is modeled after Topology 300 Change Notification (TCN) in Rapid Spanning Tree Protocol (RSTP) 301 [IEEE.802.1Q-2011]. When a bridge switches from a failed link to the 302 backup link, the bridge sends out a TCN message over the newly 303 activated link. The upstream bridge upon receiving this message 304 flushes its entire MAC addresses except the ones received over this 305 link and sends the TCN message out of its other ports in that 306 spanning tree instance. The message is further relayed along the 307 spanning tree by the other bridges. 309 The MAC Flush information is propagated in the control plane. The 310 control plane message propagation is associated with the data path 311 and hence follows similar rules for propagation as the forwarding in 312 the LDP data plane. For example PE-rs nodes follow the data plane 313 "split-horizon" forwarding rules in H-VPLS (Refer to section 4.4 in 314 [RFC4762]). Therefore a MAC Flush is propagated in the context of 315 mesh PW(s) when it is received in the context of a spoke PW. When a 316 PE-rs node receives a MAC Flush in the context of a mesh PW then it 317 is not propagated to other mesh PWs. 319 3.2. MAC Flush on failure 321 MAC Flush on failure or "negative" MAC flush is introduced in this 322 document. Negative MAC flush is an improvement on the current 323 practice of sending a MAC Flush Message with an empty MAC list 324 described in section 3.1.1. We use the term "negative" MAC flush or 325 "Flush-all-from-me" for this kind of flushing action as opposed to 326 "positive" MAC Flush action in [RFC4762]. In negative MAC flush, the 327 MAC Flush is initiated by PE1-rs (Figure 1) on detection of failure 328 of the primary spoke PW. The MAC Flush is sent to all participating 329 PE-rs devices in the VPLS full-mesh. PE1-rs should initiate MAC 330 flush only if PE1-rs is dual homing aware. (If PE1-rs is dual homing 331 agnostic, the policy is do not initiate a MAC flush on failure, since 332 that could cause unnecessary flushing in the case of single homed 333 MTU-s.) The specific dual-homing protocols for this scenario are 334 outside the scope of this document but the operator can choose to use 335 the optimized MAC flush described in this document or the [RFC4762] 336 procedures. 338 The procedure for negative MAC flush is beneficial and results in 339 less disruption than the [RFC4762] procedures including when the MTU- 340 s is dual homed with a variety of Ethernet technologies not just LDP. 341 The Negative MAC flush is a more targeted MAC flush and the other PE- 342 rs nodes will flush only the specified MACs. This targeted MAC flush 343 cannot be achieved with the MAC Address Withdraw Message defined in 344 [RFC4762]. The negative MAC flush typically results in a smaller 345 set of MACs to be flushed and results in less disruption for these 346 topologies. 348 Note that in the case of negative flush the list SHOULD be only the 349 MACs for the affected MTU-s. If the list is empty then the negative 350 flush will result in flushing and relearning all attached MTU-s's for 351 the originating PE-rs. 353 3.3. MAC Flush in PBB-VPLS 355 [RFC7041] describes how PBB can be integrated with VPLS to allow for 356 useful PBB capabilities while continuing to avoid the use of MSTP in 357 the backbone. The combined solution referred to as "PBB-VPLS" 358 results in better scalability in terms of number of service 359 instances, PWs and C-MACs that need to be handled in the VPLS PE-rs 360 devices. This document describes extensions to LDP MAC Flush 361 procedures described in [RFC4762] required to build desirable 362 capabilities to PBB-VPLS solution. 364 The solution proposed in this document is generic and is applicable 365 when Multi Segment Pseudowires (MS-PW)s [RFC6073] are used in 366 interconnecting PE devices in H-VPLS. There could be other H-VPLS 367 models not defined in this document where the solution may be 368 applicable. 370 4. Problem Description 372 This section describes the problems in detail with respective to 373 various MAC flush actions described in section 3. 375 4.1. MAC Flush Optimization in VPLS Resiliency 377 This section describes the optimizations required in MAC flush 378 procedures when H-VPLS resiliency is provided by primary and backup 379 spoke PWs. 381 4.1.1. MAC Flush Optimization for regular H-VPLS 383 Figure 2, shows a dual-homed H-VPLS scenario for a VPLS instance 384 where the problem with the existing MAC flush method explained in 385 section 3. 387 PE1-rs PE3-rs 388 +--------+ +--------+ 389 | | | | 390 | -- | | -- | 391 Customer Site 1 | / \ |------------------| / \ |->Z 392 X->CE-1 /-----| \s / | | \s / | 393 \ primary spoke PW | -- | /------| -- | 394 \ / +--------+ / +--------+ 395 \ (MTU-s)/ | \ / | 396 +--------+/ | \ / | 397 | | | \ / | 398 | -- | | \ / | 399 | / \ | | H-VPLS Full Mesh Core| 400 | \s / | | / \ | 401 | -- | | / \ | 402 /+--------+\ | / \ | 403 / backup spoke PW | / \ | 404 / \ +--------+ \--------+--------+ 405 Y->CE-2 \ | | | | 406 Customer Site 2 \------| -- | | -- | 407 | / \ |------------------| / \ |-> 408 | \s / | | \s / | 409 | -- | | -- | 410 +--------+ +--------+ 411 PE2-rs PE4-rs 413 Figure 2: Dual homed MTU-s in two tier hierarchy H-VPLS 415 In Figure 2, the MTU-s is dual-homed to PE1-rs and PE2-rs. Only the 416 primary spoke PW is active at MTU-s, thus PE1-rs is acting as the 417 active device (designated forwarder) to reach the full mesh in the 418 VPLS instance. The MAC addresses of nodes located at access sites 419 (behind CE1 and CE2) are learned at PE1-rs over the primary spoke PW. 420 Let's say X represents a set of such MAC addresses located behind 421 CE-1. MAC Z represents one of a possible set of other destination 422 MACs. As packets flow from X to other MACs in the VPLS network, 423 PE2-rs, PE3-rs and PE4-rs learn about X on their respective mesh PWs 424 terminating at PE1-rs. When MTU-s switches to the backup spoke PW 425 and activates it, PE2-rs becomes the active device (designated 426 forwarder) to reach the full mesh core for MTU-s. Traffic entering 427 the H-VPLS from CE-1 and CE-2 is diverted by the MTU-s to the spoke 428 PW to PE2-rs. Traffic destined from PE2-rs, PE3-rs and PE4-rs to X 429 will be blackholed till MAC address aging timer expires (default is 5 430 minutes) or a packet flows from X to other addresses through PE2-rs. 432 For example, if after the backup spoke PW is active, if a packet 433 flows from MAC Z to MAC X, packets from MAC Z travel from PE3-rs to 434 PE-1rs and are dropped. However, if a packet with MAC X as source 435 and MAC Z as destination arrives at PE2-rs, PE2-rs will now learn MAC 436 X is on the backup spoke PW and will forward to MAC Z. At this point 437 traffic from PE3-rs to MAC X will go to PE2-rs, since PE-3rs has also 438 learned about MAC X. Therefore a mechanism is required to make this 439 learning more timely in cases where traffic is not bidirectional. 441 To avoid traffic blackholing the MAC addresses that have been learned 442 in the upstream VPLS full-mesh through PE1-rs, must be relearned or 443 removed from the MAC FIBs in the VSIs at PE2-rs, PE3-rs and PE4-rs. 444 If PE1-rs and PE2-rs are dual-homing agnostic then on activation of 445 the standby PW from MTU-s, a MAC flush message will be sent by MTU-s 446 to PE2-rs that will flush all the MAC addresses learned in the VPLS 447 instance at PE2-rs from all the other PWs but the PW connected to 448 MTU-s. 450 PE2-rs further relays the MAC flush messages to all other PE-rs 451 devices in the full mesh. The same processing rule applies at all 452 those PE-rs devices: all the MAC addresses are flushed but the ones 453 learned on the PW connected to PE2-rs. For example, at PE3-rs all of 454 the MAC addresses learned from the PWs connected to PE1-rs and PE4-rs 455 are flushed and relearned subsequently. Before the relearning 456 happens flooding of unknown destination MAC addresses takes place 457 throughout the network. As the number of PE-rs devices in the full- 458 mesh increases, the number of unaffected MAC addresses flushed in a 459 VPLS instance also increases, thus leading to unnecessary flooding 460 and relearning. With large number of VPLS instances provisioned in 461 the H-VPLS network topology the amount of unnecessary flooding and 462 relearning increases. An optimization, described below, is required 463 that will flush only the MAC addresses learned from the respective 464 PWs between PE1-rs and other PE devices in the full-mesh minimizing 465 the relearning and flooding in the network. In the example above, 466 only the MAC addresses in set X and Y (shown in Figure 2) need to be 467 flushed across the core. 469 The same case is applicable when PE1-rs and PE2-rs are dual homing 470 aware and participate in a designated forwarder election. When 471 PE2-rs becomes the active device for MTU-s then PE2-rs MAY initiate 472 MAC flush towards the core. The receiving action of the MAC Flush in 473 other PE-rs devices is the same as in MTU-s initiated MAC Flush. This 474 is the [RFC4762] specified behavior. 476 4.1.2. MAC Flush Optimization for native Ethernet access 478 The analysis in section 4.1.1 applies also to the native Ethernet 479 access into a VPLS. In such a scenario one active and one or more 480 standby endpoints terminate into two or more VPLS or H-VPLS PE-rs 481 devices. Examples of these dual homed access are ITU-T [ITU.G8032] 482 access rings or any proprietary multi-chassis LAG emulations. Upon 483 failure of the active native Ethernet endpoint on PE1-rs, an 484 optimized MAC flush is required to be initiated by PE1-rs to ensure 485 that on PE2-rs, PE3-rs and PE4-rs only the MAC addresses learned from 486 the respective PWs connected to PE1-rs are being flushed. 488 4.2. Black holing issue in PBB-VPLS 490 In a PBB-VPLS deployment a B-component VPLS (B-VPLS) may be used as 491 infrastructure to support one or more I-component instances. The 492 B-VPLS control plane (LDP Signaling) and learning of "Backbone" MACs 493 (BMACs) replaces I-component control plane and learning of customer 494 MACs (CMACs) throughout the MPLS core. This raises an additional 495 challenge related to black hole avoidance in the I-component domain 496 as described in this section. Figure 3 describes the case of a CE 497 device (node A) dual-homed to two I-component instances located on 498 two PBB-VPLS PEs (PE1-rs and PE2-rs). 499 IP/MPLS Core 500 +--------------+ 501 |PE2-rs | 502 +----+ | 503 |PBB | +-+ | 504 |VPLS|---|P| | 505 S/+----+ /+-+\ |PE3-rs 506 / +----+ / \+----+ 507 +---+/ |PBB |/ +-+ |PBB | +---+ 508 CMAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--CMAC Y 509 +---+ A +----+ +-+ +----+ +---+ 510 A |PE1-rs | B 511 | | 512 +--------------+ 513 Figure 3: PBB Black holing Issue - CE Dual-Homing use case 515 The link between PE1-rs and CE-A is active (marked with A) while the 516 link between CE-A and PE2-rs is in Standby/Blocked status. In the 517 network diagram CMAC X is one of the MAC addresses located behind 518 CE-A in the customer domain, CMAC Y is behind CE-B and the B-VPLS 519 instances on PE1-rs are associated with BMAC B1 and PE2-rs with BMAC 520 B2. 522 As the packets flow from CMAC X to CMAC Y through PE1-rs with BMAC 523 B1, the remote PE-rs devices participating in the B-VPLS with the 524 same ISID (for example, PE3-rs) will learn the CMAC X associated with 525 BMAC B1 on PE1-rs. Under a failure condition of the link between CE- 526 A and PE1-rs and on activation of the link to PE2-rs, the remote PE- 527 rs devices (for example, PE3-rs) will forward the traffic destined 528 for customer MAC X to BMAC B1 resulting in PE1-rs blackholing that 529 traffic until the aging timer expires or a packet flows from X to Y 530 through the PE2-rs, BMAC B2. This may take a long time (default 531 aging timer is 5 minutes) and may affect a large number of flows 532 across multiple I-components. 534 A possible solution to this issue is to use the existing LDP MAC 535 Flush as specified in [RFC4762] to flush the BMAC associated with the 536 PE-rs in the B-VPLS domain where the failure occurred. This will 537 automatically flush the CMAC to BMAC association in the remote PE-rs 538 devices. This solution has the disadvantage of producing a lot of 539 unnecessary MAC flush in the B-VPLS domain as there was no failure or 540 topology change affecting the Backbone domain. 542 A better solution which propagates the I-component events through the 543 backbone infrastructure (B-VPLS) is required in order to flush only 544 the CMAC to BMAC associations in the remote PBB-VPLS capable PE-rs 545 devices. Since there are no I-component control plane exchanges 546 across the PBB backbone, extensions to B-VPLS control plane are 547 required to propagate the I-component MAC Flush events across the 548 B-VPLS. 550 5. Solution Description 552 This section describes the solution for the problem space described 553 in section 4. 555 5.1. MAC Flush Optimization for VPLS Resiliency 557 The basic principle of the optimized MAC flush mechanism is explained 558 with reference to Figure 2. The optimization is achieved by 559 initiating MAC Flush on failure as described in section 3.2. 561 PE1-rs would initiate MAC Flush towards the core on detection of 562 failure of primary spoke PW between MTU-s and PE1-rs (or status 563 change from active to standby [RFC6718] ). This method is referred 564 to as "MAC Flush on Failure" throughout this document. The MAC Flush 565 message would indicate to receiving PE-rs devices to flush all MACs 566 learned over the PW in the context of the VPLS for which the MAC 567 flush message is received. Each PE-rs device in the full mesh that 568 receives the message identifies the VPLS instance and its respective 569 PW that terminates in PE1-rs from the FEC TLV received in the message 570 and/or LDP session. Thus the PE-rs device flushes only the MAC 571 addresses learned from that PW connected to PE1-rs, minimizing the 572 required relearning and the flooding throughout the VPLS domain. 574 This section defines a generic MAC Flush Parameters TLV for LDP 575 [RFC5036]. Through out this document the MAC Flush Parameters TLV is 576 referred as the MAC Flush TLV. A MAC Flush TLV carries information 577 on the desired action at the PE-rs device receiving the message and 578 is used for optimized MAC flushing in VPLS. The MAC Flush TLV can 579 also be used for [RFC4762] style of MAC Flush as explained in section 580 3. 582 5.1.1. MAC Flush Parameters TLV 584 The MAC Flush Parameters TLV is described as below: 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 |1|1| MAC Flush Params TLV(TBDA)| Length | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Flags | Sub-TLV Type | Sub-TLV Length | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Sub-TLV Variable Length Value | 594 | " | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 The U and F bits are set to forward if unknown so that potential 598 intermediate VPLS PE-rs devices unaware of the new TLV can just 599 propagate it transparently. In the case of an B-VPLS network that 600 has PBB-VPLS in the core with no I-components attached this message 601 can still be useful to edge B-VPLS that do have the I-components with 602 the ISIDs and understand the message. The MAC Flush Parameters TLV 603 type is to be assigned by IANA. The encoding of the TLV follows the 604 standard LDP TLV encoding in [RFC5036] 606 The TLV value field contains a one byte Flag field used as described 607 below. Further the TLV value MAY carry one or more sub-TLVs. Any 608 sub-TLV definition to the above TLV MUST address the actions in 609 combination with other existing sub-TLVs. 611 The detailed format for the Flags bit vector is described below: 613 0 1 2 3 4 5 6 7 614 +-+-+-+-+-+-+-+-+ 615 |C|N| MBZ | (MBZ = MUST Be Zero) 616 +-+-+-+-+-+-+-+-+ 618 1 Byte Flag field is mandatory. The following flags are defined: 620 C flag, used to indicate the context of the PBB-VPLS component in 621 which MAC flush is required. For PBB-VPLS there are two contexts of 622 MAC flushing - The Backbone VPLS (B-component VPLS) and Customer VPLS 623 (I-component VPLS). C flag MUST be ZERO (C=0) when a MAC Flush for 624 the B-VPLS is required. C flag MUST be set (C=1) when the MAC Flush 625 for I-component is required. In the regular H-VPLS case the C flag 626 MUST be ZERO (C=0) to indicate the flush applies to the current VPLS 627 context. 629 N flag, used to indicate whether a positive (N=0, Flush-all-but-mine) 630 or negative (N=1 Flush-all-from-me) MAC Flush is required. The 631 source (mine/me) is defined either as the PW associated with the LDP 632 session on which the LDP MAC Withdraw was received or with the 633 BMAC(s) listed in the BMAC Sub-TLV. For the optimized MAC Flush 634 procedure described in this section the flag MUST be set (N=1). 636 Detailed usage in the context of PBB-VPLS is explained in section 637 5.2. 639 MBZ flags, the rest of the flags SHOULD be set to zero on 640 transmission and ignored on reception. 642 The MAC Flush TLV SHOULD be placed after the existing TLVs in the MAC 643 Flush message in [RFC4762]. 645 5.1.2. Application of the MAC Flush TLV in Optimized MAC Flush 647 When optimized MAC flush is supported, the MAC Flush TLV MUST be sent 648 as in existing LDP Address Withdraw Message with empty MAC List but 649 from the core PE-rs on detection of failure of its local/primary 650 spoke PW. The N bit in TLV MUST be set to 1 to indicate Flush-all- 651 from-me. If the optimized MAC Flush procedure is used in a Backbone 652 VPLS or regular VPLS/H-VPLS context the C bit MUST be ZERO (C=0). If 653 it is used in an I-component context the C bit MUST be set (C= 1). 654 See section 5.2 for details of its usage in PBB-VPLS context. 656 Note that the assumption is the MAC flush TLV is understood by all 657 devices before it is turned on in any network. See Operational 658 Considerations section 6. 660 When optimized MAC flush is not supported, the MAC withdraw 661 procedures defined in [RFC4762], where either the MTU-s or PE2-rs 662 send the MAC Withdraw message, SHOULD be used. This includes the case 663 where the network is being changed to support optimized MAC flush but 664 not all devices are capable of understanding the optimized MAC flush. 666 For the case of B-VPLS devices the optimized MAC flush message SHOULD 667 be supported. 669 5.1.3. MAC Flush TLV Processing Rules for Regular VPLS 671 This section describes the processing rules of the MAC Flush TLV that 672 MUST be followed in the context of optimized MAC flush procedures in 673 VPLS. 675 When optimized MAC flush is supported, a multi-homing PE-rs initiates 676 a MAC flush message towards the other related VPLS PE-rs devices when 677 it detects a transition (failure or to standby) in its active spoke 678 PW. In such case the MAC Flush TLV MUST be sent with N = 1. A PE-rs 679 device receiving the MAC Flush TLV SHOULD follow the same processing 680 rules as described in this section. 682 Note that if a Multi-segment Psuedowire (MS-PW) is used in VPLS, then 683 a MAC flush message is processed only at the PW Terminating Provider 684 Edge (T-PE) nodes since PW Switching Provider Edge S-PE(s) traversed 685 by the MS-PW propagate the MAC flush messages without any action. In 686 this section, a PE-rs device signifies only T-PE in MS-PW case. 688 When a PE-rs device receives a MAC Flush TLV with N = 1, it SHOULD 689 flush all the MAC addresses learned from the PW in the VPLS in the 690 context on which the MAC Flush message is received. It is assumed 691 when these procedures are used all nodes support the MAC Flush 692 Message. See section 6 Operational Considerations for details. 694 When Optimized MAC flush is not supported, a MAC Flush TLV is 695 received with N = 0 in the MAC flush message then the receiving PE-rs 696 SHOULD flush the MAC addresses learned from all PWs in the VPLS 697 instance except the ones learned over the PW on which the message is 698 received. 700 Regardless of whether Optimized MAC flush is supported, if a PE-rs 701 device receives a MAC flush with a MAC Flush TLV option (N = 0 or N= 702 1) and a valid MAC address list, it SHOULD ignore the option and deal 703 with MAC addresses explicitly as per [RFC4762]. 705 5.1.4. Optimized MAC Flush Procedures 707 This section expands on the optimized MAC flush procedure in the 708 scenario in Figure 2. 710 When Optimized MAC flush is being used a PE-rs that is dual homing 711 aware SHOULD send MAC address messages with a MAC Flush TLV and N=1 712 provided the other PEs understand the new messages. Upon receipt of 713 the MAC flush message, PE2-rs identifies the VPLS instance that 714 requires MAC flush from the FEC element in the FEC TLV. On receiving 715 N=1, PE-2 removes all MAC addresses learned from that PW over which 716 the message is received. The same action is followed by PE3-rs and 717 PE4-rs. 719 Figure 4 shows another redundant H-VPLS topology to protect against 720 failure of MTU-s device. In this case, since there is more than a 721 single MTU-S a protocol such as provider RSTP [IEEE.802.1Q-2011] may 722 be used as selection algorithm for active and backup PWs in order to 723 maintain the connectivity between MTU-s devices and PE-rs devices at 724 the edge. It is assumed that PE-rs devices can detect failure on PWs 725 in either direction through OAM mechanisms such as VCCV procedures 726 for instance. 728 MTU-1================PE-1-rs=============PE-3-rs 729 || || \ /|| 730 || Redundancy || \ / || 731 || Provider RSTP || Full-Mesh . || 732 || || / \ || 733 || || / \|| 734 MTU-2----------------PE-2-rs=============PE-4-rs 735 Backup PW 737 Figure 4: Redundancy with Provider RSTP 739 MTU-1, MTU-2, PE1-rs and PE2-rs participate in provider RSTP. By 740 configuration in RSTP it is ensured that the PW between MTU-1 and 741 PE1-rs is active and the PW between MTU-2 and PE2-rs is blocked (made 742 backup) at MTU-2 end. When the active PW failure is detected by 743 RSTP, it activates the PW between MTU-2 and PE2-rs. When PE1-rs 744 detects the failing PW to MTU-1, it MAY trigger MAC flush into the 745 full mesh with a MAC Flush TLV that carries N=1. Other PE-rs devices 746 in the full mesh that receive the MAC flush message identify their 747 respective PWs terminating on PE1-rs and flush all the MAC addresses 748 learned from it. 750 [RFC4762] describes multi-domain VPLS service where fully meshed VPLS 751 networks (domains) are connected together by a single spoke PW per 752 VPLS service between the VPLS "border" PE-rs devices. To provide 753 redundancy against failure of the inter-domain spoke, full mesh of 754 inter-domain spokes can be setup between border PE-rs devices and 755 provider RSTP may be used for selection of the active inter-domain 756 spoke. In case of inter-domain spoke PW failure, PE-rs initiated MAC 757 withdrawal MAY be used for optimized MAC flushing within individual 758 domains. 760 Further, the procedures are applicable with any native Ethernet 761 access topologies multi-homed to two or more VPLS PE-rs devices. The 762 text in this section applies for the native Ethernet case where 763 active/standby PWs are replaced with the active/standby Ethernet 764 endpoints. An optimized MAC Flush message can be generated by the 765 VPLS PE-rs that detects the failure in the primary Ethernet access. 767 5.2. LDP MAC Flush Extensions for PBB-VPLS 769 The use of Address Withdraw message with MAC List TLV is proposed in 770 [RFC4762] as a way to expedite removal of MAC addresses as the result 771 of a topology change (e.g. failure of a primary link of a VPLS PE-rs 772 device and implicitly the activation of an alternate link in a dual- 773 homing use case). These existing procedures apply individually to 774 B-VPLS and I-component domains. 776 When it comes to reflecting topology changes in access networks 777 connected to I-component across the B-VPLS domain certain additions 778 should be considered as described below. 780 MAC Switching in PBB is based on the mapping of Customer MACs (CMACs) 781 to Backbone MAC(s) (BMACs). A topology change in the access 782 (I-domain) should just invoke the flushing of CMAC entries in PBB 783 PEs' FIB(s) associated with the I-component(s) impacted by the 784 failure. There is a need to indicate the PBB PE (BMAC source) that 785 originated the MAC Flush message to selectively flush only the MACs 786 that are affected. 788 These goals can be achieved by including the MAC Flush Parameters TLV 789 in the LDP Address Withdraw message to indicate the particular 790 domain(s) requiring MAC flush. On the other end, the receiving PEs 791 SHOULD use the information from the new TLV to flush only the related 792 FIB entry/entries in the I-component instance(s). 794 At least one of the following sub-TLVs MUST be included in the MAC 795 Flush Parameters TLV if the C-flag is set to 1: 797 o PBB BMAC List Sub-TLV: 799 Type: IANA TBDB 801 Length: value length in octets. At least one BMAC address MUST be 802 present in the list. 804 Value: one or a list of 48 bits BMAC addresses. These are the source 805 BMAC addresses associated with the B-VPLS instance that originated 806 the MAC Withdraw message. It will be used to identify the CMAC(s) 807 mapped to the BMAC(s) listed in the sub-TLV. 809 o PBB ISID List Sub-TLV: 811 Type: IANA TBDC 813 Length: value length in octets. Zero indicates an empty ISID list. 814 An empty ISID list means that the flush applies to all the ISIDs 815 mapped to the B-VPLS indicated by the FEC TLV. 817 Value: one or a list of 24 bits ISIDs that represent the I-component 818 FIB(s) where the MAC Flush needs to take place. 820 5.2.1. MAC Flush TLV Processing Rules for PBB-VPLS 822 The following steps describe the details of the processing rules for 823 the MAC Flush TLV in the context of PBB-VPLS. In general these 824 procedures are similar to the VPLS case but are tailored to PBB which 825 may have a large number of MAC addresses. In PBB there are two sets 826 of MAC addresses Backbone (outer) MACs (BMACs) and Customer (inner) 827 MACs (CMACs). C-MACs are associated to remote B-MACs by learning. 828 There are also ISIDs which are similar to VLANs for this description. 829 In order to get the behavior similar to the Regular VPLS case there 830 are some differences in the interpretation of the Optimized MAC flush 831 message. 833 1. Positive Flush of CMACs. This is equivalent to the [RFC4762] MAC 834 flush in a PBB context. In this case the N bit is set to 0; the C bit 835 is Set to 1 and CMACs are to be flushed. However since CMACs are 836 related to BMACs in an ISID context there is further refinement of 837 flushing scope possible. 839 - If an ISID needs to be flushed (All CMACs within that ISID) then 840 ISIDs are listed in the appropriate TLV. If all ISIDs are to have 841 the CMACs flushed then the ISID TLV can be empty. It is typical 842 to flush a single ISID only since each ISID is associated with one 843 or more interfaces (typically one in the case of dual homing). In 844 the PBB case flushing the ISID is equivalent to the empty MAC list 845 in [RFC4762]. 847 - If only a set of BMAC to CMAC associations need to be flushed, 848 then a BMAC list can be included to further refine the list. This 849 can be the case if an ISID component has more than one interface 850 and a BMAC is used to refine the granularity. Since this is a 851 positive MAC flush the intended behavior is flush all CMACs but 852 those that are associated with a BMACs in the list. 854 Positive Flush of BMACs is also useful for propagating Flush from 855 other protocols such as RSTP. 857 2. Negative Flush of CMACs. This is the equivalent to the optimized 858 MAC flush. In this case the N bit is set to 1; the C bit is Set to 1 859 and a list of BMACs is provided so that the respective CMACs can be 860 flushed. 862 - The ISID list SHOULD be specified. If it is absent then all 863 ISIDs require the CMACs to be flushed. 865 - A set of BMACs SHOULD be listed since BMAC to CMAC associations 866 need to be flushed and listing BMACs scopes the flush to just 867 those BMACs. Again this is typical usage because a PBB VPLS I- 868 component interface will have one associated ISID and typically 869 one but possibly more than one BMAC each with multiple remotely 870 learned CMACs. The BMAC list is included to further refine the 871 list for the remote receiver. Since this is a negative MAC flush 872 the intended behavior is flush all remote CMACs that are 873 associated with any BMACs in the list (in other words from the 874 affected interface.) 876 The Processing rules on reception of the MAC flush Message are: 878 - On a Backbone Core Bridges (BCB) in if the C-bit is set to 1 then 879 the PBB-VPLS SHOULD NOT flush their BMAC FIBs. The B-VPLS control 880 plane SHOULD propagate the MAC Flush following the data-plane split- 881 horizon rules to the established B-VPLS topology. 883 - On Backbone Edge Bridges (BEB) is as follows: 885 - The PBB ISID List is used to determine the particular ISID FIBs 886 (I-component) that need to be considered for flushing action. If 887 the PBB ISID List sub-tlv is not included in a received message 888 then all the ISID FIBs associated with the receiving B-VPLS SHOULD 889 be considered for flushing action. 891 - The PBB BMAC List is used to identify from the ISID FIBs in the 892 previous step to selectively flush BMAC to CMAC associations 893 depending on the N flag specified below. If PBB BMAC List Sub-TLV 894 is not included in a received message then all BMAC to CMAC 895 association in all ISID FIBs (I-component) as specified by the 896 ISID List are considered for required flushing action, again 897 depending on the N flag specified below. 899 - Next, depending on the N flag value the following actions apply: 901 - N=0, all the CMACs in the selected ISID FIBs SHOULD be flushed 902 with the exception of the resulted CMAC list from the BMAC List 903 mentioned in the message. ("Flush all but the CMACs associated 904 with the BMAC(s) in the BMAC List Sub-TLV from the FIBs associated 905 with the ISID list"). 907 - N=1, all the resulted CMACs SHOULD be flushed ("Flush all the 908 CMACs associated with the BMAC(s) in the BMAC List Sub-TLV from 909 the FIBs associated with the ISID list"). 911 5.2.2. Applicability of the MAC Flush Parameters TLV 913 If MAC Flush Parameters TLV is received by a Backbone Edge Bridges 914 (BEB) in a PBB-VPLS that does not understand the TLV then it may 915 result in undesirable MAC flushing action. It is RECOMMENDED that 916 all PE-rs devices participating in PBB-VPLS support the MAC Flush 917 Parameters TLV. If this is not possible the MAC Flush Parameters TLV 918 SHOULD be disabled as mentioned in section 6 Operational 919 Considerations. 921 The MAC Flush Parameters TLV is also applicable to regular VPLS 922 context as well as explained in section 3.1.1. To achieve negative 923 MAC Flush (flush-all-from-me) in regular VPLS context, the MAC Flush 924 Parameters TLV SHOULD be encoded with C=0 and N = 1 without inclusion 925 of any Sub-TLVs. Negative MAC flush is highly desirable in scenarios 926 when VPLS access redundancy is provided by Ethernet Ring Protection 927 as specified in ITU-T [ITU.G8032]specification. 929 6. Operational Considerations 931 As mentioned earlier, if the MAC Flush Parameters TLV is not 932 understood by a receiver then it would result in undesired flushing 933 action. To avoid this, one possible solution is to develop an LDP 934 based capability negotiation mechanism to negotiate support of 935 various MAC Flushing capability between PE-rs devices in a VPLS 936 instance. A negotiation mechanism was discussed and was considered 937 outside the scope of this document. Negotiation is not required to 938 deploy this optimized MAC flush as described in this document. 940 VPLS may be used with or without the optimization. If an operator 941 wants the optimizations for VPLS it is the operator's responsibility 942 to make sure the VPLS that are capable of supporting the optimization 943 are properly configured. From operational standpoint, it is 944 RECOMMENDED that implementations of the solution provide 945 administrative control to select the desired MAC Flushing action 946 towards a PE-rs device in the VPLS. Thus in the topology described 947 in figure 2, an implementation could support PE1-rs sending optimized 948 MAC Flush towards the PE-rs devices that support the solution and 949 PE2-rs device initiating [RFC4762] style of MAC Flush towards the PE- 950 rs devices that do not support the optimized solution during 951 upgrades. The PE-rs that supports the MAC Flush Parameters TLV MUST 952 support the RFC4762 MAC flush procedures since this document only 953 augments them. 955 For the case of PBB-VPLS this operation is the only method supported 956 for specifying ISIDs and the optimization is assumed to be supported 957 or should be turned off reverting to flushing using [RFC4762] at the 958 Backbone MAC level. 960 7. IANA Considerations 962 7.1 New LDP TLV 964 IANA maintains a registry called "Label Distribution Protocol (LDP) 965 Parameters" with a sub-registry called "TLV Type Name Space". 967 IANA is requested to allocate three new code points from the 968 unassigned range 0x0405-0x04FF as follows. IANA is requested to 969 allocate consecutive numbers. 971 Value | Description | Reference | Notes 972 ------+--------------------------+------------+----------- 973 TBDA | MAC Flush Parameters TLV | [This.I-D] | 974 TBDB | PBB BMAC List Sub-TLV | [This.I-D] | 975 TBDC | PBB ISID List Sub-TLV | [This.I-D] | 977 7.2 New Registry for MAC Flush Flags 979 IANA is requested to create a new sub-registry under "Label 980 Distribution Protocol (LDP) Parameters" called "MAC Flush Flags". 982 IANA is requested to populate the registry as follows: 984 Bit number | Hex | Abbreviation | Description | Reference 985 -----------+------+--------------+------------------+----------- 986 0 | 0x80 | C | Context | [This.I-D] 987 1 | 0x40 | N | Negative flush | [This.I-D] 988 2-7 | | | Unassigned | 990 Other new bits are to be assigned by Standards Action. 992 8. Security Considerations 994 Control plane aspects: 996 LDP security (authentication) methods as described in [RFC5036] is 997 applicable here. Further this document implements security 998 considerations as in [RFC4447] and [RFC4762]. The extensions defined 999 here optimize the flushing and so the risk of security attacks is 1000 reduced. However, in the event that the configuration of support for 1001 the new TLV can be spoofed, sub-optimal behavior will be seen. 1003 Data plane aspects: 1005 This specification does not have any impact on the VPLS forwarding 1006 plane but can improve MAC flushing behavior. 1008 9. Contributing Author 1010 The authors would like to thank Marc Lasserre who made a major 1011 contribution to the development of this document. 1013 Marc Lasserre 1015 Alcatel-Lucent 1017 Email: marc.lasserre@alcatel-lucent.com 1019 10. Acknowledgements 1021 The authors would like to thank the following people who have 1022 provided valuable comments, feedback and review on the topics 1023 discussed in this document: Dimitri Papadimitriou, Jorge Rabadan, 1024 Prashanth Ishwar, Vipin Jain, John Rigby, Ali Sajassi, Wim 1025 Henderickx, Paul Kwok, Maarten Vissers, Daniel Cohn, Nabil Bitar, 1026 Giles Heron, Adrian Farrel, Ben Niven-Jenkins, Robert Sparks, Susan 1027 Hares and Stephen Farrell. 1029 11. References 1031 11.1. Normative References 1033 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1034 Requirement Levels", BCP 14, RFC 2119, March 1997. 1036 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1037 Heron, "Pseudowire Setup and Maintenance Using the Label 1038 Distribution Protocol (LDP)", RFC 4447, April 2006. 1040 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 1041 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 1042 RFC 4762, January 2007. 1044 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1045 Specification", RFC 5036, October 2007. 1047 11.2. Informative References 1049 [RFC7041] Balus, F., Sajassi, A., and N. Bitar, "Extensions to the 1050 Virtual Private LAN Service (VPLS) Provider Edge (PE) 1051 Model for Provider Backbone Bridging",RFC 7041, 1052 November 2013. 1054 [I-D.ietf-l2vpn-vpls-multihoming] 1055 Kothari, B., Kompella, K., Henderickx, W., Balus, F., 1056 Palislamovic, S., Uttaro, J., and W. Lin, "BGP based 1057 Multi-homing in Virtual Private LAN Service", 1058 draft-ietf-l2vpn-vpls-multihoming-06 (work in progress), 1059 October 2012. 1061 [IEEE.802.1Q-2011] 1062 IEEE, "IEEE Standard for Local and metropolitan area 1063 networks -- Media Access Control (MAC) Bridges and Virtual 1064 Bridged Local Area Networks", IEEE Std 802.1Q, 2011. 1066 [ITU.G8032] 1067 International Telecommunications Union, "Ethernet ring 1068 protection switching", ITU-T Recommendation G.8032, 1069 March 2010. 1071 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1072 Private Networks (L2VPNs)", RFC 4664, September 2006. 1074 [RFC6718] Muley, P., Aissaoui, M., and Bocci, M., "Pseudowire 1075 Redundancy", RFC 6718, August 2012. 1077 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and 1078 Aissaoui, M., "Segmented Pseudowire", RFC 6073, January 1079 2011. 1081 Authors' Addresses 1083 Pranjal Kumar Dutta 1084 Alcatel-Lucent 1085 701 E Middlefield Road 1086 Mountain View, California 94043 1087 USA 1089 Email: pranjal.dutta@alcatel-lucent.com 1091 Florin Balus 1092 Alcatel-Lucent 1093 701 E Middlefield Road 1094 Mountain View, California 94043 1095 USA 1097 Email: florin.balus@alcatel-lucent.com 1099 Olen Stokes 1100 Extreme Networks 1101 PO Box 14129, RTP 1102 Raleigh, North Carolina 27709 1103 USA 1105 Email: ostokes@extremenetworks.com 1107 Geraldine Calvginac 1108 Orange 1109 2, avenue Pierre-Marzin 1110 Lannion Cedex, 22307 1111 France 1113 Email: geraldine.calvignac@orange.com 1115 Don Fedyk 1117 Hewlett-Packard Company 1118 USA 1119 Email: don.fedyk@hp.com