idnits 2.17.1 draft-ietf-pals-mpls-tp-mac-wd-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 : ---------------------------------------------------------------------------- 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 (November 03, 2015) is 3095 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: 'RFC5226' is defined on line 363, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Sivabalan 3 Internet-Draft S. Boutros 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: May 03, 2016 H. Shah 6 Ciena Corp. 7 S. Aldrin 8 Google Inc. 9 M. Venkatesan 10 Comcast. 11 November 03, 2015 13 MAC Address Withdrawal over Static Pseudowire 14 draft-ietf-pals-mpls-tp-mac-wd-03.txt 16 Abstract 18 This document specifies a mechanism to signal MAC address withdrawal 19 notification using PW Associated Channel (ACH). Such notification is 20 useful when statically provisioned PWs are deployed in VPLS/H-VPLS 21 environment. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 3, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. MAC Withdraw OAM Message . . . . . . . . . . . . . . . . . . 4 66 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Operation of Sender . . . . . . . . . . . . . . . . . . . 6 68 4.2. Operation of Receiver . . . . . . . . . . . . . . . . . . 7 69 5. Security Consideration . . . . . . . . . . . . . . . . . . . 7 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 6.1. MPLS G-Ach type . . . . . . . . . . . . . . . . . . . . . 7 72 6.2. Sequence Number TLV . . . . . . . . . . . . . . . . . . . 8 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 7.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 An LDP-based MAC Address Withdrawal Mechanism is specified in 81 [RFC4762] to remove dynamically learned MAC addresses when the source 82 of those addresses can no longer forward traffic. This is 83 accomplished by sending an LDP Address Withdraw Message with a MAC 84 List TLV containing the MAC addresses to be removed, to all other PEs 85 over the LDP sessions. [RFC7361] describes an optimized MAC 86 withdrawal mechanism which can be used to remove only the set of 87 MAC addresses that need to be re-learned in H-VPLS networks. 88 [RFC7361] also describes optimized MAC Withdrawal operations 89 in PBB-VPLS networks. 91 A PW can be signaled via the LDP or can be statically provisioned. 92 In the case of static PW, LDP based MAC withdrawal mechanism cannot 93 be used. This is analogous to the problem and solution described in 94 [RFC6478] where PW OAM message has been introduced to carry PW 95 status TLV using in-band PW Associated Channel. In this document, we 96 propose to use PW OAM message to withdraw MAC address(es) learned via 97 static PW. 99 Thus, MAC withdraw signaling for static PW re-uses concepts of 101 - in-band signaling mechanisms used by static PW status signaling and 103 - MAC withdrawal mechanisms described by [RFC4762] and [RFC7361] 105 The MAC withdraw signaling is a best effort scheme. It is an attempt 106 to optimize the network convergence by reducing blackholes caused by 107 PW failover for protected PWs. The protocol defined in this document 108 addresses possible loss of MAC withdraw signal due to network 109 congestion, but do not assure the guarenteed delivery, as is the 110 case for the LDP based MAC withdraw signaling. In the event that MAC 111 withdraw signaling does not reach the intended target, the fallback 112 to MAC re-learning due to bi-directional traffic or as a last resort 113 to user configured MAC entries age out, will resume the traffic via 114 new PW path. Such fallbacks would cause temporary blackout but does 115 not render network permanently unusable. 117 2. Terminology 119 The following terminologies are used in this document: 121 ACK: Acknowledgement for MAC withdraw message. 123 LDP: Label Distribution Protocol. 125 MAC: Media Access Control. 127 PE: Provide Edge Node. 129 MPLS: Multi Protocol Label Switching. 131 PW: PseudoWire. 133 PW OAM: PW Operations, Administration and Maintenance. 135 TLV: Type, Length, and Value. 137 VPLS: Virtual Private LAN Services. 139 3. MAC Withdraw OAM Message 141 LDP provides a reliable packet transport for control plackets for 142 dynamic PWs. This can be contrasted with static PWs which rely on 143 re-transmission and acknowledgments (ACK) for reliable OAM packet 144 delivery as described in [RFC6478]. The proposed solution for MAC 145 withdrawal over static PW also relies on re-transmissions and ACKs. 146 However, ACK is mandatory. A given MAC withdrawal notification is 147 sent as a PW OAM message, and the sender re-transmits the message for 148 a configured number of times in the absence of an ACK response for 149 the sequence numbered message. The receiver removes the MAC 150 address(es) for a given sequence number MAC withdraw signaling and 151 sends the ACK response. The receipt of same or lower sequence number 152 message is responded with ACK but does not cause removal of MAC 153 addresses. A new TLV to carry the sequence number has been defined. 155 The format of the MAC address withdraw OAM message is shown in 156 Figure 1. The MAC withdraw PW OAM message follows same guidelines 157 used in [RFC6478], whereby first 4-bytes of OAM message header 158 is followed by message specific field and a set of TLVs relevant 159 for the message. Since the MAC withdrawal PW OAM message is not 160 refreshed forever, a MAC address withdraw OAM message MUST contain a 161 "Sequence Number TLV" otherwise the entire message is dropped. It 162 MAY contain MAC Flush Parameter TLVs defined in [RFC7361] when 163 static PWs are deployed in H-VPLS and PBB-VPLS scenarios. The first 164 2 bits of the sequence number TLV are reserved and MUST be set to 0 165 on transmit and ignored on receipt. 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 |0 0 0 1|Version| Reserved |(TBD) MAC Withdraw OAM Message | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Reserved | TLV Length |A|R| Flags | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 |Res| Sequence Number TLV (TBD) | Sequence Number TLV Length | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Sequence Number | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | | 179 | MAC List TLV | 180 ~ MAC Flush Parameter TLV (optional) ~ 181 | | 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 1: MAC Address Withdraw PW OAM Packet Format 187 In this section, MAC List TLV and MAC Flush Parameter TLV are 188 collectively referred to as "MAC TLV(s)". The definition and 189 processing rules of MAC List TLV are described by [RFC4762], and the 190 corresponding rules of MAC Flush Parameter TLV are governed by 191 [RFC7361]. 193 "TLV Length" is the total length of all TLVs in the message, and 194 "Sequence Number TLV Length" is the length of the sequence number 195 field. 197 A single bit (called A-bit) is set by a receiver to acknowledge 198 receipt and processing of a MAC Address Withdraw OAM message. 199 In the acknowledge message, with A-bit set, MAC TLV(s) is/are 200 excluded. 202 A single bit (called R-bit) is set to indicate if the sender is 203 requesting reset of the sequence numbers. The sender sets this bit 204 when the Pseudowire is restarted and has no local record of send and 205 expected receive sequence number. 207 The Sequence number TLV MUST be the first TLV in the message. 209 The lack of reliable transport protocol for the in-band OAM 210 necessitates a presence of sequencing and acknowledgement 211 scheme so that the receiver can recognize newer message from 212 retransmitted older messages. The [RFC4385] describes the details 213 of sequence number handling which includes overflow detection for 214 sequence number field of size 16-bits. This document leverages 215 the same scheme with the two exemptions 216 - sequence number field is of size 32-bits 217 - overflow detection is simplified such that sequence 218 number exceed 2,147,483,647 (0x7FFFFFFF) is considered 219 overflow and reset to 1. 221 4. Operation 223 This section describes how the initial MAC withdraw OAM messages are 224 sent and retransmitted, as well as how the messages are processed and 225 retransmitted messages are identified. 227 4.1. Operation of Sender 229 Each PW is associated with a counter to keep track of the sequence 230 number of the transmitted MAC withdrawal messages. Whenever a node 231 sends a new set of MAC TLVs, it increments the transmitted sequence 232 number counter, and include the new sequence number in the message. 233 The transmit sequence number is initialized to 1 at the onset, after 234 the wrap and after the sequence number reset request receipt. 235 Hence the transmit sequence number is set to 2 in the first MAC 236 withdraw message sent after the sequence number is initialized 237 to 1. 239 The sender expects an ACK from the receiver within a time interval 240 which we call "Retransmit Time" which can be either a default (1 241 second) or configured value. If the ACK does not arrive within the 242 Retransmit Time, the sender retransmits the message with the same 243 sequence number as the original message. The retransmission MUST 244 be ceased when an ACK is received. In order to avaoid continuous 245 retransmissions in the absence of acknowledgements, a method of 246 suppressing retransmission MUST be implemented. A simple and 247 well used approach is to cease retransmission after a small 248 number of transmissions. A one second retransmission with two 249 retries in the absence of an ACK response is RECOMMENDED. 250 However, both the interval and the number of retries are a local 251 matter which present no interworking issues and thus the operator 252 MAY configure different values. Alternatively, an increasing 253 backoff delay with a larger number of retries MAY be implemented 254 to improve scaling issues. Whilst there are no interworking issues 255 with any of these methods, the implementer must be mindful of not 256 introducing network congestion and must take into account of 257 decaying value of delayed MAC withdraw signaling against possible 258 relearning due to bidirectional traffic or MAC age timeout. 260 During the period of retransmission, if a need to send a new MAC 261 withdraw message with updated sequence number arises then 262 retransmission of the older unacknowledged withdraw message MUST be 263 suspended and retransmit time for the new sequence number MUST be 264 initiated. In essence, sender engages in retransmission logic only 265 for the latest send withdraw message for a given PW. 267 In the event that a Pseudowire was deleted and re-added or the router 268 is restarted with configuration, the local node may lose information 269 about the send sequence number of previous incarnation. This becomes 270 problematic for the remote peer as it will continue to ignore the 271 received MAC withdraw messages with lower sequence numbers. In such 272 cases, it is desirable to reset the sequence numbers at both ends of 273 the Pseudowire. The 'R' reset bit is set in the first MAC withdraw 274 to notify the remote peer to reset the send and receive sequence 275 numbers. The 'R' bit must be cleared in subsequent MAC withdraw 276 messages after the acknowledgement is received 278 4.2. Operation of Receiver 280 Each PW is associated with a register to keep track of the expected 281 sequence number of the MAC withdrawal message and is initialized to 282 1. Whenever a MAC withdrawal message is received, and if the 283 sequence number on the message is greater than the value in the 284 register, the MAC address(es) contained in the MAC TLV(s) is/are 285 removed, and the register is updated with the received sequence 286 number. The receiver sends an ACK whose sequence number is the 287 same as that in the received message. 289 If the sequence number in the received message is smaller than or 290 equal to the value in the register, the MAC TLV(s) is/are not 291 processed. However, an ACK with the received sequence number MUST be 292 sent as a response. The receiver processes the ACK message as an 293 acknowledgement for all the MAC withdraw messages sent up to the 294 sequence number present in the ACK message and terminates 295 retransmission. 297 The handling of the sequence number is described in section 3. 299 A MAC withdraw message with 'R' bit set MUST be processed by 300 resetting the send and receive sequence number first. The rest of 301 MAC withdraw message processing is performed as described above. The 302 acknowledgement is sent with 'R' bit cleared. 304 5. Security Consideration 306 The security measures described in [RFC4447], [RFC5085], and 307 [RFC6073] are adequate for the proposed mechanism. 309 6. IANA Considerations 311 6.1. MPLS G-Ach type 313 This document requests IANA to assign new channel type (requested 314 value 0x0028) from the registry named "MPLS Generalized Associated 315 Channel (G-ACh) Types (including Pseudwire Associated Channel 316 Types)". The description of the new channel type is "MAC Withdraw 317 OAM Message". [TO BE REMOVED: This registration should take place at 318 the following location: http://www.iana.org/assignments/g-ach- 319 parameters/g-ach-parameters.xhtml]. The channel type value of 0x0028 320 is requested as it is used in implementations that are deployed in 321 the field. 323 6.2. Sequence Number TLV 325 This document requests IANA to assign a new TLV Type 326 (requested value 0x0001) from the existing LDP "TLV Type Name 327 Space" registry. The description for the new TLV Type is 328 "Sequence Number TLV". 330 [Note to IANA TO BE REMOVED BY THE RFC EDITOR: This registration 331 should take place at the following location: 332 http://www.iana.org/assignments/ldp-namespaces/ldp-namespaces.xhtml]. 333 In an earlier revision of this draft, we created a new sub-TLV 334 registry with one entry, a new "Sequence Number TLV" with the 335 value 0x0001. This has been implemented by several vendors. The 336 IESG proposed that rathen than create a new sub-TLV registry, we 337 just allocate a new code point from the existing LDP "TLV Type Name 338 Space" registry. In this registry, the value 0x0001 is available for 339 allocation by standards action, so we request this code point for 340 the new "Sequence Number" TLV type to avoid needing to change 341 the existing implementations. 343 7. References 345 7.1. Normative References 347 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 348 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 349 Use over an MPLS PSN", RFC 4385, February 2006. 351 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 352 Heron, "Pseudowire Setup and Maintenance Using the Label 353 Distribution Protocol (LDP)", RFC 4447, April 2006. 355 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 356 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 357 RFC 4762, January 2007. 359 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 360 Connectivity Verification (VCCV): A Control Channel for 361 Pseudowires", RFC 5085, December 2007. 363 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 364 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 365 May 2008. 367 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 368 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 370 [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, 371 "Pseudowire Status for Static Pseudowires", RFC 6478, May 372 2012. 374 [RFC7361] Dutta, P., Balus, F., Stokes, O., Calvignac, G., and D. 375 Fedyk, "LDP Extensions for Optimized MAC Address 376 Withdrawal in a Hierarchical Virtual Private LAN Service 377 (H-VPLS)", RFC 7361, September 2014. 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 7.2. Informative References 384 Authors' Addresses 386 Siva Sivabalan 387 Cisco Systems, Inc. 388 2000 Innovation Drive 389 Kanata, Ontario K2K 3E8 390 Canada 392 Email: msiva@cisco.com 394 Sami Boutros 395 Cisco Systems, Inc. 396 170 West Tasman Dr. 397 San Jose, CA 95134 398 US 400 Email: sboutros@cisco.com 402 Himanshu Shah 403 Ciena Corp. 404 3939 North First Street 405 San Jose, CA 95134 406 US 408 Email: hshah@ciena.com 409 Sam Aldrin 410 Google Inc. 412 Email: aldrin.ietf@gmail.com 414 Mannan Venkatesan 415 Comcast. 416 1800 Bishop Gate Blvd 417 Mount Laurel, NJ 08075 418 US 420 Email: mannan_venkatesan@cable.comcast.com