idnits 2.17.1 draft-boutros-nvo3-mac-move-over-geneve-02.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 (September 19, 2019) is 1681 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) == Missing Reference: 'RFC2119' is mentioned on line 111, but not defined == Unused Reference: 'KEYWORDS' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'Geneve' is defined on line 285, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Sami Boutros 3 Intended Status: Standard Track Jerome Catrouillet 4 Sri Mohana Singamsetty 5 VMware 6 Parag Jain 7 Cisco 9 Expires: March 22, 2020 September 19, 2019 11 MAC move over Geneve encapsulation 12 draft-boutros-nvo3-mac-move-over-geneve-02 14 Abstract 16 This document specifies a mechanism to signal Media Access Control 17 (MAC) addresses move over a Network Virtualization Overlays over 18 Layer 3 (NVO3) virtual tunnel. Such notification is useful in 19 redundancy scenarios when a Layer 2 service that was active on a 20 Network Virtualization Edge (NVE) fails over to a standby NVE. This 21 notification can be used only when data plane mac learning is enabled 22 over the NVO3 tunnels. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. MAC Move Frame Format . . . . . . . . . . . . . . . . . . . . . 5 65 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1 Operation of Sender . . . . . . . . . . . . . . . . . . . . 6 67 3.2 Operation of Receiver . . . . . . . . . . . . . . . . . . . 7 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6.1 Normative References . . . . . . . . . . . . . . . . . . . 8 72 6.2 Informative References . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1 Introduction 77 In multi-homing scenarios a Layer 2 service can be multi-homed to 78 more than one Network virtualization Edge (NVE). Only one NVE can be 79 active for a given Layer 2 service, and a standby NVE can be chosen 80 to take over the Layer 2 service when the active NVE goes down. The 81 mechanisms to elect which NVE will be active or standby to provide 82 single active redundancy for a given Layer 2 service is outside the 83 scope of this document. 85 When a standby NVE gets activated, Standby NVE needs to send a MAC 86 Move message to all remote NVE(s) that spans this L2 service over the 87 Geneve tunnels to Move all MAC learned in data plane via the old 88 active NVE. 90 The MAC Move message will contain the NVE Identifier(s) of the old 91 Active NVE and the new active NVE. 93 MAC Move can be used to optimize network convergence and reduce 94 blackholes, when an active NVE hosting a logical L2 service fails 95 over to a standby NVE. 97 The protocol defined in this document addresses possible loss of the 98 MAC Move messages due to network congestion, but does not guarantee 99 delivery. 101 In the event that MAC Move messages does not reach the intended 102 target, the fallback to MAC re-learning or as a last resort aging out 103 of MAC addresses in the absence of frames from the sources, will 104 resume the traffic via new active NVE. 106 1.1 Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 1.2 Abbreviations 114 NVO3 Network Virtualization Overlays over Layer 3 116 OAM Operations, Administration, and Maintenance 118 TLV Type, Length, and Value 120 VNI Virtual Network Identifier 122 NVE Network Virtualization Edge 123 NVA Network Virtualization Authority 125 NIC Network interface card 127 VTEP Virtual Tunnel End Point 129 Transit device Underlay network devices between NVE(s). 131 2. MAC Move Frame Format 133 Geneve Header: 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |Ver| Opt Len |O|C| Rsvd. | Protocol Type | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Virtual Network Identifier (VNI) | Reserved | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Geneve Option Header: 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Option Class | Type |R|R|R| Length | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Variable Option Data | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Option Class = To be assigned by IANA (TBA). 153 Type = TBA. 155 'C' bit, Endpoints must drop if they do not recognize this option) 157 Length = 2 (8 bytes) 159 Variable option data: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 |Version|Flags |A|R| old active VTEP ID | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |Reserved | new active VTEP ID | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Sequence Number | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Version (4 bits): Initially the Version will be 0. 173 A (1 bit): Set by a receiver to acknowledge receipt and processing 174 of a MAC Move message. 176 R (1 bit): Set to indicate if the sender is requesting reset of 177 the sequence numbers. The sender sets this bit when it has no 178 local record of previous send and expected receive sequence 179 numbers. 181 Flags(6): Reserved and should be set to 0. 183 VTEP ID (20 bits): Identifies old and new active NVE(s). 185 Sequence Number (32) bits: For overflow detection a sequence 186 number that exceeds (0x7FFFFFFF) is considered an overflow and 187 reset to 1. 189 3. Operation 191 This section describes how the initial MAC Move Messages are sent and 192 retransmitted, as well as how the messages are processed and 193 retransmitted messages are identified. The mechanisms described are 194 very similar to the one defined in [RFC 7769]. 196 3.1 Operation of Sender 198 At the NVE , each L2 logical switch identified by a VNI is associated 199 with a counter to keep track of the sequence number of the 200 transmitted MAC Move messages. Whenever a node sends a MAC Move 201 message, it increments the transmitted sequence-number counter and 202 includes the new sequence number in the message. 204 The transmit sequence number is initialized to 1 at the onset, after 205 the wrap and after the sequence number reset request receipt. Hence 206 the transmit sequence number is set to 2 in the first MAC Move 207 message sent after the sequence number is initialized to 1. 209 The sender expects an ACK from the receiver within a retransmit time 210 interval, which can be either a default (1 second) or a configured 211 value. If the ACK is not received within the Retransmit time, the 212 sender retransmits the message with the same sequence number as the 213 original message. The retransmission MUST cease when an ACK is 214 received. In order to avoid continuous re-transmissions in the 215 absence of acknowledgements, the sender MUST cease retransmission 216 after a small number of transmissions, two retries is RECOMMENDED. 218 Alternatively, an increasing backoff delay with a larger number of 219 retries MAY be implemented to improve scaling issues. 221 During the period of retransmission, if a need to send a new MAC Move 222 message with updated sequence number arises, then retransmission of 223 the older unacknowledged Move message MUST be suspended and 224 retransmit time for the new sequence number MUST be initiated. In 225 essence, a sender engages in retransmission logic only for the most 226 recently sent Move message for a given L2 Logical Switch identified 227 by a VNI. 229 In the event that the L2 logical switch is deleted and re-added or 230 the VTEP node is restarted with new configuration, the NVE may lose 231 information about the previously sent sequence number. This becomes 232 problematic for the remote peer as it will continue to ignore the 233 received MAC Move messages with lower sequence numbers. In such 234 cases, it is desirable to reset the sequence numbers, the reset R-bit 235 is set in the first MAC Move to notify the remote peer to reset the 236 send and receive sequence numbers. The R-bit must be cleared in 237 subsequent MAC Move messages after the acknowledgement is received. 239 3.2 Operation of Receiver 241 Each L2 logical switch identified by a VNI is associated with a 242 receive sequence number per remote NVE to keep track of the expected 243 sequence number of the MAC Move message. 245 Whenever a MAC Move message is received, and if the sequence number 246 on the message is greater than the value in the receive sequence 247 number of this remote NVE, the MAC addresses learned from the NVE 248 associated with the NVE identifier in the message are moved to be 249 associated with the new active NVE identifier, and the receive 250 sequence number of the remote NVE is updated with the received 251 sequence number. The receiver sends an ACK with the same sequence 252 number in the received message. 254 If the sequence number in the received message is smaller than or 255 equal to the value in the receive sequence number per remote NVE, the 256 MAC Move is not processed. However, an ACK with the received sequence 257 number MUST be sent as a response to stop the sender retransmission. 259 A MAC Move message with the R-bit set MUST be processed by resetting 260 the receive sequence number of the remote NVE, and Moving the MACs as 261 described above. The acknowledgement is sent with the R-bit cleared. 263 4. Security Considerations 265 This document does not introduce any additional security constraints. 267 5. IANA Considerations 269 IANA is requested to assign a new option class from the "Geneve 270 Option Class" registry for the Geneve MAC Move option. 272 Option Class Description 273 ------------ --------------------- 274 XXXX Geneve MAC Move 276 6 References 278 6.1 Normative References 280 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 6.2 Informative References 285 [Geneve] "Generic Network Virtualization Encapsulation", [I-D.ietf- 286 nvo3-geneve] 287 [RFC 7769] "MAC Address Withdrawal over Static PW", [RFC 7769] 289 Authors' Addresses 291 Sami Boutros 292 VMware 293 Email: boutross@vmware.com 295 Jerome Catrouillet 296 VMware 297 Email: jcatrouillet@vmware.com 299 Sri Mohana Singamsetty 300 Email: msingamsetty@vmware.com 302 Ankur Sharma 303 VMware 304 Email: ankursharma@vmware.com 306 Parag Jain 307 Cisco 308 Email: paragj@cisco.com