idnits 2.17.1 draft-weis-ippm-ioam-eth-05.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 (February 21, 2022) is 788 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ETYPES' == Outdated reference: A later version (-08) exists of draft-ietf-ippm-ioam-data-integrity-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ippm B. Weis, Ed. 3 Internet-Draft Independent 4 Intended status: Standards Track F. Brockners, Ed. 5 Expires: August 25, 2022 C. Hill 6 Cisco 7 S. Bhandari 8 Thoughtspot 9 V. Govindan 10 C. Pignataro, Ed. 11 N. Nainar, Ed. 12 Cisco 13 H. Gredler 14 RtBrick Inc. 15 J. Leddy 17 S. Youell 18 JMPC 19 T. Mizrahi 20 Huawei Network.IO Innovation Lab 21 A. Kfir 22 B. Gafni 23 Nvidia 24 P. Lapukhov 25 Facebook 26 M. Spiegel 27 Barefoot Networks, an Intel company 28 February 21, 2022 30 EtherType Protocol Identification of In-situ OAM Data 31 draft-weis-ippm-ioam-eth-05 33 Abstract 35 In-situ Operations, Administration, and Maintenance (IOAM) records 36 operational and telemetry information in the packet while the packet 37 traverses a path between two points in the network. This document 38 defines an EtherType that identifies IOAM data fields as being the 39 next protocol in a packet, and a header that encapsulates the IOAM 40 data fields. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on August 25, 2022. 59 Copyright Notice 61 Copyright (c) 2022 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 77 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 79 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 80 3. IOAM EtherType . . . . . . . . . . . . . . . . . . . . . . . 3 81 4. Usage Examples of the IOAM EtherType . . . . . . . . . . . . 4 82 4.1. Example: GRE Encapsulation of IOAM Data Fields . . . . . 5 83 4.2. Example: Geneve Encapsulation of IOAM Data Fields . . . . 6 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 89 8.2. Informative References . . . . . . . . . . . . . . . . . 9 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 92 1. Introduction 94 In-situ Operations, Administration, and Maintenance (IOAM) records 95 operational and telemetry information in the packet while the packet 96 traverses a particular network domain. The term "in-situ" refers to 97 the fact that the IOAM data fields are added to the data packets 98 rather than being sent within packets specifically dedicated to OAM. 99 This document proposes a new Ethertype for IOAM and defines how IOAM 100 data fields are carried as part of encapsulations where the IOAM data 101 fields follows an encapsulation header that uses an EtherType to 102 denote the type of protocol data unit. Examples of these protocols 103 are GRE [RFC2784] [RFC2890] and Geneve [RFC8926]). This document 104 outlines how IOAM data fields are encoded in these encapsultion 105 headers. 107 2. Conventions 109 2.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 2.2. Abbreviations 119 Abbreviations used in this document: 121 E2E: Edge-to-Edge 123 Geneve: Generic Network Virtualization Encapsulation 125 GRE: Generic Routing Encapsulation 127 IOAM: In-situ Operations, Administration, and Maintenance 129 OAM: Operations, Administration, and Maintenance 131 POT: Proof of Transit 133 3. IOAM EtherType 135 When the IOAM data fields are included within an encapsulation that 136 identifies the next protocol using an EtherType (e.g., GRE or Geneve) 137 the presence of IOAM data fields are identified with TBD_IOAM. When 138 this EtherType is used, an additional IOAM header is also included. 139 This header indicates the type of IOAM data fields that follows, and 140 the next protocol that follows the IOAM data fields. 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | IOAM-Type | IOAM HDR len| Next Protocol | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 ! | 148 ! | 149 ~ IOAM Option and Data Space ~ 150 | | 151 | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 The IOAM encapsulation is defined as follows. 156 IOAM Type: 8-bit field defining the IOAM Option type, as defined in 157 Section 5.1 of [I-D.ietf-ippm-ioam-data]. 159 IOAM HDR Len: 8 bit Length field contains the length of the IOAM 160 header in 4-octet units. 162 Next Protocol: 16 bits Next Protocol Type field contains the 163 protocol type of the protocol data unit following IOAM protocol 164 header. Protocol Type is defined to be an EtherType value from 165 [ETYPES]. An implementation receiving a packet containing a 166 Protocol Type which is not listed in one of those registries 167 SHOULD discard the packet. 169 IOAM Option and Data Space: IOAM option header and data is present 170 as specified by the IOAM-Option-Type field, and is defined in 171 Section 5 of [I-D.ietf-ippm-ioam-data]. 173 Multiple IOAM options MAY be included within the encapsulation 174 header. For example, if a GRE encapsulation contains two IOAM 175 options before the data payload, the Next Protocol field of the first 176 IOAM option will contain the value of TBD_IOAM, while the Next 177 Protocol field of the second IOAM option will contain the EtherType 178 indicating the type of the data payload. 180 4. Usage Examples of the IOAM EtherType 182 The IOAM EtherType can be used with any encapsulation that uses 183 EtherType to denote the type of the protocol data unit. The 184 following sections show how it can be used when GRE and Geneve are 185 used as the encapsulation header. 187 4.1. Example: GRE Encapsulation of IOAM Data Fields 189 When IOAM data fields are carried in GRE, the IOAM encapsulation 190 defined above follows the GRE header, as shown in Figure 1. 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 |C| |K|S| Reserved0 | Ver | Protocol Type = | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 197 | Checksum (optional) | Reserved1 (Optional) | G 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 199 | Key (optional) | E 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 201 | Sequence Number (Optional) | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 203 | IOAM-Type | IOAM HDR len| Next Protocol | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 205 ! | O 206 ! | A 207 ~ IOAM Option and Data Space ~ M 208 | | | 209 | | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 211 | | 212 | Payload + Padding (L2/L3/ESP/...) | 213 | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Figure 1: GRE Encapsulation Example 218 The GRE header and fields are defined in [RFC2890]. The GRE Protocol 219 Type value is set to TBD_IOAM. 221 Figure 2 shows two example protocol header stacks that use GRE along 222 with IOAM. IOAM Option-Types (the below diagram uses "IOAM" as 223 shorthand for IOAM Option-Types) are sequenced in behind the GRE 224 header that follows the "outer" header of the next protocol unit. 226 Example 1 Example 2 228 | ... | | ... | 229 +----------------+ +----------------+ 230 | TCP/UDP header | | IP, ... | 231 +----------------+ +----------------+ 232 | IP header | | Eth. header | 233 +----------------+ +----------------+ 234 | IOAM | | IOAM | 235 +----------------+ +----------------+ 236 | GRE header | | GRE header | 237 +----------------+ +----------------+ 238 | IP header | | IP header | 239 +----------------+ +----------------+ 240 | Layer 2 | | Layer 2 | 241 +----------------+ +----------------+ 242 | Layer 1 | | Layer 1 | 243 +----------------+ +----------------+ 245 Figure 2: GRE with IOAM examples 247 4.2. Example: Geneve Encapsulation of IOAM Data Fields 249 When IOAM data fields are carried in Geneve, the IOAM encapsulation 250 defined above follows the Geneve header, as shown in Figure 3. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 255 |Ver| Opt Len |O|C| Rsvd. | Protocol Type = | |G 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E 257 | Virtual Network Identifier (VNI) | Reserved | |N 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E 259 | Variable Length Options | |V 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+E 261 | IOAM-Type | IOAM HDR len| Next Protocol | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 263 ! | O 264 ! | A 265 ~ IOAM Option and Data Space ~ M 266 | | | 267 | | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 269 | | 270 | Inner header + Payload + Padding (L2/L3/ESP/...) | 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Figure 3: Geneve Encapsulation Example 276 The Geneve header and fields are defined in [RFC8926]. The Geneve 277 Protocol Type value is TBD_IOAM. 279 5. Security Considerations 281 This document describes the encapsulation of IOAM data fields in the 282 encapsulation header such as GRE and Geneve that uses EtherType to 283 denote the protocol data unit. Security considerations of the 284 specific IOAM data fields for each case (i.e., Trace, Proof of 285 Transit, and E2E) are described in [I-D.ietf-ippm-ioam-data]. 287 As this document describes new protocol fields within the existing 288 encapsulation, any security considerations of the respective 289 encapsulation header is applicable. When the encapsulation is GRE, 290 the security considerations of [RFC2890] is applicable. When the 291 encapsulation is Geneve, the security considerations of [RFC8926] is 292 applicable. 294 IOAM data fields SHOULD be integrity protected (e.g., with 295 [I-D.ietf-ippm-ioam-data-integrity]) to detect changes made by a 296 device between the IOAM encapsulating node and the IOAM decapsulating 297 node. 299 6. IANA Considerations 301 A new EtherType value is requested to be added to the [ETYPES] IANA 302 registry by IEEE Registration Authority. The description should be 303 "In-situ OAM (IOAM)". 305 7. Acknowledgements 307 We would like to thank Nagendra Kumar Nainar for the contribution. 309 8. References 311 8.1. Normative References 313 [ETYPES] "IANA Ethernet Numbers", 314 . 317 [I-D.ietf-ippm-ioam-data] 318 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 319 for In-situ OAM", draft-ietf-ippm-ioam-data-17 (work in 320 progress), December 2021. 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, 324 DOI 10.17487/RFC2119, March 1997, 325 . 327 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 328 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 329 DOI 10.17487/RFC2784, March 2000, 330 . 332 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 333 RFC 2890, DOI 10.17487/RFC2890, September 2000, 334 . 336 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 337 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 338 May 2017, . 340 [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 341 "Geneve: Generic Network Virtualization Encapsulation", 342 RFC 8926, DOI 10.17487/RFC8926, November 2020, 343 . 345 8.2. Informative References 347 [I-D.ietf-ippm-ioam-data-integrity] 348 Brockners, F., Bhandari, S., and T. Mizrahi, "Integrity of 349 In-situ OAM Data Fields", draft-ietf-ippm-ioam-data- 350 integrity-00 (work in progress), October 2021. 352 Authors' Addresses 354 Brian Weis (editor) 355 Independent 356 USA 358 Email: bew.stds@gmail.com 360 Frank Brockners (editor) 361 Cisco Systems, Inc. 362 Hansaallee 249, 3rd Floor 363 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 364 Germany 366 Email: fbrockne@cisco.com 368 Craig Hill 369 Cisco Systems, Inc. 370 13600 Dulles Technology Drive 371 Herndon, Virginia 20171 372 United States 374 Email: crhill@cisco.com 376 Shwetha Bhandari 377 Thoughtspot 378 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 379 Bangalore, KARNATAKA 560 102 380 India 382 Email: shwetha.bhandari@thoughtspot.com 384 Vengada Prasad Govindan 385 Cisco Systems, Inc. 387 Email: venggovi@cisco.com 388 Carlos Pignataro (editor) 389 Cisco Systems, Inc. 390 7200-11 Kit Creek Road 391 Research Triangle Park, NC 27709 392 United States 394 Email: cpignata@cisco.com 396 Nagendra Kumar Nainar (editor) 397 Cisco Systems, Inc. 398 7200-11 Kit Creek Road 399 Research Triangle Park, NC 27709 400 United States 402 Email: naikumar@cisco.com 404 Hannes Gredler 405 RtBrick Inc. 407 Email: hannes@rtbrick.com 409 John Leddy 410 United States 412 Email: john@leddy.net 414 Stephen Youell 415 JP Morgan Chase 416 25 Bank Street 417 London E14 5JP 418 United Kingdom 420 Email: stephen.youell@jpmorgan.com 422 Tal Mizrahi 423 Huawei Network.IO Innovation Lab 424 Israel 426 Email: tal.mizrahi.phd@gmail.com 427 Aviv Kfir 428 Nvidia 429 350 Oakmead Parkway, Suite 100 430 Sunnyvale, CA 94085 431 U.S.A. 433 Email: avivk@nvidia.com 435 Barak Gafni 436 Nvidia 437 350 Oakmead Parkway, Suite 100 438 Sunnyvale, CA 94085 439 U.S.A. 441 Email: gbarak@nvidia.com 443 Petr Lapukhov 444 Facebook 445 1 Hacker Way 446 Menlo Park, CA 94025 447 US 449 Email: petr@fb.com 451 Mickey Spiegel 452 Barefoot Networks, an Intel company 453 4750 Patrick Henry Drive 454 Santa Clara, CA 95054 455 US 457 Email: mickey.spiegel@intel.com