idnits 2.17.1 draft-ietf-l2vpn-vpls-macflush-ld-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4762]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 31, 2013) is 4043 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) == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-vpls-multihoming-05 -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Kwok 3 Internet-Draft P. Dutta 4 Intended status: Standards Track Alcatel-Lucent 5 Expires: October 2, 2013 March 31, 2013 7 MAC Flush Loop Detection in VPLS 8 draft-ietf-l2vpn-vpls-macflush-ld-03 10 Abstract 12 MAC Address Withdrawal is a mechanism described in [RFC4762] to 13 remove or unlearn MAC addresses that have been dynamically learned in 14 a VPLS instance, for faster convergence on topology change. Failure 15 of mechanisms that control loop free connectivity among VPLS PE-rs 16 nodes may cause MAC Address Withdrawal messages looping among those 17 nodes, leading to Denial of Service (DoS) or complete failure of 18 control plane in the PE-rs nodes. This document describes a 19 mechanism to detect and prevent loops of MAC Address Withdrawal 20 messages in a VPLS PE-rs node on such failures. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 7, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. MTU-s Initiated MAC Flush . . . . . . . . . . . . . . . . 6 66 3.1.1. MAC Flush Loop Due to Misconfiguration . . . . . . . . 7 67 3.2. PE-rs Initiated MAC Flush . . . . . . . . . . . . . . . . 10 68 4. Loop Detection in MAC Flush . . . . . . . . . . . . . . . . . 10 69 4.1. Loop Detection Procedure in MAC Flush Message . . . . . . 11 70 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 12 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 8. Major Contributing Authors . . . . . . . . . . . . . . . . . . 13 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 10.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 A method of Virtual Private LAN Service (VPLS) is described in 83 [RFC4762]. A full mesh of Pseudowire (PW)s is established between 84 PE-rs (Provider Edge - Routing and Switching Capable) nodes to 85 construct the VPLS core. The mesh topology provides a LAN segment or 86 broadcast domain that is fully capable of learning and forwarding 87 based on Ethernet MAC addresses at the PE-rs nodes. Since every 88 PE-rs node is now directly connected to every other PE-rs nodes in 89 the core via a PW, the topology forms a loop in data plane. A simple 90 loop breaking rule is used - the "spilt horizon" rule described in 91 section 4.4 in [RFC4762], whereby a PE-rs node does not forward 92 traffic from one PW to another in the same VPLS mesh. Various 93 mechanisms used to enforce split-horizon rule in the VPLS full mesh 94 are out of scope of this document. 96 For scalability, this VPLS full mesh core configuration can be 97 augmented with additional non-meshed spoke or MTU-s (Multi-Tenant 98 Unit - Switching Capable) [RFC4762] nodes to provide a Hierarchical 99 VPLS (H-VPLS) service [RFC4762]. "Spoke" PW connecting the MTU-s 100 node and "hosting" PE-rs node can forward traffic to and receive 101 traffic from a "Mesh" PW in the VPLS core. To protect from 102 connection failure of the spoke PW or the hosting PE-rs node, the 103 MTU-s node may be dual-homed into two PE-rs nodes in the same VPLS 104 instance (see Figure 1). The dual homed connectivity also forms a 105 loop that requires a loop breaking mechanism. The various loop 106 breaking mechanisms used in H-VPLS dual homing are out of scope of 107 this document. 109 MAC Address Withdrawal [RFC4762] is required to remove or unlearn MAC 110 addresses for faster convergence on topology change in H-VPLS (e.g., 111 failure of the primary spoke PW for a dual-homed MTU-s). In this 112 document the term "MAC Flush Message" means the LDP Address Withdraw 113 Message MAC List TLV used for MAC Address Withdrawal in VPLS. 115 Lack of of mechanisms or failure of mechanisms that control data 116 plane loop free connectivity among VPLS PE-rs nodes may also cause 117 loops of MAC Flush Messages in the LDP control plane among the 118 participating PE-rs nodes. Such looping of MAC Flush Messages may is 119 similar to denial of service (DoS) attacks which may lead to complete 120 failure of the control plane in the node(s). This document describes 121 the looping problem with MAC Flush Messages and defines a mechanism 122 to detect and prevent such loops in the LDP control plane. 124 Note misconfiguration in VPLS networks may cause loops and broadcast 125 storms in traffic forwarding as well. Data path loop detection and 126 prevention is outside the scope of this document. Implementations 127 may deploy methodologies available in native service forwarding to 128 detect and prevent such loops in data path. The control plane may 129 not necessarily benefit from these capabilities since the control 130 messages are handled differently at each hop. 132 2. Terminology 134 This document uses the terminology defined in [RFC5036] and 135 [RFC4762]. 137 Throughout this document VPLS means the emulated bridged LAN service 138 offered to a customer. H-VPLS means the hierarchical Connectivity or 139 layout of MTU-s and PE devices offering the VPLS [RFC4762]. 141 The terms spoke node and MTU-s in H-VPLS are used interchangeably. 143 "Spoke PW" means the PW that provides connectivity between MTU-s and 144 PE-rs nodes. 146 "Mesh PW" means the PW that provides connectivity between PE-rs nodes 147 in a VPLS full mesh core. 149 "MAC Flush Message" means LDP Address Withdraw Message with MAC List 150 TLV with MAC List TLV. 152 MAC Flush Message in the "context of a PW" means the Message that has 153 been received over the LDP session that is used to set up the PW used 154 to provide connectivity in VPLS. The MAC Flush Message carries the 155 context of the PW in terms on FEC TLV associated with the PW 156 [RFC4762][RFC4447]. 158 In general, "MAC Flush" means the method of initiating and processing 159 of MAC Flush Messages across a VPLS instance. 161 3. Problem Statement 163 This section describes MAC Flush Loop in the LDP control plane. 165 PE1-rs PE3-rs 166 +--------+ +--------+ 167 | | | | 168 | -- | | -- | 169 Customer Site 1 | / \ |---------------| / \ |..-> Z 170 X->CE-1 /-----| \ s/ | | \S / | 171 \ primary spoke PW | -- | /---| -- | 172 \ / +--------+ / +--------+ 173 \ (MTU-s) / | \ / | 174 +--------+/ | \ / | 175 | | | \ / | 176 | -- | | \ / | 177 | / \ | | H-VPLS Full Mesh Core| 178 | \S / | | / \ | 179 | -- | | / \ | 180 /+--------+\ | / \ | 181 / backup spoke PW | / \ | 182 / \ +--------+ \-----+--------+ 183 Y->CE-2 \ | | | | 184 Customer Site 2 \------| -- | | -- | 185 | / \ |---------------| / \ |..-> 186 | \s / | | \S / | 187 | -- | | -- | 188 +--------+ +--------+ 189 PE2-rs PE4-rs 191 Figure 1: Dual homed MTU-s in two tier hierarchy H-VPLS 193 An example of usage of the MAC Flush mechanism is the dual-homed 194 H-VPLS where an edge node termed as MTU-s is connected to two hosting 195 PE-rs nodes via primary spoke PW and backup spoke PW respectively 196 (see Figure 1). This model is described in [RFC4762]. 198 Such redundancy is designed to protect against the failure of primary 199 spoke PW or hosting primary PE-rs node. There could be multiple 200 methods of dual homing in H-VPLS that are not described in [RFC4762]. 201 For example, note the following statement from section 10.2.1 in 202 [RFC4762]: 204 "How a spoke is designated primary or secondary is outside the scope 205 of this document. For example, a spanning tree instance running 206 between only the MTU-s and the two PE-rs nodes is one possible 207 method. Another method could be configuration". 209 When the MTU-s switches over to the backup PW (activates the backup 210 PW), it is required to flush the MAC addresses learned in the 211 corresponding VSI (Virtual Switch Instance) in all PE-rs devices 212 participating in full mesh, to avoid black holing of frames to those 213 addresses. 215 In Figure 1, the MTU-s is dual-homed to PE1-rs and PE2-rs. Only the 216 primary spoke PW is active at MTU-s, thus PE1-rs is acting as the 217 active device (designated forwarder) to reach the full mesh in the 218 VPLS instance. The MAC addresses of nodes located at access sites 219 (behind CE1 and CE2) are learned at PE1-rs over the primary spoke PW. 220 Let's say X represents a set of such MAC addresses located behind 221 CE-1. As packets flow from X to Z, PE2-rs, PE3-rs and PE4-rs learn 222 about X on their respective mesh PWs terminating at PE1-rs. When 223 MTU-s switches to the backup spoke PW and activates it, PE2-rs 224 becomes the active device (designated forwarder) to reach the full 225 mesh core. Traffic entering the H-VPLS from CE-1 and CE-2 is 226 diverted by the MTU-s to the spoke PW to PE2-rs. Traffic destined 227 from PE2-rs, PE3-rs and PE4-rs to X will be blackholed till MAC 228 address ageing timer expires (default is 5 minutes) or a packet flows 229 from X to Z through PE2-rs. 231 To avoid traffic blackholing the MAC addresses that have been learned 232 in the upstream VPLS full-mesh through PE1-rs, those addresses must 233 be relearned or removed from the MAC FIBs in the VSIs at PE2-rs, 234 PE3-rs and PE4-rs. This is accomplished by sending a MAC Flush 235 Message with the list of MAC addresses to be removed to all PE-rs 236 devices in the VPLS. In order to minimize the impact on LDP 237 convergence time and scalability when a MAC List TLV contains a large 238 number of MAC addresses, many implementations use a MAC Flush Message 239 with an empty MAC List. 241 3.1. MTU-s Initiated MAC Flush 243 When dual homing in H-VPLS is achieved by manual configuration in 244 MTU-S node, the hosting PE-rs nodes are dual homing "agnostic". It 245 is the MTU-s node that controls the primary and backup status of 246 spoke PWs connected to PE1-rs and PE2-rs respectively. In figure 1, 247 PE2-rs can send and receive traffic over the backup spoke PW any time 248 and only MTU-s blocks the traffic on the spoke PW at its end. For 249 example Broadcast, Unicast Unlearned and Multicast (BUM) traffic 250 received from the VPLS core is continually forwarded by PE3-rs node 251 over the backup spoke PW to get it dropped by MTU-s node. 253 Therefore PE2-rs node (PE-rs node with now-active PW) cannot initiate 254 MAC Flush message on activation of backup PW by MTU-s. When the 255 backup PW is made active by the MTU-s node, it initiates a MAC Flush 256 Message to PE2-rs node. The Message is sent over in the context of 257 the newly activated spoke PW. On receiving the MAC Flush Message 258 from MTU-s node, PE2-rs node would flush all the MAC addresses it has 259 learned except the ones learned over the newly activated spoke PW 260 (Here it is assumed that MTU-s initiated a MAC Flush Message with 261 empty MAC List). PE2-rs node further "propagates" the MAC Flush 262 Message to all other PE-rs nodes in the VPLS core to incur the same 263 MAC flushing action in peer PE-rs nodes. 265 The MAC Flush forwarding rules in LDP control plane strictly follow 266 the "split-horizon" forwarding rules in H-VPLS data plane (Refer to 267 section 4.4 in [RFC4762]). So a MAC Flush is forwarded in the 268 context of mesh PW(s) only when it is received in the context of a 269 spoke PW. When a PE-rs node receives a MAC Flush in the context of a 270 mesh PW then it is not forwarded in the control plane further - means 271 not forwarded to any mesh or spoke PWs. 273 MTU-s initiated method of MAC Flushing is modeled after Topology 274 Change Notification (TCN) in Rapid Spanning Tree Protocol 275 (RSTP)[IEEE.802.1Q-2011]. When a bridge switches from a failed link 276 to the backup link, the bridge sends out a TCN message over the newly 277 activated link. The upstream bridge upon receiving this message 278 flushes its entire MAC addresses except the ones received over this 279 link and sends the TCN message out of its other ports in that 280 spanning tree instance. The message is further relayed along the 281 spanning tree by the other bridges. MTU-s initiated MAC Flushing may 282 be also applicable when RSTP may be used to ensure loop free 283 connectivity and failure protection between MTU-s node and host PE-rs 284 node (Refer to section 11.2 in [RFC4762]). 286 This method of MTU-s initiated MAC Flush is not explicitly described 287 in [RFC4762], although it mentions about dual-homing with manual 288 configuration or with xSTP (Any of the Spanning Tree Protocol Family) 289 . Note that forced switchover to backup spoke PW can be also 290 performed at MTU-s node administratively due to maintenance 291 activities on the formerly primary spoke PW. 293 3.1.1. MAC Flush Loop Due to Misconfiguration 295 In the figure below, PE1-rs, PE2-rs, PE3-rs and PE4-rs comprises of 296 the VPLS full mesh core. The loop free connectivity between the 297 PE-rs devices is supposed to be ensured by split-horizon forwarding 298 rules between mesh PWs that connects the VPLS core[RFC4762]. 300 PE1-rs PE3-rs 301 +--------+ +--------+ 302 | | | | 303 | -- | | -- | 304 | / \ |-----| / \ |-> 305 /------| \ s/ | | \S / | 306 primary spoke PW | -- | -| -- | 307 / +--------+ / +--------+ 308 (MTU-s) / \ / 309 +--------+/ | \ / | 310 | | | \ / | 311 | -- | | \ / | 312 | / \ | | H-VPLS Full Mesh Core| 313 | \S / | | / \ | 314 | -- | | / \ | 315 +--------+\ / \ | 316 backup spoke PW | \ 317 \ +--------+ \--------+--------+ 318 \ | | | | 319 \------| -- | | -- | 320 | / \ |------| / \ |-> 321 | \s / | | \S / | 322 | -- | | -- | 323 +--------+ +--------+ 324 PE2-rs PE4-rs 326 Figure 2: Dual homed MTU-s in two tier hierarchy H-VPLS with 327 misconfiguration in core 329 Figure 2. above describes a set of misconfigurations in the H-VPLS 330 topology, which are as follows: 332 1. The PW that connects between PE2-rs and PE3-rs has been 333 misconfigured at PE3-rs as spoke PW instead of mesh PW. 335 2. The PW that connects between PE3-rs and PE1-rs has been 336 misconfigured at PE1-rs as spoke PW instead of mesh PW. 338 3. The PW that connects between PE1-rs and PE2-rs has been 339 misconfigured at PE2-rs as spoke PW instead of mesh PW. 341 Such misconfiguration can occur due to configuration error in manual 342 provisioning of a VPLS instance. Further such misconfiguration may 343 also happen due to misconfiguration of the protocol(s) used to 344 automate provisioning of VPLS instances. 346 Note the misconfiguration now has created a loop in data plane along 347 the path PE1-rs->PE2-rs->PE3-rs->PE1-rs. An example is as follows: 349 1. BUM traffic received by PE1-rs from MTU-s over the primary spoke 350 PW would be flooded to PE2-rs and PE3-rs (would be also forwarded to 351 MTU-s over the backup spoke PW if PE2-rs is dual-homing agnostic). 353 2. PE2-rs on receiving the packets from PE1-rs on a spoke PW, PE2-rs 354 would forward to PE3-rs over the mesh PW. 356 3. PE3-rs on receiving the packets from PE2-rs on a spoke PW, PE3-rs 357 would forward to PE1-rs and PE4-rs over the respective mesh PWs. 359 4. PE1-rs on receiving the packets from PE3-rs on a spoke PW, PE1-rs 360 would forward to PE2-rs and PE4-rs over the respective mesh PWs. 362 Implementations may deploy several data plane loop breaking methods 363 that are available in native service forwarding to break such loops 364 in data path. Data plane loop breaking methods are outside the scope 365 of this document. 367 In this misconfigured topology, MTU-s activates the backup spoke PW 368 to PE2-rs and initiates a MAC Flush Message towards PE2-rs. Since 369 MAC flush forwarding rules are derived from the VPLS split-horizon 370 rules data plane, a MAC flush loop would occur in the LDP control 371 plane along PE2-rs->PE3-rs->PE1-rs->PE2-rs as follows: 373 1. PE2-rs on receiving the MAC Flush Message from MTU-s in the 374 context of a spoke PW, PE2-rs would perform required flushing action 375 and would forward the MAC Flush Message towards PE3-rs and PE4-rs in 376 the context of respective mesh PWs. Note that PE2-rs would also 377 forward the message to PE1-rs as well since the PW connecting to 378 PE1-rs has been misconfigured as spoke. 380 2. PE3-rs on receiving the MAC Flush Message from PE2-rs in the 381 context of a spoke PW, PE3-rs would perform required flushing action 382 and would forward the MAC Flush Message to PE1-rs and PE4-rs in the 383 context of respective mesh PWs. 385 3. PE1-rs on receiving the MAC Flush Message from PE3-rs in the 386 context of a spoke PW, PE1-rs would perform required flushing action 387 and would forward the MAC Flush Message to PE2-rs and PE4-rs in the 388 context of respective mesh PWs. 390 Each such loop of a MAC Flush Message causes replication to (N-1) 391 messages, where N is number of PE-rs devices a replicating PE-rs is 392 connected to. Such looping of MAC Flush Messages may lead to a 393 denial of service (DoS) attacks or complete failure of the control 394 plane in the node(s) and bring down services in the entire network. 395 The LDP control plane in PE-rs or MTU-s nodes requires a fault 396 tolerant mechanism to detect such loops and to protect against such 397 failures. 399 3.2. PE-rs Initiated MAC Flush 401 PE-rs initiated MAC Flush [RFC4762] specifies that on failure of the 402 primary PW, it is the PE2-rs node (Figure 2) that initiates MAC flush 403 towards the core. This is specified in section 10.2.2 in [RFC4762]. 404 However note that PE2-rs node can initiate MAC Flush only when PE2-rs 405 is dual homing "aware" - that is, there is some redundancy management 406 protocol running between MTU-s and its host PE-rs devices. 408 The scope of this document is not specific to any dual homing 409 protocols. One example could be BGP based multi-homing in LDP based 410 VPLS that uses the procedures defined in 411 [I-D.ietf-l2vpn-vpls-multihoming]. In this method of dual-homing, 412 PE3-rs would neither forward any traffic to MTU-s neither would 413 receive any traffic from MTU-s while PE1-rs is acting a primary (or 414 designated forwarder). 416 When PE2-rs detects that the backup spoke PW is now active then 417 PE2-rs initiates a MAC Flush Message towards all peer PE-rs nodes in 418 the VPLS full-mesh core. The MAC Flush Processing and Forwarding 419 Rules are same as explained in section 3.1. When a VPLS topology is 420 misconfigured as described in Figure 2, a MAC Flush loop would occur 421 in the same way as explained in section 3.1.1. 423 4. Loop Detection in MAC Flush 425 This section describes the method for Detection and Protection 426 against MAC Flush loops in the control plane. 428 MAC Flush Loop Detection is a configurable option in a VPLS capable 429 PE-rs or MTU-s node that provides a mechanism for finding and 430 preventing MAC Flush messages from looping across the VPLS network. 431 The mechanism makes use of LDP Path Vector TLVs defined in [RFC5036]. 432 For loop detection in MAC Flush, Path Vector TLVs are carried in the 433 MAC Flush Messages. 435 The following shows the encoding of Path Vector TLV when used for MAC 436 Flush Loop Detection. For backward compatibility with [RFC4762] the 437 U bit and F bit MUST be set as 1. 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 |1|1| Path Vector (0x0104) | Length | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | LSR Id 1 | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | | 447 ~ ~ 448 | | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | LSR Id n | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Figure 2. Path Vector TLV in MAC Flush. 455 The method builds on the following basic property of the TLV: 457 - A Path Vector TLV contains a list of the PE-rs devices that the 458 containing MAC Flush Message has traversed. A PE-rs is identified in 459 a Path Vector list by its unique LDP LSR Identifier (LSR-ID), which 460 is the first four octets of its LDP Identifier([RFC5036]). When a 461 PE-rs propagates a MAC flush message containing a Path Vector, it 462 appends its LSR-ID to the Path Vector list. An LSR that receives a 463 message with a Path Vector that contains its LSR-ID, detects that the 464 message has traversed a loop. 466 The following paragraphs describe the MAC Flush Loop Detection 467 Procedures. For these paragraphs, and only these paragraphs, "MUST" 468 is redefined to mean "MUST if configured for Loop Detection". Further 469 the term "PE-rs device" is used specify a VPLS capable PE-rs or a 470 MTU-s device. 472 4.1. Loop Detection Procedure in MAC Flush Message 474 The rules that govern use of the Path Vector TLV are LDP MAC Flush 475 messages by a PE-rs when MAC Flush Loop Detection is enabled are the 476 following: 478 o If PE-rs device is originating the MAC Flush Message, it MUST 479 include a Path Vector TLV of length 1 containing its own LSR-ID 480 along with the MAC Flush Message originated to downstream PE-rs. 482 o If PE-rs device is propagating the MAC flush as a result of having 483 received a MAC Flush from an upstream PE-rs, then: 485 * If the MAC Flush message contains no Path Vector TLV, then 486 PE-rs MUST include a Path Vector TLV of length 1 containing its 487 own LSR-ID along with the MAC Flush Message propagated to 488 downstream PE-rs. 490 * If the MAC Flush contains a Path Vector TLV then: 492 + If the Path Vector TLV contains its LSR-ID then the PE-rs 493 device detects the MAC flush message has traveled in a loop 494 and it MUST drop the MAC Flush Message without processing, 495 else 497 + If the Path Vector TLV exceeds the maximum allowable length, 498 then the PE-rs device detects that the MAC flush message has 499 traveled in a loop and it MUST drop the MAC Flush Message 500 without processing, else, 502 + the TLV PE-rs device MUST add its own LSR ID to the Path 503 Vector, and MUST pass the resulting Path Vector to its 504 downstream PE-rs along with the propagated MAC flush 505 message. 507 By the definition of Path Vector TLV in [RFC5036], it supports the 508 notion of a maximum allowable Path Vector Length; a PE-rs node that 509 detects a Path Vector has reached the maximum length behaves as if 510 containing message has traversed a loop. Such limit MAY be a locally 511 configurable option in an implementation based on the scope of H-VPLS 512 topology. The limit MAY also be driven by payload size limitations 513 of MAC flush messages. 515 5. Applicability 517 If MAC Flush Loop Detection is desired in VPLS Network, then it 518 should be enabled on all PE-rs nodes within that VPLS Network, 519 otherwise Loop Detection will not operate properly and may result in 520 undetected loops or in falsely detected loops. 522 PE-rs nodes that are configured for MAC Flush Loop Detection are not 523 expected to store the Path Vectors as part of the VPLS service. 525 There could be other H-VPLS topologies where the problem and the 526 solution described in this document may be applicable. 528 6. IANA Considerations 530 This document makes no request of IANA. 532 Note to RFC Editor: this section may be removed on publication as an 533 RFC. 535 7. Security Considerations 536 - Control plane aspects 538 - LDP security (authentication) methods as described in [RFC5036] is 539 applicable here. Further this document implements security 540 considerations as in [RFC4447] and [RFC4762]. 542 - Data plane aspects - This specification does not have any impact on 543 the VPLS forwarding plane. 545 8. Major Contributing Authors 547 The authors would like to thank Don Fedyk who made a major 548 contribution to development of this document. 550 Don Fedyk Alcatel-Lucent, EMail: donald.fedyk@alcatel-lucent.com 552 9. Acknowledgements 554 The authors would like acknowledge the comments and suggestions from 555 Wim Henderickx, Vach Kompella, Florin Balus, Mustapha Aissaoui, 556 Mathew Bocci, Miroslav Vrana, Nabil Bitar, Giles Heron and Ali 557 Sajassi. 559 10. References 561 10.1. Normative References 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, March 1997. 566 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 567 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 568 RFC 4762, January 2007. 570 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 571 Specification", RFC 5036, October 2007. 573 10.2. Informative References 575 [I-D.ietf-l2vpn-vpls-multihoming] 576 Kothari, B., Kompella, K., Henderickx, W., Balus, F., and 577 J. Uttaro, "BGP based Multi-homing in Virtual Private LAN 578 Service", draft-ietf-l2vpn-vpls-multihoming-05 (work in 579 progress), February 2013. 581 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 582 Heron, "Pseudowire Setup and Maintenance Using the Label 583 Distribution Protocol (LDP)", RFC 4447, April 2006. 585 [IEEE.802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan 586 area networks -- Media Access Control (MAC) Bridges and 587 Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 588 2011. 590 Authors' Addresses 592 Paul Kwok 593 Alcatel-Lucent 594 701 E Middlefield Road 595 Mountain View, CA 94043 596 USA 597 Email: paul.kwok@alcatel-lucent.com 599 Pranjal Kumar Dutta 600 Alcatel-Lucent 601 701 E Middlefield Road 602 Mountain View, CA 94043 603 USA 604 Email: pranjal.dutta@alcatel-lucent.com