idnits 2.17.1 draft-chen-l2vpn-vpls-mac-opt-qualified-01.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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC4762], [RFC4664], [I-D.ietf-l2vpn-vpls-ldp-mac-opt]), 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 14, 2011) is 4793 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: 'RFC2119' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'RFC4447' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 326, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-l2vpn-vpls-ldp-mac-opt-03 ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Downref: Normative reference to an Informational RFC: RFC 4664 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group R. Chen 3 Internet-Draft Y. Wang 4 Intended status: Standards Track ZTE Corporation 5 Expires: September 15, 2011 L. Guo 6 China Telecom 7 March 14, 2011 9 LDP Extensions for Optimized MAC Address Withdrawal in VPLS model 3 10 supporting Qualified learning 11 draft-chen-l2vpn-vpls-mac-opt-qualified-01 13 Abstract 15 This draft defines a method for optimized MAC Address Withdrawal in 16 VPLS model 3 ([RFC4664]) supporting qualified learning ([RFC4762]). 17 Some extensions are made based on the MAC Address Withdrawal 18 procedures defined in [RFC4762] and 19 [I-D.ietf-l2vpn-vpls-ldp-mac-opt], in order to enable a PE to remove 20 only the MAC addresses, which belong to MAC address space affected by 21 topology change. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 15, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions used in this document . . . . . . . . . . . . . . . 3 59 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Optimized MAC Flush Mechanism . . . . . . . . . . . . . . . . . 6 62 4.1. MAC Address Space TLV . . . . . . . . . . . . . . . . . . . 6 63 4.2. MAC Address Space TLV Processing Rules . . . . . . . . . . 7 64 4.3. Optimized MAC Flush Procedures . . . . . . . . . . . . . . 8 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 67 7. Normative references . . . . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 There are operators deploying VPLS with qualified learning mode 73 [RFC4762], so as to reduce the number of VPLS instance. By using 74 VLAN within VPLS and qualified learning mode to separate customer 75 internally, current defined VPLS MAC address withdraw mechanism will 76 flush MAC addresses VLAN space which are not affected due to topology 77 change. 79 [RFC4762] defines a basic MAC Address Withdrawal mechanism to remove 80 or unlearn MAC addresses for faster convergence on topology change. 81 It defines MAC List TLV which contains a list of MAC addresses to be 82 flushed in LDP Address Withdraw Message, and when a MAC List TLV 83 contains a large number of MAC addresses, it would be preferable to 84 send a LDP Address Withdraw Message with an empty MAC List. 86 As per the rules in [RFC4762], on receiving a MAC Address Withdrawal 87 Message with MAC List TLV, a PE removes the association between the 88 MAC address and the AC or PW over which this message is received. 89 For a MAC Address Withdraw message with empty MAC list, a PE removes 90 all MAC addresses except the MAC addresses learned over the newly 91 activated PW. The PE further transmits a MAC Address Withdrawal 92 message to each remote PE in the VPLS network. The problem is that 93 it will flush MAC addresses which are not affected due to topology 94 change, thus leading to unnecessary flooding and relearning. 96 Draft [I-D.ietf-l2vpn-vpls-ldp-mac-opt] defines an extension to the 97 MAC Address Withdrawal procedure with empty MAC List ([RFC4762]). It 98 is accomplished by sending an LDP Address Withdraw Message with the 99 empty MAC addresses and PE-ID TLV. When a PE device receives a MAC 100 Address Withdrawal message with a PE-ID TLV, it SHOULD flush all the 101 MAC addresses learned from the PW, which terminates in the remote VSI 102 identified by the PE-ID element. Comparing with [RFC4762], this 103 mechanism narrows the scope of MAC address flush to PE-ID elements. 104 But if this mechanism is used in VPLS model 3 ([RFC4664]) supporting 105 qualified learning ([RFC4762]), it also flushes MAC addresses 106 belonging to MAC address space which are not affected due to topology 107 change. 109 This draft describes the problem and a solution to optimize the MAC 110 flush procedure in [RFC4762] and [I-D.ietf-l2vpn-vpls-ldp-mac-opt], 111 and enable it to flush only the MAC addresses belonging to the MAC 112 address space affected by topology change. 114 2. Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC2119. 120 2.1. Terminology 122 AC: Attachment Circuit 124 CE: Customer Edge device 126 LDP: Label Distribution Protocol 128 PE: Provider Edge 130 PW: Pseudowire 132 MTU-s: Multi-Tenant Unit switch 134 3. Problem Description 136 VLAN1 137 VLAN2 VLAN2 138 CE-2 CE-3 139 / / 140 PE-1 / PE-3 / 141 +--------+/ +--------+/ 142 | | | | 143 | -- | PW2 | -- | 144 VLAN1 | / \ |------------------| / \ | 145 CE-1 /------| \ s/ | | \S / | 146 \ primary spoke PW | -- | /------| -- | 147 \ / +--------+ / +--------+ 148 \ (MTU-s)/ | \ PW3 / PW6| 149 +--------+/ | \ / | 150 | | | \ / | 151 | -- | PW1 | \ / | 152 | / \ | | H-VPLS Full Mesh Core| 153 | \S / | | / \ | 154 | -- | | / \ | 155 +--------+\ | PW4/ \ | 156 backup spoke PW | / \ | 157 \ +--------+ \--------+--------+ 158 \ | | | | 159 \------| -- | PW5 | -- | 160 | / \ |------------------| / \ | 161 | \s / | | \S / | 162 | -- | | -- | 163 /+--------+ +--------+ 164 / PE-2 PE-4 165 / 166 CE-4 167 VLAN1 168 VLAN2 170 Figure 1: Dual homed MTU-s in two tier hierarchy H-VPLS 172 Figure 1 is an example for the dual-homing access topology in VPLS 173 model 3 supporting qualified learning. 175 There are four VLANs in Figure 1, and each customer VLAN has its own 176 broadcast domain and MAC address space. CE-1 and CE-3 belong to 177 VLAN1, CE-2 and CE-4 belong to VLAN2. 179 CE-1, CE-2, CE-3 and CE-4 connect with MTU-S, PE-1, PE-4 and PE-2 180 respectively. The MTU-S is dual-homed to PE-1 and PE-2. Only the 181 primary spoke PW is active at MTU-s, thus PE-1 is acting as the 182 active device to reach the full mesh in the VPLS instance. 184 When MTU-s switches to the backup spoke PW and activates it, PE-2 185 becomes the active device to reach the full mesh core. Traffic 186 entering the H-VPLS from CE-1 is diverted by the MTU-s to the backup 187 spoke PW. For faster convergence MTU-s may desire to unlearn or 188 remove the MAC addresses belonging to VLAN1 and learned from the PW 189 that terminates at PE-1 MUST be removed. Once the backup PW has been 190 made active, MTU-s may send a MAC flush message to PE-2. 192 As per the rules defined in [RFC4762], PE-2 flushes all of the MAC 193 addresses learned in the VPLS from the PWs terminating at PE-1, PE-3 194 and PE-4. PE-2 further relays MAC flush messages to PE-1, PE-3 and 195 PE-4. Same processing rule applies at all those PE. 197 As per the rules defined in [I-D.ietf-l2vpn-vpls-ldp-mac-opt], PE-2 198 flushes all of the MAC addresses learned in the VPLS from the PWs 199 terminating at PE-1. In fact, PE2 need not flush the MAC addresses 200 belonging to VLAN2 and learned over PW1.There are multi-Mac addresses 201 spaces in a single VPLS, and the affected Mac addresses spaces is 202 only VLAN1. PE-2 only need flush and relearn MAC addresses belong to 203 VLAN1 and learned over PW1. 205 With the number of PE in the full-mesh increases, the number of 206 unaffected MAC addresses flushed in a VPLS instance also increases, 207 thus leading to unnecessary flooding and relearning. 209 4. Optimized MAC Flush Mechanism 211 4.1. MAC Address Space TLV 213 This draft proposes a MAC Address Space TLV, it is carried in the LDP 214 Address Withdraw Message. The MAC Address Space TLV carries a MAC 215 address Space which are affected due to topology change. When a PE 216 receives a LDP Address Withdraw message with MAC Address Space TLV, 217 then the PE only flushes the suspect MAC addresses belonging to the 218 MAC Address Space elements. 220 The new MAC Address Space TLV format is as follows: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |U|F| MAC Address Space TLV(TBD)| Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | MAC address space | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 2: MAC Address Space TLV format 232 U bit: Unknown bit. This bit MUST be set to 1. If the MAC address 233 Space format is not understood, then it MUST be ignored. 235 F bit: Forward bit. This bit MUST be set to 0. Since the LDP 236 mechanism used here is targeted, the TLV MUST NOT be forwarded. 238 Type: Type field. This identifies the TLV type as MAC Address Space 239 TLV. 241 Length: Length field. This field specifies the total length in 242 octets of value in MAC Address Space TLV. 244 MAC Address Space: This identifies the MAC addresses Space which are 245 affected due to topology change. 247 The MAC address space TLV should immediately be after the MAC address 248 list TLV. It is used to indicate MAC address space that these MAC 249 address list belongs to. 251 4.2. MAC Address Space TLV Processing Rules 253 If a PE receives a MAC Address Withdraw with MAC Address Space TLV 254 and empty MAC list, it SHOULD remove all the MAC addresses belonging 255 to the MAC Address Spaces in a VPLS instance, except the MAC 256 addresses learned over the PW associated with this signaling session 257 over which the message was received. 259 If a PE receives a MAC Address Withdraw with MAC Address Space TLV 260 and MAC list TLV, it SHOULD remove the MAC address belonging to the 261 MAC Address Space in a VPLS instance. 263 If a PE receives a MAC Address Withdraw with MAC Address Space TLV 264 and PE-ID TLV, from the specified MAC Address Space which is 265 identified by MAC Address Space TLV, it SHOULD remove all the MAC 266 addresses learned from the PW, which terminates at the PE identified 267 by the PE-ID. 269 If a PE that doesn't support MAC Address Space TLV, receives a MAC 270 flush message with this option, it MUST ignore the option and follow 271 the processing rules as per [RFC4762] and 272 [I-D.ietf-l2vpn-vpls-ldp-mac-opt]. 274 4.3. Optimized MAC Flush Procedures 276 This section explains the optimized MAC flush procedure in the 277 scenario shown in Figure 1. 279 When the backup PW is activated by MTU-s, it may send MAC Address 280 Withdraw message to PE-2 with the optional PE-ID TLV and MAC Address 281 Space TLV. Upon receipt of the MAC Address Withdraw message, PE-2 282 identifies the VPLS instance that requires MAC Address Withdraw from 283 the FEC element in the FEC TLV. From the PE-ID TLV, PE-2 identifies 284 the PW in the VPLS that terminates in PE-1. From the MAC Address 285 Space TLV, PE-2 identifies MAC addresses Space which are affected due 286 to topology change. PE-2 removes all MAC addresses belong to VLAN1 287 and learned over PW1. 289 PE-2 relays MAC Address Withdraw messages with the received MAC 290 Address Space TLV and PE-ID to all its peer PE devices. When the 291 message is received at PE-3/PE-4, MAC addresses belonging to VLAN1 292 and learned over the PW that terminates at PE1 MUST be removed. 294 5. IANA Considerations 296 The type field in the MAC List TLV is defined as 0x406 and is subject 297 to IANA approval 299 6. Security Considerations 301 Security considerations discussed in [RFC4762] and [I-D.ietf-l2vpn- 302 vpls-ldp-mac-opt] apply to this document. 304 7. Normative references 306 [I-D.ietf-l2vpn-vpls-ldp-mac-opt] 307 Dutta, P., Balus, F., Calvignac, G., and O. Stokes, "LDP 308 Extensions for Optimized MAC Address Withdrawal in 309 H-VPLS", draft-ietf-l2vpn-vpls-ldp-mac-opt-03 (work in 310 progress), October 2010. 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, March 1997. 315 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 316 Heron, "Pseudowire Setup and Maintenance Using the Label 317 Distribution Protocol (LDP)", RFC 4447, April 2006. 319 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 320 Private Networks (L2VPNs)", RFC 4664, September 2006. 322 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 323 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 324 RFC 4762, January 2007. 326 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 327 Specification", RFC 5036, October 2007. 329 Authors' Addresses 331 Ran Chen 332 ZTE Corporation 333 4F,RD Building 2,Zijinghua Road 334 Yuhuatai District,Nanjing 210012 335 P.R.China 337 Phone: +86 025 52878135 338 Email: chen.ran@zte.com.cn 340 Yubao Wang 341 ZTE Corporation 342 4F,RD Building 2,Zijinghua Road 343 Yuhuatai District,Nanjing 210012 344 P.R.China 346 Phone: +86 025 52872130 347 Email: wang.yubao2@zte.com.cn 349 Liang Guo 350 China Telecom 351 26/F,109 Zhongshan Ave 352 Tianhe District,Guangzhou 510630 353 P.R.China 355 Phone: +86 020 38639595 356 Email: guoliang@gsta.com