idnits 2.17.1 draft-weis-ippm-ioam-eth-03.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 (April 28, 2020) is 1453 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 (-17) exists of draft-ietf-ippm-ioam-data-09 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 3 Internet-Draft Independent 4 Intended status: Standards Track F. Brockners 5 Expires: October 30, 2020 C. Hill 6 S. Bhandari 7 V. Govindan 8 C. Pignataro 9 Cisco 10 H. Gredler 11 RtBrick Inc. 12 J. Leddy 14 S. Youell 15 JMPC 16 T. Mizrahi 17 Huawei Network.IO Innovation Lab 18 A. Kfir 19 B. Gafni 20 Mellanox Technologies, Inc. 21 P. Lapukhov 22 Facebook 23 M. Spiegel 24 Barefoot Networks, an Intel company 25 April 28, 2020 27 EtherType Protocol Identification of In-situ OAM Data 28 draft-weis-ippm-ioam-eth-03 30 Abstract 32 In-situ Operations, Administration, and Maintenance (IOAM) records 33 operational and telemetry information in the packet while the packet 34 traverses a path between two points in the network. This document 35 defines an EtherType that identifies IOAM data fields as being the 36 next protocol in a packet, and a header that encapsulates the IOAM 37 data fields. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on October 30, 2020. 56 Copyright Notice 58 Copyright (c) 2020 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 76 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 77 3. IOAM EtherType . . . . . . . . . . . . . . . . . . . . . . . 3 78 4. Usage Examples of the IOAM EtherType . . . . . . . . . . . . 4 79 4.1. Example: GRE Encapsulation of IOAM Data Fields . . . . . 4 80 4.2. Example: Geneve Encapsulation of IOAM Data Fields . . . . 6 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 85 7.2. Informative References . . . . . . . . . . . . . . . . . 8 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 88 1. Introduction 90 In-situ Operations, Administration, and Maintenance (IOAM) records 91 operational and telemetry information in the packet while the packet 92 traverses a particular network domain. The term "in-situ" refers to 93 the fact that the IOAM data fields are added to the data packets 94 rather than being sent within packets specifically dedicated to OAM. 95 This document defines how IOAM data fields are carried as part of 96 encapsulations where the IOAM data follows a header that uses an 97 EtherType to denote the next protocol in the packet. Examples of 98 these protocols are GRE [RFC2890] and Geneve [I-D.ietf-nvo3-geneve]). 99 This document outlines how IOAM data fields are encoded in these 100 protocols. 102 2. Conventions 104 2.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 2.2. Abbreviations 114 Abbreviations used in this document: 116 E2E: Edge-to-Edge 118 Geneve: Generic Network Virtualization Encapsulation 120 GRE: Generic Routing Encapsulation 122 IOAM: In-situ Operations, Administration, and Maintenance 124 OAM: Operations, Administration, and Maintenance 126 POT: Proof of Transit 128 3. IOAM EtherType 130 When the IOAM data fields are included within an encapsulation that 131 identifies the next protocol using an EtherType (e.g., GRE or Geneve) 132 the presence of IOAM data fields are identified with TBD_IOAM. When 133 this EtherType is used, an additional IOAM header is also included. 134 This header indicates the type of IOAM data that follows, and the 135 next protocol that follows the IOAM data. 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | IOAM-Type | IOAM HDR len| Next Protocol | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 ! | 143 ! | 144 ~ IOAM Option and Data Space ~ 145 | | 146 | | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 The IOAM encapsulation is defined as follows. 151 IOAM Type: 8-bit field defining the IOAM Option type, as defined in 152 Section 7.2 of [I-D.ietf-ippm-ioam-data]. 154 IOAM HDR Len: 8 bit Length field contains the length of the IOAM 155 header in 4-octet units. 157 Next Protocol: 16 bits Next Protocol Type field contains the 158 protocol type of the packet following IOAM protocol header. 159 Protocol Type is defined to be an EtherType value from [ETYPES]. 160 An implementation receiving a packet containing a Protocol Type 161 which is not listed in one of those registries SHOULD discard the 162 packet. 164 IOAM Option and Data Space: IOAM option header and data is present 165 as specified by the IOAM-Type field, and is defined in Section 4 166 of [I-D.ietf-ippm-ioam-data]. 168 Multiple IOAM options MAY be included within the IOAM Option and Data 169 Space. For example, if two IOAM options are included, the Next 170 Protocol field of the first IOAM option will contain the value of 171 TBD_IOAM, while the Next Protocol field of the second IOAM option 172 will contain the EtherType indicating the type of the data packet. 174 4. Usage Examples of the IOAM EtherType 176 The IOAM EtherType can be used with many encapsulations. The 177 following sections show how it can be used with GRE and Geneve. 179 4.1. Example: GRE Encapsulation of IOAM Data Fields 181 When IOAM data fields are carried in GRE, the IOAM encapsulation 182 defined above follows the GRE header, as shown in Figure 1. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 187 |C| |K|S| Reserved0 | Ver | Protocol Type = | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 189 | Checksum (optional) | Reserved1 (Optional) | G 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 191 | Key (optional) | E 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 193 | Sequence Number (Optional) | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 195 | IOAM-Type | IOAM HDR len| Next Protocol | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 197 ! | O 198 ! | A 199 ~ IOAM Option and Data Space ~ M 200 | | | 201 | | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 203 | | 204 | Payload + Padding (L2/L3/ESP/...) | 205 | | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Figure 1: GRE Encapsulation Example 210 The GRE header and fields are defined in [RFC2890]. The GRE Protocol 211 Type value is TBD_IOAM. 213 Figure 2 shows two example protocol header stacks that use GRE along 214 with IOAM. IOAM-Option-Types (the below diagram uses "IOAM" as 215 shorthand for IOAM-Option-Types) are sequenced in behind the GRE 216 header that follows the "outer" IP header. 218 Example 1 Example 2 220 | ... | | ... | 221 +----------------+ +----------------+ 222 | TCP/UDP header | | IP, ... | 223 +----------------+ +----------------+ 224 | IP header | | Eth. header | 225 +----------------+ +----------------+ 226 | IOAM | | IOAM | 227 +----------------+ +----------------+ 228 | GRE header | | GRE header | 229 +----------------+ +----------------+ 230 | IP header | | IP header | 231 +----------------+ +----------------+ 232 | Layer 2 | | Layer 2 | 233 +----------------+ +----------------+ 234 | Layer 1 | | Layer 1 | 235 +----------------+ +----------------+ 237 Figure 2: GRE with IOAM examples 239 4.2. Example: Geneve Encapsulation of IOAM Data Fields 241 When IOAM data fields are carried in Geneve, the IOAM encapsulation 242 defined above follows the Geneve header, as shown in Figure 3. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 247 |Ver| Opt Len |O|C| Rsvd. | Protocol Type = | |G 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E 249 | Virtual Network Identifier (VNI) | Reserved | |N 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E 251 | Variable Length Options | |V 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+E 253 | IOAM-Type | IOAM HDR len| Next Protocol | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 255 ! | O 256 ! | A 257 ~ IOAM Option and Data Space ~ M 258 | | | 259 | | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 261 | | 262 | Inner header + Payload + Padding (L2/L3/ESP/...) | 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 3: Geneve Encapsulation Example 268 The GENEVE header and fields are defined in [I-D.ietf-nvo3-geneve]. 269 The Geneve Protocol Type value is TBD_IOAM. 271 5. Security Considerations 273 This document describes the encapsulation of IOAM data fields in GRE. 274 Security considerations of the specific IOAM data fields for each 275 case (i.e., Trace, Proof of Transit, and E2E) are described in 276 defined in [I-D.ietf-ippm-ioam-data]. 278 As this document describes new protocol fields within the existing 279 GRE encapsulation, these are similar to the security considerations 280 of [RFC2890]. 282 IOAM data transported in an OAM E2E header SHOULD be integrity 283 protected (e.g., with IPsec ESP [RFC4303]) to detect changes made by 284 a device between the sending and receiving OAM endpoints. 286 6. IANA Considerations 288 A new EtherType value is requested to be added to the [ETYPES] IANA 289 registry. The description should be "In-situ OAM (IOAM)". 291 7. References 293 7.1. Normative References 295 [ETYPES] "IANA Ethernet Numbers", 296 . 299 [I-D.ietf-ippm-ioam-data] 300 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 301 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 302 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 303 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 304 ietf-ippm-ioam-data-09 (work in progress), March 2020. 306 [I-D.ietf-nvo3-geneve] 307 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 308 Network Virtualization Encapsulation", draft-ietf- 309 nvo3-geneve-16 (work in progress), March 2020. 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 317 RFC 2890, DOI 10.17487/RFC2890, September 2000, 318 . 320 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 321 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 322 May 2017, . 324 7.2. Informative References 326 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 327 RFC 4303, DOI 10.17487/RFC4303, December 2005, 328 . 330 Authors' Addresses 332 Brian Weis 333 Independent 334 USA 336 Email: bew.stds@gmail.com 337 Frank Brockners 338 Cisco Systems, Inc. 339 Hansaallee 249, 3rd Floor 340 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 341 Germany 343 Email: fbrockne@cisco.com 345 Craig Hill 346 Cisco Systems, Inc. 347 13600 Dulles Technology Drive 348 Herndon, Virginia 20171 349 United States 351 Email: crhill@cisco.com 353 Shwetha Bhandari 354 Cisco Systems, Inc. 355 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 356 Bangalore, KARNATAKA 560 087 357 India 359 Email: shwethab@cisco.com 361 Vengada Prasad Govindan 362 Cisco Systems, Inc. 364 Email: venggovi@cisco.com 366 Carlos Pignataro 367 Cisco Systems, Inc. 368 7200-11 Kit Creek Road 369 Research Triangle Park, NC 27709 370 United States 372 Email: cpignata@cisco.com 374 Hannes Gredler 375 RtBrick Inc. 377 Email: hannes@rtbrick.com 378 John Leddy 379 United States 381 Email: john@leddy.net 383 Stephen Youell 384 JP Morgan Chase 385 25 Bank Street 386 London E14 5JP 387 United Kingdom 389 Email: stephen.youell@jpmorgan.com 391 Tal Mizrahi 392 Huawei Network.IO Innovation Lab 393 Israel 395 Email: tal.mizrahi.phd@gmail.com 397 Aviv Kfir 398 Mellanox Technologies, Inc. 399 350 Oakmead Parkway, Suite 100 400 Sunnyvale, CA 94085 401 U.S.A. 403 Email: avivk@mellanox.com 405 Barak Gafni 406 Mellanox Technologies, Inc. 407 350 Oakmead Parkway, Suite 100 408 Sunnyvale, CA 94085 409 U.S.A. 411 Email: gbarak@mellanox.com 413 Petr Lapukhov 414 Facebook 415 1 Hacker Way 416 Menlo Park, CA 94025 417 US 419 Email: petr@fb.com 420 Mickey Spiegel 421 Barefoot Networks, an Intel company 422 4750 Patrick Henry Drive 423 Santa Clara, CA 95054 424 US 426 Email: mickey.spiegel@intel.com