idnits 2.17.1 draft-worley-nvo3-geneve-misc-00.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. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 5, 2018) is 2212 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.mizrahi-ippm-compact-alternate-marking' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'ieee-ethertype-reg' is defined on line 556, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-fmm-nvo3-pm-alt-mark-01 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-06 == Outdated reference: A later version (-05) exists of draft-mizrahi-ippm-compact-alternate-marking-01 ** Obsolete normative reference: RFC 7042 (Obsoleted by RFC 9542) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 D. Worley 3 Internet-Draft Ariadne 4 Intended status: Informational April 5, 2018 5 Expires: October 7, 2018 7 Geneve Extensions 8 draft-worley-nvo3-geneve-misc-00 10 Abstract 12 TBD 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at https://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on October 7, 2018. 31 Copyright Notice 33 Copyright (c) 2018 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (https://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Protocol Numbers . . . . . . . . . . . . . . . . . . . . . . 4 50 2.1. Geneve over UDP . . . . . . . . . . . . . . . . . . . . . 4 51 2.2. Geneve over IP . . . . . . . . . . . . . . . . . . . . . 4 52 2.3. Geneve over Ethernet . . . . . . . . . . . . . . . . . . 4 53 3. Geneve Protocol Type Numbers . . . . . . . . . . . . . . . . 5 54 3.1. Ethernet over Geneve . . . . . . . . . . . . . . . . . . 5 55 3.2. IP over Geneve . . . . . . . . . . . . . . . . . . . . . 5 56 3.3. Layer 4 over Geneve . . . . . . . . . . . . . . . . . . . 5 57 3.3.1. No Payload . . . . . . . . . . . . . . . . . . . . . 5 58 3.3.2. Pseudoheaders for Checksums . . . . . . . . . . . . . 6 59 3.4. SNAP Ethertypes over Geneve . . . . . . . . . . . . . . . 6 60 4. Alternate Packet Marking . . . . . . . . . . . . . . . . . . 7 61 5. Short Header . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. TCAM Support . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Allocation of Flag Bits . . . . . . . . . . . . . . . . . . . 8 64 8. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8 65 8.1. Packet Spraying . . . . . . . . . . . . . . . . . . . . . 8 66 8.2. OAM Headers . . . . . . . . . . . . . . . . . . . . . . . 9 67 9. Revision History . . . . . . . . . . . . . . . . . . . . . . 11 68 9.1. TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 10.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 This document concerns expanding the Geneve encapsulation header to 78 the function of a generalized encapsulation. The current Geneve 79 proposal[I-D.ietf-nvo3-geneve] is highly extensible regarding the 80 information that can be carried in the Geneve header, but it 81 envisions that the encapsulated payload will be either Ethernet or a 82 layer 3 protocol and will be carried over UDP within an IPv4 or IPv6 83 packet: 85 +---------------+ 86 | Ethernet | 87 +---------------+ 88 | IP | 89 +---------------+ 90 | UDP | 91 +---------------+ 92 | Geneve | 93 +---------------+ 94 | Ethernet | 95 +---------------+ 96 | Layer 3 | 97 | ... | 98 +---------------+ 100 This document envisions that Geneve header may be used for other 101 functions. These include tunneling at different layers of the stack, 102 such as tunneling Ethernet over Ethernet: 104 +---------------+ 105 | Ethernet | 106 +---------------+ 107 | Geneve | 108 +---------------+ 109 | Ethernet | 110 +---------------+ 111 | Layer 3 | 112 | ... | 113 +---------------+ 115 or carrying additional information to be processed at various levels 116 of the protocol stack: 118 +---------------+ 119 | Ethernet | 120 +---------------+ 121 | IP | 122 +---------------+ 123 | Geneve | 124 +---------------+ 125 | UDP | 126 +---------------+ 127 | application | 128 | data ... | 129 +---------------+ 131 remarkably little extension is needed to allow Geneve to take on this 132 much-expanded role. 134 2. Protocol Numbers 136 The most important requirement for the concept of Geneve as a 137 generalized encapsulation technique is assigning suitable protocol 138 numbers so that Geneve can be demultiplexed at various layers of the 139 protocol stack.[number-assignments-msg] 141 2.1. Geneve over UDP 143 When Geneve is used over layer 4, UDP, then there needs to be an 144 assigned UDP destination port to specify that the UDP payload is 145 demultiplexed as Geneve. IANA has assigned 6081 as the port 146 number.[I-D.ietf-nvo3-geneve] 148 2.2. Geneve over IP 150 When Geneve is used over layer 3, IP, it needs a protocol/next header 151 value. Protocol values are only 8 bits, but only a bit over half of 152 the protocol values have been allocated in 30 years, so it seems that 153 there's not a lot of pressure on the number-space, and it is 154 reasonable to request a protocol number assignment for Geneve. 155 Currently, the next unused IP Protocol value is 156 143.[protocol-numbers] 158 2.3. Geneve over Ethernet 160 When Geneve is used over layer 2, Ethernet, it needs an Ethertype 161 assignment. An Ethertype assignment could be obtained from 162 IEEE,[ieee-ethertype-reg] but it might be more expedient to obtain a 163 SNAP Protocol Number from IANA.[RFC7042] Currently, the next unused 164 SNAP Protocol Number is 0x0009, yielding the five-octet SNAP 165 extension header 00-00-5E-00-09.[snap-protocol-numbers] The SNAP 166 extension header appears in the Ethernet frame after the primary 167 Ethernet header when the Ethertype in the Ethernet header is the OUI 168 Extended EtherType, 0x88B7. 170 [IEEE_802-2014] clause 9.2.4 notes 172 As discussed in 9.2.3, it is good protocol development practice to 173 use a protocol subtype, along with a protocol version identifier 174 in order to avoid having to allocate a new protocol identifier 175 when a protocol is revised or enhanced. Users of the OUI Extended 176 EtherType are, therefore, encouraged to include protocol subtype 177 and version information in the specification of the protocol data 178 for their protocols. 180 Geneve satisfies this desideratum through (1) using the first two 181 bits of the Geneve header as a version identifier, and (2) carrying 182 most of its data in an extensible set of options. 184 3. Geneve Protocol Type Numbers 186 The Geneve header contains a protocol type field which identifies the 187 protocol of the payload of the Geneve header, i.e., the overlying 188 protocol. The protocol type field is defined to be an Ethertype. To 189 allow the Geneve payload to be other than layer 3 protocols (with a 190 few layer 2 protocols specifiable through "encapsulated" Ethertypes), 191 encodings are needed for a larger space of protocol identifers. 193 3.1. Ethernet over Geneve 195 When layer 2 is used over Geneve, the protocol type is 0x6558 196 (encapsulated Ethernet). 198 3.2. IP over Geneve 200 When layer 3 is used over Geneve, the protocol type is 0800 (IPv4) or 201 86DD (IPv6). 203 3.3. Layer 4 over Geneve 205 When layer 4 is used over Geneve, Geneve must be extended, because 206 there's no defined way of representing an IP protocol/next header 207 value directly as an Ethertype, and few or no protocols that can be 208 represented as such a value have assigned Ethertypes. 210 One approach for carrying layer 4 protocols depends on the fact that 211 all Ethertypes must have values of 0x0600 or higher ([IEEE_802-2014] 212 clause 9.2.1). That is because Ethertypes are carried in a two-octet 213 field in the Ethernet header, and values of that field smaller than 214 0x0600 are defined to specify the length of the Ethernet frame, not 215 its Ethertype. This implies that values of the Geneve protocol type 216 field with a first octet of 0x00 to 0x05 are not actually allocated 217 at present and can be redefined for other uses. 219 This suggests extending the protocol type field so that if the first 220 octet is 0x00, then the second octet is an IP protocol number 221 describing the payload protocol. 223 3.3.1. No Payload 225 An additional case is when there is no payload, i.e., the Geneve 226 header contains all of the information content of the packet. In 227 this situation, we can take use the next-header value 59, which means 228 "no next header".[RFC8200] Given the encoding for IP protocol 229 numbers, "no next header" is encoded by a Geneve protocol type of 230 0x003B. 232 3.3.2. Pseudoheaders for Checksums 234 TBD 236 3.4. SNAP Ethertypes over Geneve 238 But things get messier if Geneve directly encapsulates a protocol 239 which has a SNAP protocol number, because Geneve only reserves two 240 octets for the protocol type field. Likely the best 241 solution[extended-msg] is allocate (1) the first octet of the 242 protocol type field is an indicator value, 0x02, (2) the second octet 243 of the protocol type field is the first octet of the OUI of the SNAP 244 protocol number, and (3) as the first four octets of the Geneve 245 payload, place the final two octets of the OUI and the two octets of 246 the protocol identifier: 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 |Ver| Opt Len |O|C| Rsvd. | 0x01 | OUI | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Virtual Network Identifier (VNI) | Reserved | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Options ... | 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | OUI | Protocol Identifier | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 +-+-+-+-+-+-+-+-+- 262 | Payload ... 263 +-+-+-+-+-+-+-+-+- 265 This solution allows the format of the Geneve header to remain 266 unchanged, and the payload of the inner protocol remains aligned on a 267 four-octet boundary. It does introduce an irregular word between the 268 Geneve header and the payload proper, but this is upward-compatible 269 with the current Geneve specification: a processor that does not 270 understand the SNAP payload convention sees an Ethertype starting 271 with 0x02 (which it does not recognize) and a payload that is four 272 octets longer than the actual payload (which it knows it does not 273 know how to process). 275 (The value 0x02 is chosen as the indicator because numerous 276 Ethertypes with high byte 0x01 are listed in the IEEE's registration 277 database for "Xerox (Experimental)", despite that they are not 278 acceptable as Ethertypes.) 280 4. Alternate Packet Marking 282 "Alternate packet marking" encompasses a number of methods of 283 inserting one or more "marking" bits in packets when they are 284 transmitted, and when they are received, measuring the arrival times 285 of packets with specific markings to determine flow statistics, 286 including delay and jitter.[I-D.fmm-nvo3-pm-alt-mark][I-D.mizrahi-ipp 287 m-compact-alternate-marking] 289 Alternate marking is mentioned here because even if compact marking 290 is used, one of the reserved flag bits needs to be allocated for 291 marking. 293 5. Short Header 295 For some applications, there may be no need for a Virtual Network 296 Identifier. It may be reasonable to allocate one of the header flag 297 bits to mean "short", in that the second word of the header is 298 suppressed. Thus, when S = 1, the format of the Geneve header is: 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |Ver| Opt Len |O|C|S| Rsvd. | Protocol Type | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Variable Length Options | 304 | ... | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 6. TCAM Support 309 My memory is that the question of "TCAM support" was raised a couple 310 of IETFs ago. I take that to mean the question of whether a Geneve 311 header can be classified as to whether it conforms to a particular 312 "profile" or not by using a ternary-content-addressed memory, that 313 is, by examining a fixed set of bits at fixed locations to see if 314 they have certain fixed values. If the profile in question is the 315 presence of a particular set of options with particular lengths, the 316 classification is possible using TCAM. 318 A problem arises if we want to support profiles that allow further 319 options beyond the specified set. It is straightforward to verify 320 that the required option class/type values appear in the expected 321 locations relative to the Geneve header. The problem is that there's 322 no way to verify that the apparent options are actually within the 323 Geneve header -- to do that would require that the Option Length 324 field is greater than or equal to a specified constant, and that test 325 can't be done via TCAM. 327 One solution is embed in the Geneve header fixed part, and each 328 option, a flag telling whether there is a further option in the 329 Geneve header.[tcam-msg] Then a Geneve header can be verified to have 330 at least N options (when N > 1) when the another-option flag is true 331 in the header fixed part and in the first N-1 options. 333 (Effectively, the another-option flags represent the number of 334 options in the Geneve header in uniary, and using TCAM it is possible 335 to compare a number to be greater than a constant if the number is 336 represented in unary.) 338 7. Allocation of Flag Bits 340 The Geneve format reserves eight bits in the first word for flag 341 bits. Accumulating all of these proposals, there are five allocation 342 flag bits: 344 O (existing) packet contains OAM information. The endpoint should 345 direct the packet into a control queue. 347 C (existing) critical option is present 349 M (new) traffic marking for measurementSection 4 351 A (new) (in the fixed part) there are one or more options, (in an 352 option) this are one or more options following this oneSection 6 354 S (new) short header - the second word of the fixed part is 355 absentSection 5 357 8. Applications 359 8.1. Packet Spraying 361 One application of these extensions is described in the draft 362 [I-D.xiang-nvo3-geneve-packet-spray] in section 5.3, in which it is 363 desirable to put the layer 4 header (TCP or UDP) directly after the 364 Geneve header (which carries the "Flow Group ID" and "Sequencing 365 Number" in an option). In these cases, the Geneve protocol type 366 field will be 0x0006 (for TCP) or 0x0011 (for UDP). 368 8.2. OAM Headers 370 Within this framework, an attractive application is implementing the 371 proposed OOAM header as a Geneve header. The current header 372 proposal[I-D.ooamdt-rtgwg-ooam-header] exhibits some of the 373 properties that Geneve was designed to avoid, in particular, 374 specification of various functions by means of a limited number of 375 flag bits in a fixed order. These limitations can be avoided by 376 reformatting the fields of the OOAM header as a Geneve header. 378 The OOAM header has three parts: a fixed part, the data blocks 379 specified by the Flags field, and an OOAM control message. 381 The (potentially) sixteen flags that indicate the data blocks can be 382 replaced by sixteen Geneve options, each of which carries as its data 383 the data block of the corresponding flag. This has the disadvantage 384 that if a number of flags would be specified in the current format, 385 the Geneve header would contain the same number of words to introduce 386 the data blocks. This can be compressed by allocating a group of 387 2^16 Geneve option class/type values, each of which encodes a subset 388 of the flags, and which has as option data the sequence of data 389 blocks for those flags: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Class |F|F F F F F F F F|C|F F F F F F F|R|R|R| Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Data blocks for the set flags | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 This approach does consume 2^16 of the available 2^23 option class/ 400 type values, but that is less than 1% of the available number space. 402 Using the S (short header) bit, the Geneve header is no longer than 403 the current OOAM header format: 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | V | Msg Type | Length | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Flags | Reserved | Next Prot | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 ~ OOAM data blocks ~ 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 vs. 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 |Ver| Opt Len |O|C|B| Rsvd. | Protocol Type | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Class |F|F F F F F F F F|C|F F F F F F F|R|R|R| Length | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 ~ Data blocks for the set flags ~ 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 The major limitation of using a Geneve header is that it is limited 424 to a 63 words (252 octets) of options. 426 The OOAM control message could be carried within a Geneve option, 427 although that would limit it to 31 words (124 octets). The option 428 specifies the control message type: 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | V | Msg Type | Length | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Flags | Reserved | Next Prot | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 ~ OOAM control message ~ 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 vs. 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 |Ver| Opt Len |O|C|B| Rsvd. | Protocol Type | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Option Class | Type |R|R|R| Length | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 ~ OOAM control message ~ 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 An alternative approach that allows longer OOAM control messages is 449 to place it after the Geneve header itself and before the Geneve 450 header's payload. The option for the OOAM control message would 451 contain only one word of data, carrying the message type and length: 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | V | Msg Type | Length | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Flags | Reserved | Next Prot | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 ~ OOAM control message ~ 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 vs. 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |Ver| Opt Len |O|C|B| Rsvd. | Protocol Type | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Option Class | Type |R|R|R| Length | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Msg Type | Length | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 ~ Further Geneve options ~ 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 ~ OOAM control message ~ 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 ~ Geneve payload ~ 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 In all of these forms, advantage can be taken of Geneve's more easily 478 generalized "next protocol" fieldSection 3 and the abililty to 479 allocate additional Geneve option class/type values for later 480 extensibility. 482 However, what does not change with this approach is the fundamental 483 work of defining the semantics of the OOAM facilities and control 484 messages. 486 9. Revision History 488 [Note to RFC Editor: Please remove this entire section upon 489 publication as an RFC.] 491 9.1. TBD 493 TBD 495 10. References 496 10.1. Normative References 498 [I-D.fmm-nvo3-pm-alt-mark] 499 Fioccola, G., Mirsky, G., and T. Mizrahi, "Performance 500 Measurement (PM) with Alternate Marking in Network 501 Virtualization Overlays (NVO3)", draft-fmm-nvo3-pm-alt- 502 mark-01 (work in progress), March 2018. 504 [I-D.ietf-nvo3-geneve] 505 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 506 Network Virtualization Encapsulation", draft-ietf- 507 nvo3-geneve-06 (work in progress), March 2018. 509 [I-D.mizrahi-ippm-compact-alternate-marking] 510 Mizrahi, T., Arad, C., Fioccola, G., Cociglio, M., Chen, 511 M., Zheng, L., and G. Mirsky, "Compact Alternate Marking 512 Methods for Passive and Hybrid Performance Monitoring", 513 draft-mizrahi-ippm-compact-alternate-marking-01 (work in 514 progress), March 2018. 516 [protocol-numbers] 517 Internet Assigned Numbers Authority, "Protocol Numbers", 518 October 2017, . 521 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 522 IETF Protocol and Documentation Usage for IEEE 802 523 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 524 October 2013, . 526 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 527 (IPv6) Specification", STD 86, RFC 8200, 528 DOI 10.17487/RFC8200, July 2017, 529 . 531 [snap-protocol-numbers] 532 Internet Assigned Numbers Authority, "SNAP Protocol 533 Numbers", June 2017, . 537 10.2. Informative References 539 [extended-msg] 540 Worley, D., "OUI Extended Ethertypes as next-protocol", 541 IETF NVO3 mailing list msg06235, August 2017, 542 . 545 [I-D.ooamdt-rtgwg-ooam-header] 546 Mirsky, G., Kumar, N., Kumar, D., Chen, M., Yizhou, L., 547 and D. Dolson, "OAM Header for use in Overlay Networks", 548 draft-ooamdt-rtgwg-ooam-header-04 (work in progress), 549 March 2018. 551 [I-D.xiang-nvo3-geneve-packet-spray] 552 Xiang, H., Yu, Y., Congdon, P., and J. Wang, "Packet 553 Spraying in Geneve Overlay Network", draft-xiang-nvo3- 554 geneve-packet-spray-00 (work in progress), March 2018. 556 [ieee-ethertype-reg] 557 IEEE Standards Association, "IEEE-SA - Registration 558 Authority Ethertype", January 2018, 559 . 562 [IEEE_802-2014] 563 IEEE Computer Society, "802 - IEEE Standard for Local and 564 Metropolitan Area Networks: Overview and Architecture", 565 June 2014, . 568 [number-assignments-msg] 569 Worley, D., "Number assignments", IETF NVO3 mailing 570 list msg06219, July 2017, . 573 [tcam-msg] 574 Worley, D., "TCAM compatibility for Geneve", IETF NVO3 575 mailing list msg06142, Jun 2017, . 578 Acknowledgments 580 Donald Eastlake suggested the use of a SNAP protocol number. 582 Author's Address 584 Dale R. Worley 585 Ariadne Internet Services 586 738 Main St. 587 Waltham, MA 02451 588 US 590 Email: worley@ariadne.com