idnits 2.17.1 draft-ietf-nvo3-vxlan-gpe-09.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 (December 5, 2019) is 1603 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-05) exists of draft-brockners-ippm-ioam-vxlan-gpe-03 Summary: 3 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 F. Maino, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational L. Kreeger, Ed. 5 Expires: June 7, 2020 Arrcus 6 U. Elzur, Ed. 7 Intel 8 December 5, 2019 10 Generic Protocol Extension for VXLAN 11 draft-ietf-nvo3-vxlan-gpe-09 13 Abstract 15 This draft describes extending Virtual eXtensible Local Area Network 16 (VXLAN), via changes to the VXLAN header, with four new capabilities: 17 support for multi-protocol encapsulation, support for operations, 18 administration and maintenance (OAM) signaling, support for ingress- 19 replicated BUM Traffic (i.e. Broadcast, Unknown unicast, or 20 Multicast), and explicit versioning. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 7, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. VXLAN Without Protocol Extension . . . . . . . . . . . . . . 3 64 3. Generic Protocol Extension for VXLAN (VXLAN GPE) . . . . . . 4 65 3.1. VXLAN GPE Header . . . . . . . . . . . . . . . . . . . . 4 66 3.2. Multi Protocol Support . . . . . . . . . . . . . . . . . 5 67 3.3. Replicated BUM Traffic . . . . . . . . . . . . . . . . . 7 68 3.4. OAM Support . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.5. Version Bits . . . . . . . . . . . . . . . . . . . . . . 7 70 4. Outer Encapsulations . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Inner VLAN Tag Handling . . . . . . . . . . . . . . . . . 11 72 4.2. Fragmentation Considerations . . . . . . . . . . . . . . 11 73 5. Implementation and Deployment Considerations . . . . . . . . 12 74 5.1. Applicability Statement . . . . . . . . . . . . . . . . . 12 75 5.2. Congestion Control Functionality . . . . . . . . . . . . 12 76 5.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 13 77 5.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 13 78 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15 79 6.1. VXLAN VTEP to VXLAN GPE VTEP . . . . . . . . . . . . . . 15 80 6.2. VXLAN GPE VTEP to VXLAN VTEP . . . . . . . . . . . . . . 15 81 6.3. VXLAN GPE UDP Ports . . . . . . . . . . . . . . . . . . . 15 82 6.4. VXLAN GPE and Encapsulated IP Header Fields . . . . . . . 15 83 7. VXLAN GPE Examples . . . . . . . . . . . . . . . . . . . . . 16 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 87 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 11.1. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 19 89 11.2. VXLAN GPE Next Protocol . . . . . . . . . . . . . . . . 19 90 11.3. VXLAN GPE Flag and Reserved Bits . . . . . . . . . . . . 19 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 93 12.2. Informative References . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Introduction 98 Virtual eXtensible Local Area Network VXLAN [RFC7348] defines an 99 encapsulation format that encapsulates Ethernet frames in an outer 100 UDP/IP transport. As data centers evolve, the need to carry other 101 protocols encapsulated in an IP packet is required, as well as the 102 need to provide increased visibility and diagnostic capabilities 103 within the overlay. The VXLAN header does not specify the protocol 104 being encapsulated and therefore is currently limited to 105 encapsulating only Ethernet frame payload, nor does it provide the 106 ability to define OAM protocols. In addition, [RFC6335] requires 107 that new transports not use transport layer port numbers to identify 108 tunnel payload, rather it encourages encapsulations to use their own 109 identifiers for this purpose. VXLAN GPE is intended to extend the 110 existing VXLAN protocol to provide protocol typing, OAM, and 111 versioning capabilities. 113 The Version and OAM bits are introduced in Section 3, and the choice 114 of location for these fields is driven by minimizing the impact on 115 existing deployed hardware. 117 In order to facilitate deployments of VXLAN GPE with hardware 118 currently deployed to support VXLAN, changes from legacy VXLAN have 119 been kept to a minimum. Section 6 provides a detailed discussion 120 about how VXLAN GPE addresses the requirement for backward 121 compatibility with VXLAN. 123 The capabilities of the VXLAN-GPE protocol can be extended by 124 defining next protocol "shim" headers that are used to implement new 125 data plane functions. For example, Group-Based Policy (GBP) or In- 126 situ Operations, Administration, and Maintenance (IOAM) metadata 127 functionalities can be added as specified in 128 [I-D.lemon-vxlan-lisp-gpe-gbp] and 129 [I-D.brockners-ippm-ioam-vxlan-gpe]. 131 2. VXLAN Without Protocol Extension 133 VXLAN provides a method of creating multi-tenant overlay networks by 134 encapsulating packets in IP/UDP along with a header containing a 135 network identifier which is used to isolate tenant traffic in each 136 overlay network from each other. This allows the overlay networks to 137 run over an existing IP network. 139 Through this encapsulation, VXLAN creates stateless tunnels between 140 VXLAN Tunnel End Points (VTEPs) which are responsible for adding/ 141 removing the IP/UDP/VXLAN headers and providing tenant traffic 142 isolation based on the VXLAN Network Identifier (VNI). Tenant 143 systems are unaware that their networking service is being provided 144 by an overlay. 146 When encapsulating packets, a VTEP must know the IP address of the 147 proper remote VTEP at the far end of the tunnel that can deliver the 148 inner packet to the Tenant System corresponding to the inner 149 destination address. The control plane used to distribute inner to 150 outer mappings is out of the scope of this document. 152 The VXLAN Network Identifier (VNI) provides scoping for the addresses 153 in the header of the encapsulated PDU. If the encapsulated packet is 154 an Ethernet frame, this means the Ethernet MAC addresses are only 155 unique within a given VNI and may overlap with MAC addresses within a 156 different VNI. If the encapsulated packet is an IP packet, this 157 means the IP addresses are only unique within that VNI. 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 |R|R|R|R|I|R|R|R| Reserved | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | VXLAN Network Identifier (VNI) | Reserved | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 1: VXLAN Header 169 3. Generic Protocol Extension for VXLAN (VXLAN GPE) 171 3.1. VXLAN GPE Header 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |R|R|Ver|I|P|B|O| Reserved |Next Protocol | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | VXLAN Network Identifier (VNI) | Reserved | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Figure 2: VXLAN GPE Header 183 Flags (8 bits): The first 8 bits of the header are the flag field. 184 The bits designated "R" above are reserved flags. These MUST be 185 set to zero on transmission and ignored on receipt. 187 Version (Ver): Indicates VXLAN GPE protocol version. The initial 188 version is 0. If a receiver does not support the version 189 indicated it MUST drop the packet. 191 Instance Bit (I bit): The I bit MUST be set to indicate a valid VNI. 193 Next Protocol Bit (P bit): The P bit is set to indicate that the 194 Next Protocol field is present. 196 BUM Traffic Bit (B bit): The B bit is set to indicate that this is 197 ingress-replicated BUM Traffic (ie, Broadcast, Unknown unicast, or 198 Multicast). 200 OAM Flag Bit (O bit): The O bit is set to indicate that the packet 201 is an OAM packet. 203 Next Protocol: This 8 bit field indicates the protocol header 204 immediately following the VXLAN GPE header. 206 VNI: This 24 bit field identifies the VXLAN overlay network the 207 inner packet belongs to. Inner packets belonging to different 208 VNIs cannot communicate with each other (unless explicitly allowed 209 by policy). 211 Reserved: Reserved fields MUST be set to zero on transmission and 212 ignored on receipt. 214 3.2. Multi Protocol Support 216 This draft defines the following two changes to the VXLAN header in 217 order to support multi-protocol encapsulation: 219 P Bit: Flag bit 5 is defined as the Next Protocol bit. The P bit 220 MUST be set to 1 to indicate the presence of the 8 bit next 221 protocol field. 223 When UDP dest port=4790, P = 0 the "Next Protocol" field must be 224 set to zero and the payload MUST be ETHERNET(L2) as defined by 225 [RFC7348]. 227 Flag bit 5 was chosen as the P bit because this flag bit is 228 currently reserved in VXLAN. 230 Next Protocol Field: The lower 8 bits of the first word are used to 231 carry a next protocol. This next protocol field contains the 232 protocol of the encapsulated payload packet. A new protocol 233 registry will be requested from IANA, see section 10.2. 235 This draft defines the following Next Protocol values: 237 0x01 : IPv4 239 0x02 : IPv6 241 0x03 : Ethernet 243 0x04 : Network Service Header [RFC8300] 245 0x05 to 0x7F: Unassigned. 247 0x80 to 0xFF: Unassigned (shim headers). 249 Next protocol values from Ox80 to 0xFF are assigned to protocols 250 encoded as generic "shim" headers. All shim protocols MUST use the 251 header structure in Figure 3, which includes a Type, a Lenght, and a 252 Next Protocol field. When a shim header is used with other protocols 253 identified by next protocol values from 0x0 to 0x7F, the shim header 254 MUST come before the further protocol, and the next header of the 255 shim will indicate which protocol follows the shim header. 257 Shim headers can be used to incrementally deploy new GPE features 258 without updating the implementation of each transit node between two 259 tunnel endpoints, and without punting the packet with shim headers of 260 unknown type to the 'slow' path. Transit nodes that are not aware of 261 a given shim header type MUST ignore that shim header and proceed to 262 parse the next protocol. 264 VTEP implementations can keep the processing of known shim headers in 265 the 'fast' path (typically an ASIC), while punting the processing of 266 the remaining new GPE features to the 'slow' path. 268 Shim protocols MUST have the first 32 bits defined as: 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Type | Length | Reserved | Next Protocol | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | 276 ~ Protocol Specific Fields ~ 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 3: Shim Header 282 Where: 284 Type: This field MAY be used to identify different messages of this 285 protocol. 287 Length: The length, in in 4-octet units, of this protocol message 288 not including the first 4 octects. 290 Reserved: The use of this field is reserved to the protocol defined 291 in this message. 293 Next Protocol Field: This next protocol field contains the protocol 294 of the encapsulated payload. The protocol registry will be 295 requested from IANA as per section 10.2. 297 3.3. Replicated BUM Traffic 299 Flag bit 6 is defined as the B bit. When the B bit is set to 1, the 300 packet is marked as an an ingress-replicated BUM Traffic (i.e. 301 Broadcast, Unknown unicast, or Multicast) to help egress VTEP to 302 differentiate between known and unknown unicast. The details of 303 using the B bit are out of scope for this document, but please see 304 [RFC8365] for an example in the EVPN context. As with the P-bit, bit 305 6 is currently a reserved flag in VXLAN. 307 3.4. OAM Support 309 Flag bit 7 is defined as the O bit. When the O bit is set to 1, the 310 packet is an OAM packet and OAM processing MUST occur. Other header 311 fields including Next Protocol MUST adhere to the definitions in 312 Section 3. The OAM protocol details are out of scope for this 313 document. As with the P-bit, bit 7 is currently a reserved flag in 314 VXLAN. 316 3.5. Version Bits 318 VXLAN GPE bits 2 and 3 are defined as version bits. These bits are 319 reserved in VXLAN. The version field is used to ensure backward 320 compatibility going forward with future VXLAN GPE updates. 322 The initial version for VXLAN GPE is 0. 324 4. Outer Encapsulations 326 In addition to the VXLAN GPE header, the packet is further 327 encapsulated in UDP and IP. Data centers based on Ethernet, will 328 then send this IP packet over Ethernet. 330 Outer UDP Header: 332 Destination UDP Port: IANA has assigned the value 4790 for the VXLAN 333 GPE UDP port. This well-known destination port is used when sending 334 VXLAN GPE encapsulated packets. 336 Source UDP Port: The source UDP port is used as entropy for devices 337 forwarding encapsulated packets across the underlay (ECMP for IP 338 routers, or load splitting for link aggregation by bridges). Tenant 339 traffic flows should all use the same source UDP port to lower the 340 chances of packet reordering by the underlay for a given flow. It is 341 recommended for VTEPs to generate this port number using a hash of 342 the inner packet headers. Implementations MAY use the entire 16 bit 343 source UDP port for entropy. 345 UDP Checksum: see Section 5.3 for considerations related to UDP 346 Checksum processing. 348 Outer IP Header: 350 This is the header used by the underlay network to deliver packets 351 between VTEPs. The destination IP address can be a unicast or a 352 multicast IP address. The source IP address must be the source VTEP 353 IP address which can be used to return tenant packets to the tenant 354 system source address within the inner packet header. 356 When the outer IP header is IPv4, VTEPs MUST set the DF bit. 358 Outer Ethernet Header: 360 Most data centers networks are built on Ethernet. Assuming the outer 361 IP packet is being sent across Ethernet, there will be an Ethernet 362 header used to deliver the IP packet to the next hop, which could be 363 the destination VTEP or be a router used to forward the IP packet 364 towards the destination VTEP. If VLANs are in use within the data 365 center, then this Ethernet header would also contain a VLAN tag. 367 The following figures show the entire stack of protocol headers that 368 would be seen on an Ethernet link carrying encapsulated packets from 369 a VTEP across the underlay network for both IPv4 and IPv6 based 370 underlay networks. 372 0 1 2 3 373 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 375 Outer Ethernet Header: 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Outer Destination MAC Address | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Outer Destination MAC Address | Outer Source MAC Address | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Outer Source MAC Address | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Ethertype = 0x0800 | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Outer IPv4 Header: 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 |Version| IHL |Type of Service| Total Length | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Identification |Flags| Fragment Offset | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Time to Live |Protocl=17(UDP)| Header Checksum | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Outer Source IPv4 Address | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Outer Destination IPv4 Address | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Outer UDP Header: 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Source Port | Dest Port = 4790 | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | UDP Length | UDP Checksum | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 VXLAN GPE Header: 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | VXLAN Network Identifier (VNI) | Reserved | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Payload: 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Depends on VXLAN GPE Next Protocol field above. | 418 | Note that if the payload is Ethernet, then the original | 419 | Ethernet Frame's FCS is not included. | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Frame Check Sequence: 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Figure 4: Outer Headers for VXLAN GPE over IPv4 428 0 1 2 3 429 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 431 Outer Ethernet Header: 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Outer Destination MAC Address | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Outer Destination MAC Address | Outer Source MAC Address | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Outer Source MAC Address | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Ethertype = 0x86DD | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Outer IPv6 Header: 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 |Version| Traffic Class | Flow Label | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | | 451 + + 452 | | 453 + Outer Source IPv6 Address + 454 | | 455 + + 456 | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | | 459 + + 460 | | 461 + Outer Destination IPv6 Address + 462 | | 463 + + 464 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Outer UDP Header: 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Source Port | Dest Port = 4790 | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | UDP Length | UDP Checksum | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 VXLAN GPE Header: 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | VXLAN Network Identifier (VNI) | Reserved | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Payload: 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Depends on VXLAN GPE Next Protocol field above. | 484 | Note that if the payload is Ethernet, then the original | 485 | Ethernet Frame's FCS is not included. | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Frame Check Sequence: 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 Figure 5: Outer Headers for VXLAN GPE over IPv6 495 4.1. Inner VLAN Tag Handling 497 If the inner packet (as indicated by the VXLAN GPE Next Protocol 498 field) is an Ethernet frame, it is recommended that it does not 499 contain a VLAN tag. In the most common scenarios, the tenant VLAN 500 tag is translated into a VXLAN Network Identifier. In these 501 scenarios, VTEPs should never send an inner Ethernet frame with a 502 VLAN tag, and a VTEP performing decapsulation should discard any 503 inner frames received with a VLAN tag. However, if the VTEPs are 504 specifically configured to support it for a specific VXLAN Network 505 Identifier, a VTEP may support transparent transport of the inner 506 VLAN tag between all tenant systems on that VNI. The VTEP never 507 looks at the value of the inner VLAN tag, but simply passes it across 508 the underlay. 510 4.2. Fragmentation Considerations 512 VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and when 513 the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer 514 IPv4 header. It is recommended that the underlay network be 515 configured to carry an MTU at least large enough to accommodate the 516 added encapsulation headers. It is recommended that VTEPs perform 517 Path MTU discovery [RFC1191] [RFC1981] to determine if the underlay 518 network can carry the encapsulated payload packet. 520 5. Implementation and Deployment Considerations 522 5.1. Applicability Statement 524 VXLAN-GPE conforms, as an UDP-based encapsulation protocol, to the 525 UDP usage guidelines as specified in [RFC8085]. The applicability of 526 these guidelines are dependent on the underlay IP network and the 527 nature of the encapsulated payload. 529 [RFC8085] outlines two applicability scenarios for UDP applications, 530 1) general Internet and 2) controlled environment. The controlled 531 environment means a single administrative domain or adjacent set of 532 cooperating domains. A network in a controlled environment can be 533 managed to operate under certain conditions whereas in general 534 Internet this cannot be done. Hence requirements for a tunnel 535 protocol operating under a controlled environment can be less 536 restrictive than the requirements of general internet. 538 VXLAN-GPE is intended to be deployed in a data center network 539 environment operated by a single operator or adjacent set of 540 cooperating network operators that fits with the definition of 541 controlled environments in [RFC8085]. 543 For the purpose of this document, a traffic-managed controlled 544 environment (TMCE), outlined in [RFC8086], is defined as an IP 545 network that is traffic-engineered and/or otherwise managed (e.g., 546 via use of traffic rate limiters) to avoid congestion. Significant 547 portions of text in this Section are based on [RFC8086]. 549 It is the responsibility of the network operators to ensure that the 550 guidelines/requirements in this section are followed as applicable to 551 their VXLAN-GPE deployments 553 5.2. Congestion Control Functionality 555 VXLAN-GPE does not natively provide congestion control functionality 556 and relies on the payload protocol traffic for congestion control. 557 As such VXLAN-GPE MUST be used with congestion controlled traffic or 558 within a network that is traffic managed to avoid congestion (TMCE). 559 An operator of a traffic managed network (TMCE) may avoid congestion 560 by careful provisioning of their networks, rate-limiting of user data 561 traffic and traffic engineering according to path capacity. 563 5.3. UDP Checksum 565 In order to provide integrity of VXLAN-GPE headers and payload, for 566 example to avoid mis-delivery of payload to different tenant systems 567 in case of data corruption, outer UDP checksum SHOULD be used with 568 VXLAN-GPE when transported over IPv4. The UDP checksum provides a 569 statistical guarantee that a payload was not corrupted in transit. 570 These integrity checks are not strong from a coding or cryptographic 571 perspective and are not designed to detect physical-layer errors or 572 malicious modification of the datagram (see Section 3.4 of 573 [RFC8085]). In deployments where such a risk exists, an operator 574 SHOULD use additional data integrity mechanisms such as offered by 575 IPSec. 577 An operator MAY choose to disable UDP checksum and use zero checksum 578 if VXLAN-GPE packet integrity is provided by other data integrity 579 mechanisms such as IPsec or additional checksums or if one of the 580 conditions in Section 5.3.1 a, b, c are met. 582 By default, UDP checksum MUST be used when VXLAN-GPE is transported 583 over IPv6. A tunnel endpoint MAY be configured for use with zero UDP 584 checksum if additional requirements in Section 5.3.1 are met. 586 5.3.1. UDP Zero Checksum Handling with IPv6 588 When VXLAN-GPE is used over IPv6, UDP checksum is used to protect 589 IPv6 headers, UDP headers and VXLAN-GPE headers and payload from 590 potential data corruption. As such by default VXLAN-GPE MUST use UDP 591 checksum when transported over IPv6. An operator MAY choose to 592 configure to operate with zero UDP checksum if operating in a traffic 593 managed controlled environment as stated in Section 5.1 if one of the 594 following conditions are met: 596 a. It is known that the packet corruption is exceptionally unlikely 597 (perhaps based on knowledge of equipment types in their underlay 598 network) and the operator is willing to take a risk of undetected 599 packet corruption 601 b. It is judged through observational measurements (perhaps through 602 historic or current traffic flows that use non zero checksum) 603 that the level of packet corruption is tolerably low and where 604 the operator is willing to take the risk of undetected corruption 606 c. VXLAN-GPE payload is carrying applications that are tolerant of 607 misdelivered or corrupted packets (perhaps through higher layer 608 checksum validation and/or reliability through retransmission) 610 In addition VXLAN-GPE tunnel implementations using Zero UDP checksum 611 MUST meet the following requirements: 613 1. Use of UDP checksum over IPv6 MUST be the default configuration 614 for all VXLAN-GPE tunnels 616 2. If VXLAN-GPE is used with zero UDP checksum over IPv6 then such 617 VTEP implementation MUST meet all the requirements specified in 618 section 4 of [RFC6936] and requirements 1 as specified in section 619 5 of [RFC6936] 621 3. The VTEP that decapsulates the packet SHOULD check the source and 622 destination IPv6 addresses are valid for the VXLAN-GPE tunnel 623 that is configured to receive Zero UDP checksum and discard other 624 packets for which such check fails 626 4. The VTEP that encapsulates the packet MAY use different IPv6 627 source addresses for each VXLAN-GPE tunnel that uses Zero UDP 628 checksum mode in order to strengthen the decapsulator's check of 629 the IPv6 source address (i.e the same IPv6 source address is not 630 to be used with more than one IPv6 destination address, 631 irrespective of whether that destination address is a unicast or 632 multicast address). When this is not possible, it is RECOMMENDED 633 to use each source address for as few VXLAN-GPE tunnels that use 634 zero UDP checksum as is feasible 636 5. Measures SHOULD be taken to prevent VXLAN-GPE traffic over IPv6 637 with zero UDP checksum from escaping into the general Internet. 638 Examples of such measures include employing packet filters at the 639 gateways or edge of a VXLAN-GPE network, and/or keeping logical 640 or physical separation of VXLAN network from networks carrying 641 General Internet 643 The above requirements do not change either the requirements 644 specified in [RFC2460] as modified by [RFC6935] or the requirements 645 specified in [RFC6936]. 647 The requirement to check the source IPv6 address in addition to the 648 destination IPv6 address, plus the recommendation against reuse of 649 source IPv6 addresses among VXLAN-GPE tunnels collectively provide 650 some mitigation for the absence of UDP checksum coverage of the IPv6 651 header. A traffic-managed controlled environment that satisfies at 652 least one of three conditions listed at the beginning of this section 653 provides additional assurance. 655 6. Backward Compatibility 657 6.1. VXLAN VTEP to VXLAN GPE VTEP 659 A VXLAN VTEP conforms to VXLAN frame format and uses UDP destination 660 port 4789 when sending traffic to VXLAN GPE VTEP. As per VXLAN, 661 reserved bits 5 and 7, VXLAN GPE P and O-bits respectively must be 662 set to zero. The remaining reserved bits must be zero, including the 663 VXLAN GPE version field, bits 2 and 3. The encapsulated payload MUST 664 be Ethernet. 666 6.2. VXLAN GPE VTEP to VXLAN VTEP 668 A VXLAN GPE VTEP MUST NOT encapsulate non-Ethernet frames to a VXLAN 669 VTEP. When encapsulating Ethernet frames to a VXLAN VTEP, the VXLAN 670 GPE VTEP MUST conform to VXLAN frame format and hence will set the P 671 bit to 0, the Next Protocol to 0 and use UDP destination port 4789. 672 A VXLAN GPE VTEP MUST also set O = 0 and Ver = 0 when encapsulating 673 Ethernet frames to VXLAN VTEP. The receiving VXLAN VTEP will treat 674 this packet as a VXLAN packet. 676 A method for determining the capabilities of a VXLAN VTEP (GPE or 677 non-GPE) is out of the scope of this draft. 679 6.3. VXLAN GPE UDP Ports 681 VXLAN GPE uses a IANA assigned UDP destination port, 4790, when 682 sending traffic to VXLAN GPE VTEPs. 684 6.4. VXLAN GPE and Encapsulated IP Header Fields 686 When encapsulating IP (including over Ethernet) packets [RFC2983] 687 provides guidance for mapping DSCP between inner and outer IP 688 headers. The Pipe model typically fits better Network 689 virtualization. The DSCP value on the tunnel header is set based on 690 a policy (which may be a fixed value, one based on the inner traffic 691 class, or some other mechanism for grouping traffic). Some aspects 692 of the Uniform model (which treats the inner and outer DSCP value as 693 a single field by copying on ingress and egress) may also apply, such 694 as the ability to remark the inner header on tunnel egress based on 695 transit marking. However, the Uniform model is not conceptually 696 consistent with network virtualization, which seeks to provide strong 697 isolation between encapsulated traffic and the physical network. 699 [RFC6040] describes the mechanism for exposing ECN capabilities on IP 700 tunnels and propagating congestion markers to the inner packets. 701 This behavior MUST be followed for IP packets encapsulated in VXLAN- 702 GPE. 704 Though Uniform or Pipe models could be used for TTL (or Hop Limit in 705 case of IPv6) handling when tunneling IP packets, Pipe model is more 706 aligned with network virtualization. [RFC2003] provides guidance on 707 handling TTL between inner IP header and outer IP tunnels; this model 708 is more aligned with the Pipe model and is recommended for use with 709 VXLAN-GPE for network virtualization applications. 711 7. VXLAN GPE Examples 713 This section provides three examples of protocols encapsulated using 714 the Generic Protocol Extension for VXLAN described in this document. 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 |R|R|0|0|I|1|R|0| Reserved | NP = IPv4 | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | VXLAN Network Identifier (VNI) | Reserved | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Original IPv4 Packet | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 Figure 6: IPv4 and VXLAN GPE 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 |R|R|0|0|I|1|R|0| Reserved | NP = IPv6 | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | VXLAN Network Identifier (VNI) | Reserved | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Original IPv6 Packet | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 Figure 7: IPv6 and VXLAN GPE 740 0 1 2 3 741 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 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 |R|R|0|0|I|1|R|0| Reserved |NP = Ethernet | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | VXLAN Network Identifier (VNI) | Reserved | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Original Ethernet Frame | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 Figure 8: Ethernet and VXLAN GPE 752 8. Security Considerations 754 VXLAN-GPE encapsulation does not affect security for the payload 755 protocol. The security considerations for VXLAN applies to VXLAN- 756 GPE, see [RFC7348]. 758 When crossing an untrusted link, such as the public Internet, IPsec 759 [RFC4301] may be used to provide authentication and/or encryption of 760 the IP packets formed as part of VXLAN-GPE encapsulation. 762 Operators have to make an assessment based on their network 763 environment and determine the risks that are applicable to their 764 specific environment and use appropriate mitigation approaches as 765 applicable. 767 9. Contributors 768 Paul Quinn 769 Cisco Systems 770 paulq@cisco.com 772 Rajeev Manur 773 Broadcom 774 rmanur@broadcom.com 776 Michael Smith 777 Cisco Systems 778 michsmit@cisco.com 780 Darrel Lewis 781 Cisco Systems 782 darlewis@cisco.com 784 Puneet Agarwal 785 Innovium, Inc 786 puneet@acm.org 788 Lucy Yong 789 Huawei USA 790 lucy.yong@huawei.com 792 Xiaohu Xu 793 Huawei Technologies 794 xuxiaohu@huawei.com 796 Pankaj Garg 797 Microsoft 798 pankajg@microsoft.com 800 David Melman 801 Marvell 802 davidme@marvell.com 804 Jennifer Lemon 805 Broadcom Limited 806 jennifer.lemon@broadcom.com 808 10. Acknowledgments 810 A special thank you goes to Dino Farinacci for his guidance and 811 detailed review. 813 11. IANA Considerations 815 11.1. UDP Port 817 UDP 4790 port has been assigned by IANA for VXLAN GPE. 819 11.2. VXLAN GPE Next Protocol 821 IANA is requested to set up a registry of "Next Protocol". These are 822 8-bit values. Next Protocol values in the table below are defined in 823 this draft. New values are assigned via Standards Action [RFC5226]. 825 +---------------+---------------------------+---------------+ 826 | Next Protocol | Description | Reference | 827 +---------------+---------------------------+---------------+ 828 | 0x0 | Reserved | This Document | 829 | 0x1 | IPv4 | This Document | 830 | 0x2 | IPv6 | This Document | 831 | 0x3 | Ethernet | This Document | 832 | 0x4 | NSH | This Document | 833 | 0x05..0x7F | Unassigned | | 834 | 0x80..0xFF | Unassigned (shim headers) | | 835 +---------------+---------------------------+---------------+ 837 11.3. VXLAN GPE Flag and Reserved Bits 839 There are ten flag bits at the beginning of the VXLAN GPE header, 840 followed by 16 reserved bits and an 8-bit reserved field at the end 841 of the header. New bits are assigned via Standards Action [RFC5226]. 843 Bits 0-1 - Reserve6 845 Bits 2-3 - Version 847 Bit 4 - Instance ID (I bit) 849 Bit 5 - Next Protocol (P bit) 851 Bit 6 - Reserved 853 Bit 7 - OAM (O bit) 855 Bit 8-23 - Reserved 857 Bits 24-31 in the 2nd Word -- Reserved 859 Reserved bits/fields MUST be set to 0 by the sender and ignored by 860 the receiver. 862 12. References 864 12.1. Normative References 866 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 867 DOI 10.17487/RFC1191, November 1990, 868 . 870 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 871 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 872 1996, . 874 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 875 DOI 10.17487/RFC2003, October 1996, 876 . 878 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 879 Requirement Levels", BCP 14, RFC 2119, 880 DOI 10.17487/RFC2119, March 1997, 881 . 883 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 884 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 885 December 1998, . 887 [RFC2983] Black, D., "Differentiated Services and Tunnels", 888 RFC 2983, DOI 10.17487/RFC2983, October 2000, 889 . 891 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 892 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 893 December 2005, . 895 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 896 IANA Considerations Section in RFCs", RFC 5226, 897 DOI 10.17487/RFC5226, May 2008, 898 . 900 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 901 Notification", RFC 6040, DOI 10.17487/RFC6040, November 902 2010, . 904 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 905 Cheshire, "Internet Assigned Numbers Authority (IANA) 906 Procedures for the Management of the Service Name and 907 Transport Protocol Port Number Registry", BCP 165, 908 RFC 6335, DOI 10.17487/RFC6335, August 2011, 909 . 911 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 912 UDP Checksums for Tunneled Packets", RFC 6935, 913 DOI 10.17487/RFC6935, April 2013, 914 . 916 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 917 for the Use of IPv6 UDP Datagrams with Zero Checksums", 918 RFC 6936, DOI 10.17487/RFC6936, April 2013, 919 . 921 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 922 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 923 eXtensible Local Area Network (VXLAN): A Framework for 924 Overlaying Virtualized Layer 2 Networks over Layer 3 925 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 926 . 928 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 929 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 930 March 2017, . 932 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 933 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 934 March 2017, . 936 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 937 "Network Service Header (NSH)", RFC 8300, 938 DOI 10.17487/RFC8300, January 2018, 939 . 941 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 942 Uttaro, J., and W. Henderickx, "A Network Virtualization 943 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 944 DOI 10.17487/RFC8365, March 2018, 945 . 947 12.2. Informative References 949 [I-D.brockners-ippm-ioam-vxlan-gpe] 950 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 951 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., 952 Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE 953 Encapsulation for In-situ OAM Data", draft-brockners-ippm- 954 ioam-vxlan-gpe-03 (work in progress), November 2019. 956 [I-D.lemon-vxlan-lisp-gpe-gbp] 957 Lemon, J., Maino, F., Smith, M., and A. Isaac, "Group 958 Policy Encoding with VXLAN-GPE and LISP-GPE", draft-lemon- 959 vxlan-lisp-gpe-gbp-02 (work in progress), April 2019. 961 Authors' Addresses 963 Fabio Maino (Editor) 964 Cisco Systems 966 Email: fmaino@cisco.com 968 Larry Kreeger (editor) 969 Arrcus 971 Email: lkreeger@gmail.com 973 Uri Elzur (editor) 974 Intel 976 Email: uri.elzur@intel.com