idnits 2.17.1 draft-weis-ippm-ioam-eth-01.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 (March 10, 2019) is 1871 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-04 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-11 Summary: 0 errors (**), 0 flaws (~~), 3 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: September 11, 2019 C. Hill 6 S. Bhandari 7 V. Govindan 8 C. Pignataro 9 Cisco 10 H. Gredler 11 RtBrick Inc. 12 J. Leddy 13 Comcast 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 25 March 10, 2019 27 EtherType Protocol Identification of In-situ OAM Data 28 draft-weis-ippm-ioam-eth-01 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 September 11, 2019. 56 Copyright Notice 58 Copyright (c) 2019 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 . . . . 5 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 85 7.2. Informative References . . . . . . . . . . . . . . . . . 7 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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 4.2. Example: Geneve Encapsulation of IOAM Data Fields 215 When IOAM data fields are carried in Geneve, the IOAM encapsulation 216 defined above follows the Geneve header, as shown in Figure 2. 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 221 |Ver| Opt Len |O|C| Rsvd. | Protocol Type = | |G 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E 223 | Virtual Network Identifier (VNI) | Reserved | |N 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E 225 | Variable Length Options | |V 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+E 227 | IOAM-Type | IOAM HDR len| Next Protocol | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 229 ! | O 230 ! | A 231 ~ IOAM Option and Data Space ~ M 232 | | | 233 | | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 235 | | 236 | Inner header + Payload + Padding (L2/L3/ESP/...) | 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Figure 2: Geneve Encapsulation Example 242 The GENEVE header and fields are defined in [I-D.ietf-nvo3-geneve]. 243 The Geneve Protocol Type value is TBD_IOAM. 245 5. Security Considerations 247 This document describes the encapsulation of IOAM data fields in GRE. 248 Security considerations of the specific IOAM data fields for each 249 case (i.e., Trace, Proof of Transit, and E2E) are described in 250 defined in [I-D.ietf-ippm-ioam-data]. 252 As this document describes new protocol fields within the existing 253 GRE encapsulation, these are similar to the security considerations 254 of [RFC2890]. 256 IOAM data transported in an OAM E2E header SHOULD be integrity 257 protected (e.g., with IPsec ESP [RFC4303]) to detect changes made by 258 a device between the sending and receiving OAM endpoints. 260 6. IANA Considerations 262 A new EtherType value is requested to be added to the [ETYPES] IANA 263 registry. The description should be "In-situ OAM (IOAM)". 265 7. References 267 7.1. Normative References 269 [ETYPES] "IANA Ethernet Numbers", 270 . 273 [I-D.ietf-ippm-ioam-data] 274 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 275 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 276 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 277 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 278 data-04 (work in progress), October 2018. 280 [I-D.ietf-nvo3-geneve] 281 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 282 Network Virtualization Encapsulation", draft-ietf- 283 nvo3-geneve-11 (work in progress), March 2019. 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, 287 DOI 10.17487/RFC2119, March 1997, 288 . 290 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 291 RFC 2890, DOI 10.17487/RFC2890, September 2000, 292 . 294 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 295 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 296 May 2017, . 298 7.2. Informative References 300 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 301 RFC 4303, DOI 10.17487/RFC4303, December 2005, 302 . 304 Authors' Addresses 306 Brian Weis 307 Independent 308 USA 310 Email: bew.stds@gmail.com 311 Frank Brockners 312 Cisco Systems, Inc. 313 Hansaallee 249, 3rd Floor 314 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 315 Germany 317 Email: fbrockne@cisco.com 319 Craig Hill 320 Cisco Systems, Inc. 321 13600 Dulles Technology Drive 322 Herndon, Virginia 20171 323 United States 325 Email: crhill@cisco.com 327 Shwetha Bhandari 328 Cisco Systems, Inc. 329 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 330 Bangalore, KARNATAKA 560 087 331 India 333 Email: shwethab@cisco.com 335 Vengada Prasad Govindan 336 Cisco Systems, Inc. 338 Email: venggovi@cisco.com 340 Carlos Pignataro 341 Cisco Systems, Inc. 342 7200-11 Kit Creek Road 343 Research Triangle Park, NC 27709 344 United States 346 Email: cpignata@cisco.com 348 Hannes Gredler 349 RtBrick Inc. 351 Email: hannes@rtbrick.com 352 John Leddy 353 Comcast 355 Email: John_Leddy@cable.comcast.com 357 Stephen Youell 358 JP Morgan Chase 359 25 Bank Street 360 London E14 5JP 361 United Kingdom 363 Email: stephen.youell@jpmorgan.com 365 Tal Mizrahi 366 Huawei Network.IO Innovation Lab 367 Israel 369 Email: tal.mizrahi.phd@gmail.com 371 Aviv Kfir 372 Mellanox Technologies, Inc. 373 350 Oakmead Parkway, Suite 100 374 Sunnyvale, CA 94085 375 U.S.A. 377 Email: avivk@mellanox.com 379 Barak Gafni 380 Mellanox Technologies, Inc. 381 350 Oakmead Parkway, Suite 100 382 Sunnyvale, CA 94085 383 U.S.A. 385 Email: gbarak@mellanox.com 387 Petr Lapukhov 388 Facebook 389 1 Hacker Way 390 Menlo Park, CA 94025 391 US 393 Email: petr@fb.com 394 Mickey Spiegel 395 Barefoot Networks 396 2185 Park Boulevard 397 Palo Alto, CA 94306 398 US 400 Email: mspiegel@barefootnetworks.com