idnits 2.17.1 draft-boutros-l2vpn-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 02, 2014) is 3649 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 (-13) exists of draft-ietf-l2vpn-vpls-ldp-mac-opt-08 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Sivabalan 3 Internet-Draft S. Boutros 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: October 4, 2014 H. Shah 6 Ciena Corp. 7 S. Aldrin 8 Huawei Technologies. 9 M. Venkatesan 10 Comcast. 11 April 02, 2014 13 MAC Address Withdrawal over Static Pseudowire 14 draft-boutros-l2vpn-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 October 4, 2014. 46 Copyright Notice 48 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . 3 66 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Operation of Sender . . . . . . . . . . . . . . . . . . . 5 68 4.2. Operation of Receiver . . . . . . . . . . . . . . . . . . 5 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 6.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 An LDP-based MAC Address Withdrawal Mechanism is specified in 78 [RFC4762] to remove dynamically learned MAC addresses when the source 79 of those addresses can no longer forward traffic. This is 80 accomplished by sending an LDP Address Withdraw Message with a MAC 81 List TLV containing the MAC addressed to be removed to all other PEs 82 over LDP sessions. When the number of MAC addresses to be removed is 83 large, empty MAC List TLV may be used. [MAC-OPT] describes an 84 optimized MAC withdrawal mechanism which can be used to remove only 85 the set of MAC addresses that need to be re-learned in H-VPLS 86 networks. The solution also provides optimized MAC Withdrawal 87 operations in PBB-VPLS networks. 89 A PW can be signaled via LDP or can be statically provisioned. In 90 the case of static PW, LDP based MAC withdrawal mechanism cannot be 91 used. This is analogous to the problem and solution described in 92 [RFC4762] where PW OAM message has been introduced to carry PW 93 status TLV using in-band PW Associated Channel. In this document, we 94 propose to use PW OAM message to withdraw MAC address(es) learned via 95 static PW. 97 2. Terminology 99 The following terminologies are used in this document: 101 ACK: Acknowledgement for MAC withdraw message. 103 LDP: Label Distribution Protocol. 105 MAC: Media Access Control. 107 PE: Provide Edge Node. 109 MPLS: Multi Protocol Label Switching. 111 PW: PseudoWire. 113 PW OAM: PW Operations, Administration and Maintenance. 115 TLV: Type, Length, and Value. 117 VPLS: Virtual Private LAN Services. 119 3. MAC Withdraw OAM Message 121 LDP provides a reliable packet transport for control plackets for 122 dynamic PWs. This can be contrasted with static PWs which rely on 123 re-transmission and acknowledgments (ACK) for reliable OAM packet 124 delivery as described in [RFC6478]. The proposed solution for MAC 125 withdrawal over static PW also relies on re-transmissions and ACKs. 126 However, ACK is mandatory. A given MAC withdrawal notification is 127 sent as a PW OAM message, and the sender keeps re-transmitting the 128 message until it receives an ACK for that message. Once a receiver 129 successfully remove MAC address(es) in response to a MAC address 130 withdraw OAM message, it should not unnecessarily remove MAC 131 address(es) upon getting refresh message(s). To facilitate this, the 132 proposed mechanism uses sequence number, and defines a new TLV to 133 carry the sequence number. 135 The format of the MAC address withdraw OAM message is shown in 136 Figure 1. The PW OAM message header is exactly the same as what is 137 defined in [RFC6478]. Since the MAC withdrawal PW OAM message is not 138 refreshed forever. A MAC address withdraw OAM message MUST contain a 139 "Sequence Number TLV" otherwise the entire message is dropped. It 140 MAY contain MAC Flush Parameter TLVs defined in [MAC-OPT] when 141 static PWs are deployed in H-VPLS and PBB-VPLS scenarios. The first 142 2 bits of the sequence number TLV are reserved and MUST be set to 0 143 on transmit and ignored on receipt. 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 |0 0 0 1|Version| Reserved |0xZZ MAC Withdraw OAM Message | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Reserved | TLV Length |A|R| Flags | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 |Res| Sequence Number TLV (TBD) | Sequence Number TLV Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Sequence Number | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | | 157 | MAC List TLV | 158 ~ MAC Flush Parameter TLV (optional) ~ 159 | | 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 1: MAC Address Withdraw PW OAM Packet Format 165 In this section, MAC List TLV and MAC Flush Parameter TLV are 166 collectively referred to as "MAC TLV(s)". The processing rules of 167 MAC List TLV are governed by [RFC4762], and the corresponding rules 168 of MAC Flush Parameter TLV are governed by [MAC-OPT]. 170 "TLV Length" is the total length of all TLVs in the message, and 171 "Sequence Number TLV Length" is the length of the sequence number 172 field. 174 A single bit (called A-bit) is set to indicate if a MAC withdraw 175 message is for ACK. Also, ACK does not include MAC TLV(s). 177 Only half of the sequence number space is used. Modular arithmetic 178 is used to detect wrapping of sequence number. When sequence number 179 wraps, all MAC addresses are flushed and the sequence number is 180 reset. 182 A single bit (called R-bit) is set to indicate if the sender is 183 requesting reset of the sequence numbers. The sender sets this bit 184 when the Pseudowire is restarted and has no local record of send and 185 expected receive sequence number. 187 4. Operation 189 This section describes how the initial MAC withdraw OAM messages are 190 sent and retransmitted, as well as how the messages are processed and 191 retransmitted messages are identified. 193 4.1. Operation of Sender 195 Each PW is associated with a counter to keep track of the sequence 196 number of the transmitted MAC withdrawal messages. Whenever a node 197 sends a new set of MAC TLVs, it increments the transmitted sequence 198 number counter, and include the new sequence number in the message. 199 The transmit sequence number is initialized to 1 at the onset. 201 The sender expects an ACK from the receiver within a time interval 202 which we call "Retransmit Time" which can be either a default (1 203 second) or configured value. If the ACK does not arrive within the 204 Retransmit Time, the sender retransmits the message with the same 205 sequence number as the original message. The retransmission is 206 ceased anytime when ACK is received or after three retries. This 207 avoids unended retransmissions in the absence of acknowledgements. 208 In addition, if during the period of retransmission, if a need to 209 send a new MAC withdraw message with updated sequence number arises 210 then retransmission of the older unacknowledged withdraw message is 211 suspended and retransmit time for the new sequence number is 212 initiated. In essence, sender engages in retrasmission logic only 213 for the latest send withdraw message for a given PW. 215 In the event that a Pseudowire was deleted and re-added or the router 216 is restarted with configuration, the local node may lose information 217 about the send sequence number of previous incarnation. This becomes 218 problematic for the remote peer as it will continue to ignore the 219 received MAC withdraw messages with lower sequence numbers. In such 220 cases, it is desirable to reset the sequence numbers at both ends of 221 the Pseudowire. The 'R' reset bit is set in the first MAC withdraw 222 to notify the remote peer to reset the send and receive sequence 223 numbers. The 'R' bit must be cleared in subsequent MAC withdraw 224 messages after the acknowledgement is received 226 4.2. Operation of Receiver 228 Each PW is associated with a register to keep track of the sequence 229 number of the MAC withdrawal message received last. Whenever a MAC 230 withdrawal message is received, and if the sequence number on the 231 message is greater than the value in the register, the MAC 232 address(es) contained in the MAC TLV(s) is/are removed, and the 233 register is updated with the received sequence number. The receiver 234 sends an ACK whose sequence number is the same as that in the 235 received message. 237 If the sequence number in the received message is smaller than or 238 equal to the value in the register, the MAC TLV(s) is/are not 239 processed. However, an ACK with the received sequence number MUST be 240 sent as a response. The receiver processes the ACK message as an 241 acknowledgement for all the MAC withdraw messages sent up to the 242 sequence number present in the ACK message and terminates 243 retransmission. 245 As mentioned above, since only half of the sequence number space is 246 used, the receiver MUST use modular arithmetic to detect wrapping of 247 the sequence number. 249 A MAC withdraw message with 'R' bit set MUST be processed by 250 resetting the send and receive sequence number first. The rest of 251 MAC withdraw message processing is performed as described above. The 252 acknowledgement is sent with 'R' bit cleared. 254 5. IANA Considerations 256 The proposed mechanism requests IANA to a assign new channel type 257 (recommended value 0x0028) from the registry named "Pseudowire 258 Associated Channel Types". The description of the new channel type 259 is "Pseudowire MAC Withdraw OAM Channel". 261 IANA needs to create a new registry for Pseudowire Associated Channel 262 TLVs, and create an entry for "Sequence Number TLV". The recommended 263 value is 0x0001. 265 6. References 267 6.1. Normative References 269 [MAC-OPT] Dutta, P., Balus, F., Stokes, O., and G. Calvinac, "LDP 270 Extensions for Optimized MAC Address Withdrawal in 271 H-VPLS", draft-ietf-l2vpn-vpls-ldp-mac-opt-08.txt (work in 272 progress), February 2013. 274 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 275 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 276 RFC 4762, January 2007. 278 [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, 279 "Pseudowire Status for Static Pseudowires", RFC 6478, May 280 2012. 282 6.2. Informative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 Authors' Addresses 289 Siva Sivabalan 290 Cisco Systems, Inc. 291 2000 Innovation Drive 292 Kanata, Ontario K2K 3E8 293 Canada 295 Email: msiva@cisco.com 297 Sami Boutros 298 Cisco Systems, Inc. 299 170 West Tasman Dr. 300 San Jose, CA 95134 301 US 303 Email: sboutros@cisco.com 305 Himanshu Shah 306 Ciena Corp. 307 3939 North First Street 308 San Jose, CA 95134 309 US 311 Email: hshah@ciena.com 313 Sam Aldrin 314 Huawei Technologies. 315 2330 Central Express Way 316 Santa Clara, CA 95051 317 US 319 Email: aldrin.ietf@gmail.com 320 Mannan Venkatesan 321 Comcast. 322 1800 Bishop Gate Blvd 323 Mount Laurel, NJ 08075 324 US 326 Email: mannan_venkatesan@cable.comcast.com