idnits 2.17.1 draft-brockners-ioam-vxlan-gpe-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 : ---------------------------------------------------------------------------- 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 (October 30, 2017) is 2360 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) -- Looks like a reference, but probably isn't: '0' on line 210 -- Looks like a reference, but probably isn't: '1' on line 214 == Unused Reference: 'ETYPES' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC2784' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'RFC3232' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'RFC7665' is defined on line 535, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ETYPES' == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-00 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-04 ** Downref: Normative reference to an Informational draft: draft-ietf-nvo3-vxlan-gpe (ref. 'I-D.ietf-nvo3-vxlan-gpe') ** Downref: Normative reference to an Informational RFC: RFC 3232 == Outdated reference: A later version (-05) exists of draft-brockners-proof-of-transit-03 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Brockners 3 Internet-Draft S. Bhandari 4 Intended status: Standards Track V. Govindan 5 Expires: May 3, 2018 C. Pignataro 6 Cisco 7 H. Gredler 8 RtBrick Inc. 9 J. Leddy 10 Comcast 11 S. Youell 12 JMPC 13 T. Mizrahi 14 Marvell 15 D. Mozes 16 Mellanox Technologies Ltd. 17 P. Lapukhov 18 Facebook 19 R. Chang 20 Barefoot Networks 21 October 30, 2017 23 VXLAN-GPE Encapsulation for In-situ OAM Data 24 draft-brockners-ioam-vxlan-gpe-00 26 Abstract 28 In-situ Operations, Administration, and Maintenance (IOAM) records 29 operational and telemetry information in the packet while the packet 30 traverses a path between two points in the network. This document 31 outlines how IOAM data fields are encapsulated in VXLAN-GPE. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 3, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 70 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 71 3. IOAM Data Field Encapsulation in VXLAN-GPE . . . . . . . . . 3 72 3.1. IOAM Trace Data in VXLAN-GPE . . . . . . . . . . . . . . 3 73 3.2. IOAM POT Data in VXLAN-GPE . . . . . . . . . . . . . . . 7 74 3.3. IOAM Edge-to-Edge Data in VXLAN-GPE . . . . . . . . . . . 8 75 4. Discussion of the encapsulation approach . . . . . . . . . . 9 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 8.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 In-situ OAM (IOAM) records OAM information within the packet while 87 the packet traverses a particular network domain. The term "in-situ" 88 refers to the fact that the IOAM data fields are added to the data 89 packets rather than being sent within packets specifically dedicated 90 to OAM. This document defines how IOAM data fields are transported 91 as part of the VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] encapsulation. 92 The IOAM data fields are defined in [I-D.ietf-ippm-ioam-data]. An 93 implementation of IOAM which leverages VXLAN-GPE to carry the IOAM 94 data is available from the FD.io open source software project 95 [FD.io]. 97 2. Conventions 99 2.1. Requirement Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2.2. Abbreviations 107 Abbreviations used in this document: 109 IOAM: In-situ Operations, Administration, and Maintenance 111 MTU: Maximum Transmit Unit 113 OAM: Operations, Administration, and Maintenance 115 POT: Proof of Transit 117 SFC: Service Function Chain 119 VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol 120 Extension 122 3. IOAM Data Field Encapsulation in VXLAN-GPE 124 For encapsulating IOAM data fields into VXLAN-GPE 125 [I-D.ietf-nvo3-vxlan-gpe] the different IOAM data fields are added as 126 options within new IOAM protocol headers in VXLAN-GPE. In an 127 administrative domain where IOAM is used, insertion of the IOAM 128 protocol header(s) in VXLAN GPE is enabled at the VXLAN-GPE tunnel 129 endpoints which also serve as IOAM encapsulating/decapsulating nodes 130 by means of configuration. The VXLAN-GPE header is defined in 131 [I-D.ietf-nvo3-vxlan-gpe]. IOAM specific fields for VXLAN-GPE are 132 defined in this document. 134 3.1. IOAM Trace Data in VXLAN-GPE 136 IOAM tracing data represents data that is inserted at nodes that a 137 packet traverses. To allow for optimal implementations in both 138 software as well as hardware forwarders, two different ways to 139 encapsulate IOAM data are defined: "Pre-allocated" and "Incremental". 140 See [I-D.ietf-ippm-ioam-data] for details on IOAM tracing and the 141 pre-allocated and incremental IOAM trace options. 143 The packet formats of the pre-allocated IOAM trace and incremental 144 IOAM trace when encapsulated in VXLAN-GPE are defined as below. 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Outer Ethernet Header | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Outer IP Header | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Outer UDP Header | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 155 |R|R|Ver|I|P|R|O| Reserved |NP=IOAM_Trace | | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE 157 | Virtual Network Identifier (VNI) | Reserved | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 159 | Type | IOAM HDR len| Reserved | Next Protocol | | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IOAM 161 | IOAM-Trace-Type |NodeLen| Flags | Octets-left | Trace 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 163 | | | 164 | node data list [0] | IOAM 165 | | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D 167 | | a 168 | node data list [1] | t 169 | | a 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 ~ ... ~ S 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p 173 | | a 174 | node data list [n-1] | c 175 | | e 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 177 | | | 178 | node data list [n] | | 179 | | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<--+ 181 | | 182 | | 183 | Payload + Padding (L2/L3/ESP/...) | 184 | | 185 | | 186 | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Pre-allocated Trace Option Data MUST be 4-octet aligned. 190 Figure 1: IOAM Pre-allocated Trace Option Format over VXLAN-GPE 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Outer Ethernet Header | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Outer IP Header | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Outer UDP Header | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 201 |R|R|Ver|I|P|R|O| Reserved | NP=IOAM_Trace | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE 203 | Virtual Network Identifier (VNI) | Reserved | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 205 | Type | IOAM HDR len| Reserved | Next Protocol | | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IOAM 207 | IOAM-Trace-Type |NodeLen| Flags | Max Length | Trace 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 209 | | | 210 | node data list [0] | IOAM 211 | | | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D 213 | | a 214 | node data list [1] | t 215 | | a 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 ~ ... ~ S 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p 219 | | a 220 | node data list [n-1] | c 221 | | e 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 223 | | | 224 | node data list [n] | | 225 | | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<--+ 227 | | 228 | | 229 | Payload + Padding (L2/L3/ESP/...) | 230 | | 231 | | 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 IOAM Incremental Trace Option Data MUST be 4-octet aligned. 236 Figure 2: IOAM Incremental Trace Option Format over VXLAN-GPE 238 The IOAM Trace header consists of 8 octets, as illustrated in 239 Figure 1 and Figure 2. The format of the first 4 octets (Figure 3) 240 is specific to VXLAN-GPE, and is defined in this document. The 241 format of the next 4 octets (trace option header) is defined in 242 [I-D.ietf-ippm-ioam-data], and is described here for the sake of 243 clarity. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | IOAM HDR len| Reserved | Next Protocol | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Figure 3: Trace Shim Header for VXLAN-GPE 253 The fields of the trace shim header are as follows: 255 Type: 8-bit unsigned integer defining IOAM header type 256 IOAM_TRACE_Preallocated or IOAM_Trace_Incremental are defined 257 here. 259 IOAM HDR len: 8-bit unsigned integer. Length of the IOAM HDR in 260 4-octet units. 262 Reserved: 8-bit reserved field MUST be set to zero. 264 Next Protocol: 8-bit unsigned integer that determines the type of 265 header following IOAM protocol. The value is from the IANA 266 registry setup for VXLAN GPE Next Protocol defined in 267 [I-D.ietf-nvo3-vxlan-gpe]. 269 The fields of the trace option header [I-D.ietf-ippm-ioam-data] are 270 as follows: 272 IOAM-Trace-Type: 16-bit identifier of IOAM Trace Type as defined in 273 [I-D.ietf-ippm-ioam-data] IOAM-Trace-Types. 275 Node Data Length: 4-bit unsigned integer as defined in 276 [I-D.ietf-ippm-ioam-data]. 278 Flags: 5-bit field as defined in [I-D.ietf-ippm-ioam-data]. 280 Octets-left: 7-bit unsigned integer as defined in 281 [I-D.ietf-ippm-ioam-data]. 283 Maximum-length: 7-bit unsigned integer as defined in 284 [I-D.ietf-ippm-ioam-data]. 286 Node data List [n]: Variable-length field as defined in 287 [I-D.ietf-ippm-ioam-data]. 289 3.2. IOAM POT Data in VXLAN-GPE 291 IOAM proof of transit (POT, see also 292 [I-D.brockners-proof-of-transit]) offers a means to verify that a 293 packet has traversed a defined set of nodes. IOAM POT data fields 294 are encapsulated in VXLAN-GPE using a dedicated VXLAN-GPE protocol 295 header: 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Outer Ethernet Header | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Outer IP Header | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Outer UDP Header | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 306 |R|R|Ver|I|P|R|O| Reserved(MBZ) |NP = IOAM_POT | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE 308 | Virtual Network Identifier (VNI) | Reserved | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 310 |IOAM POT Type|P| IOAM HDR len| Reserved | Next Protocol | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IOAM 312 | Random | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P 314 | Random(contd.) | O 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T 316 | Cumulative | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 318 | Cumulative (contd.) | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 321 Figure 4: IOAM POT Header Following the VXLAN-GPE Header 323 The IOAM POT Shim Header (Figure 5), which is defined in this 324 document, is a 4-octet header, that includes the following fields: 326 IOAM POT Type: 7-bit identifier of a particular POT variant that 327 specifies the POT data that is to be included as defined in 328 [I-D.ietf-ippm-ioam-data]. 330 Profile to use (P): 1-bit as defined in [I-D.ietf-ippm-ioam-data] 331 IOAM POT Option. 333 IOAM HDR len: 8-bit unsigned integer. Length of the IOAM HDR in 334 4-octet units. 336 Reserved: 8-bit reserved field MUST be set to zero. 338 Next Protocol: 8-bit unsigned integer that determines the type of 339 header following IOAM protocol. The value is from the IANA 340 registry setup for VXLAN GPE Next Protocol defined in 341 [I-D.ietf-nvo3-vxlan-gpe]. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 |IOAM POT Type|P| IOAM HDR len| Reserved | Next Protocol | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 5: POT Shim Header for VXLAN-GPE 351 The rest of the fields in the POT option [I-D.ietf-ippm-ioam-data] 352 are as follows: 354 Random: 64-bit Per-packet random number. 356 Cumulative: 64-bit Cumulative value that is updated by the Service 357 Functions. 359 3.3. IOAM Edge-to-Edge Data in VXLAN-GPE 361 The IOAM edge-to-edge option is to carry data that is added by the 362 IOAM encapsulating node and interpreted by the IOAM decapsulating 363 node. IOAM specific fields to encapsulate IOAM Edge-to-Edge data 364 fields are defined as follows: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Outer Ethernet Header | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Outer IP Header | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Outer UDP Header | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 375 |R|R|Ver|I|P|R|O| Reserved |NP = IOAM_E2E | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE 377 | Virtual Network Identifier (VNI) | Reserved | | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 379 |Type=IOAM_E2E | IOAM HDR len | Reserved | Next Protocol | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM 381 | E2E Option data field determined by IOAM-E2E-Type | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 384 Figure 6: IOAM Edge-to-Edge over a VXLAN-GPE Header 386 The IOAM E2E Shim Header, which is defined in this document, is a 387 4-octet header, that includes the following fields: 389 Type: 8-bit identifier of a particular E2E variant that specifies 390 the E2E data that is to be included as defined in 391 [I-D.ietf-ippm-ioam-data]. 393 IOAM HDR len: 8-bit unsigned integer. Length of the IOAM HDR in 394 4-octet units. 396 Reserved: 8-bit reserved field MUST be set to zero. 398 Next Protocol: 8-bit unsigned integer that determines the type of 399 header following IOAM protocol. The value is from the IANA 400 registry setup for VXLAN GPE Next Protocol defined in 401 [I-D.ietf-nvo3-vxlan-gpe]. 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 |Type=IOAM_E2E | IOAM HDR len | Reserved | Next Protocol | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Figure 7: E2E Shim Header for VXLAN-GPE 411 The rest of the E2E option [I-D.ietf-ippm-ioam-data] consists of: 413 E2E Option data field: Variable length field as defined in 414 [I-D.ietf-ippm-ioam-data] IOAM E2E Option. 416 4. Discussion of the encapsulation approach 418 This section is to support the working group discussion in selecting 419 the most appropriate approach for encapsulating IOAM data fields in 420 VXLAN-GPE. 422 An encapsulation of IOAM data fields in VXLAN-GPE should be friendly 423 to an implementation in both hardware as well as software forwarders. 424 Hardware forwarders benefit from an encapsulation that minimizes 425 iterative look-ups of fields within the packet: Any operation which 426 looks up the value of a field within the packet, based on which 427 another lookup is performed, consumes additional gates and time in an 428 implementation - both of which are desired to be kept to a minimum. 429 This means that flat TLV structures are to be preferred over nested 430 TLV structures. IOAM data fields are grouped into three option 431 categories: Trace, proof-of-transit, and edge-to-edge. Each of these 432 three options defines a TLV structure. A hardware-friendly 433 encapsulation approach avoids grouping these three option categories 434 into yet another TLV structure, but would rather carry the options as 435 a serial sequence. 437 Two approaches for encapsulating IOAM data fields in VXLAN-GPE could 438 be considered: 440 1. Use a single GPE protocol type for all IOAM types: IOAM would 441 receive a single GPE protocol type code point. A "sub-type" 442 (e.g. 4 bit wide) would then specify what IOAM options type(s) 443 (trace, proof-of-transit, edge-to-edge) are carried. In case 444 there is a need for additional IOAM options, changes would be 445 contained within the single GPE protocol type for IOAM. 447 2. Use one GPE protocol type per IOAM options type: Each IOAM data 448 field option (trace, proof-of-transit, and edge-to-edge) would be 449 specified by its own "next protocol", i.e. each IOAM options type 450 becomes its own GPE protocol type with a dedicated code point. 451 This implies that in case additional IOAM option types would be 452 added in the future, additional GPE protocol type code points 453 would need to be allocated. 455 The second option has been chosen here, because it avoids the 456 additional layer of TLV nesting that the use of a single GPE protocol 457 type for all IOAM option types would result in. 459 5. IANA Considerations 461 IANA is requested to allocate protocol numbers for the following 462 VXLAN-GPE "Next Protocols" related to IOAM: 464 +---------------+-------------+---------------+ 465 | Next Protocol | Description | Reference | 466 +---------------+-------------+---------------+ 467 | x | IOAM_Trace | This document | 468 | y | IOAM_POT | This document | 469 | z | IOAM_E2E | This document | 470 +---------------+-------------+---------------+ 472 6. Security Considerations 474 The security considerations of VXLAN-GPE are discussed in 475 [I-D.ietf-nvo3-vxlan-gpe], and the security considerations of IOAM in 476 general are discussed in [I-D.ietf-ippm-ioam-data]. 478 IOAM is considered a "per domain" feature, where one or several 479 operators decide on leveraging and configuring IOAM according to 480 their needs. Still, operators need to properly secure the IOAM 481 domain to avoid malicious configuration and use, which could include 482 injecting malicious IOAM packets into a domain. 484 7. Acknowledgements 486 The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari 487 Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya 488 Nadahalli, Stefano Previdi, Hemant Singh, Erik Nordmark, LJ Wobker, 489 and Andrew Yourtchenko for the comments and advice. 491 8. References 493 8.1. Normative References 495 [ETYPES] "IANA Ethernet Numbers", 496 . 499 [I-D.ietf-ippm-ioam-data] 500 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 501 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 502 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 503 for In-situ OAM", draft-ietf-ippm-ioam-data-00 (work in 504 progress), September 2017. 506 [I-D.ietf-nvo3-vxlan-gpe] 507 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 508 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work 509 in progress), April 2017. 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, 513 DOI 10.17487/RFC2119, March 1997, . 516 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 517 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 518 DOI 10.17487/RFC2784, March 2000, . 521 [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced 522 by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, 523 January 2002, . 525 8.2. Informative References 527 [FD.io] "Fast Data Project: FD.io", . 529 [I-D.brockners-proof-of-transit] 530 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 531 Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof 532 of Transit", draft-brockners-proof-of-transit-03 (work in 533 progress), March 2017. 535 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 536 Chaining (SFC) Architecture", RFC 7665, 537 DOI 10.17487/RFC7665, October 2015, . 540 Authors' Addresses 542 Frank Brockners 543 Cisco Systems, Inc. 544 Hansaallee 249, 3rd Floor 545 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 546 Germany 548 Email: fbrockne@cisco.com 550 Shwetha Bhandari 551 Cisco Systems, Inc. 552 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 553 Bangalore, KARNATAKA 560 087 554 India 556 Email: shwethab@cisco.com 558 Vengada Prasad Govindan 559 Cisco Systems, Inc. 561 Email: venggovi@cisco.com 563 Carlos Pignataro 564 Cisco Systems, Inc. 565 7200-11 Kit Creek Road 566 Research Triangle Park, NC 27709 567 United States 569 Email: cpignata@cisco.com 570 Hannes Gredler 571 RtBrick Inc. 573 Email: hannes@rtbrick.com 575 John Leddy 576 Comcast 578 Email: John_Leddy@cable.comcast.com 580 Stephen Youell 581 JP Morgan Chase 582 25 Bank Street 583 London E14 5JP 584 United Kingdom 586 Email: stephen.youell@jpmorgan.com 588 Tal Mizrahi 589 Marvell 590 6 Hamada St. 591 Yokneam 20692 592 Israel 594 Email: talmi@marvell.com 596 David Mozes 597 Mellanox Technologies Ltd. 599 Email: davidm@mellanox.com 601 Petr Lapukhov 602 Facebook 603 1 Hacker Way 604 Menlo Park, CA 94025 605 US 607 Email: petr@fb.com 608 Remy Chang 609 Barefoot Networks 610 2185 Park Boulevard 611 Palo Alto, CA 94306 612 US