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