idnits 2.17.1 draft-weis-ippm-ioam-eth-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 22, 2018) is 2013 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-03 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'IP-PROT' Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ippm B. Weis 3 Internet-Draft F. Brockners 4 Intended status: Standards Track C. Hill 5 Expires: April 25, 2019 S. Bhandari 6 V. Govindan 7 C. Pignataro 8 Cisco 9 H. Gredler 10 RtBrick Inc. 11 J. Leddy 12 Comcast 13 S. Youell 14 JMPC 15 T. Mizrahi 16 Marvell 17 A. Kfir 18 B. Gafni 19 Mellanox Technologies, Inc. 20 P. Lapukhov 21 Facebook 22 M. Spiegel 23 Barefoot Networks 24 October 22, 2018 26 Ethernet Encapsulation for In-situ OAM Data 27 draft-weis-ippm-ioam-eth-00 29 Abstract 31 In-situ Operations, Administration, and Maintenance (IOAM) records 32 operational and telemetry information in the packet while the packet 33 traverses a path between two points in the network. This document 34 outlines how encapsulations using an EtherType to identify IOAM data 35 fields as the next header in a packet. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 25, 2019. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 74 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 75 3. IOAM Ethertype . . . . . . . . . . . . . . . . . . . . . . . 3 76 4. Usage Examples of the IOAM Ethertype . . . . . . . . . . . . 4 77 4.1. Example: GRE Encapsulation of In-situ OAM Date Fields . . 5 78 4.2. Example: Geneve Encapsulation of IOAM Data Fields . . . . 5 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 83 7.2. Informative References . . . . . . . . . . . . . . . . . 7 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 86 1. Introduction 88 In-situ Operations, Administration, and Maintenance (IOAM) records 89 operational and telemetry information in the packet while the packet 90 traverses a particular network domain. The term "in-situ" refers to 91 the fact that the IOAM data fields are added to the data packets 92 rather than being sent within packets specifically dedicated to OAM. 93 This document defines how IOAM data fields are carried as part of 94 encapsulations where the IOAM data follows a header that uses an 95 EtherType to denote the next protocol in the packet. Examples of 96 these protocols are GRE [RFC2784] and Geneve [I-D.ietf-nvo3-geneve]). 98 This document outlines how IOAM data fields are encoded in these 99 protocols. 101 2. Conventions 103 2.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 2.2. Abbreviations 113 Abbreviations used in this document: 115 E2E: Edge-to-Edge 117 Geneve: Generic Network Virtualization Encapsulation 119 GRE: Generic Routing Encapsulation 121 IOAM: In-situ Operations, Administration, and Maintenance 123 OAM: Operations, Administration, and Maintenance 125 POT: Proof of Transit 127 3. IOAM Ethertype 129 When the IOAM data fields are included within an encapsulation that 130 identifies the next protocol using an EtherType (e.g., GRE or Geneve) 131 the presence of IOAM data fields are identified with TBD_IOAM. When 132 the Ethernet Encapsulation for In-situ OAM Data is used, an 133 additional IOAM header is also included. This header indicates the 134 type of IOAM data that follows, and the next protocol that follows 135 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 bits Length field contains the length of the 155 variable IOAM data octets 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. When 159 the most significant octet is 0x00, the Protocol Type is taken to 160 be an IP Protocol Number as defined in [IP-PROT]. Otherwise, the 161 Protocol Type is defined to be an EtherType value from [ETYPES]. 162 An implementation receiving a packet containing a Protocol Type 163 which is not listed in one of those registries SHOULD discard the 164 packet. 166 IOAM Option and Data Space: IOAM option header and data is present 167 as specified by the IOAM-Type field, and is defined in Section 4 168 of [I-D.ietf-ippm-ioam-data]. 170 Multiple IOAM options MAY be included within the IOAM Option and Data 171 Space. For example, if two IOAM options are included, the Next 172 Protocol field of the first IOAM option will contain the value of 173 TBD_IOAM, while the Next Protocol field of the second IOAM option 174 will contain the Ethertype or IP protocol Number indicating the type 175 of the data packet. 177 4. Usage Examples of the IOAM Ethertype 179 The Ethernet Encapsulation for In-situ OAM Data can be used with many 180 encapsulations. The following sections show how it can be used with 181 GRE and Geneve. 183 4.1. Example: GRE Encapsulation of In-situ OAM Date Fields 185 When IOAM data fields are carried in GRE, the IOAM encapsulation 186 defined above follows the GRE header, as shown in Figure 1. 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 191 |C| Reserved0 | Ver | Protocol Type = | G 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 193 | Checksum (optional) | Reserved1 (Optional) | E 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 [RFC2784]. 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 [RFC2784]. 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-03 (work in progress), June 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-08 (work in progress), October 2018. 285 [IP-PROT] "IANA Protocol Numbers", 286 . 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, 291 DOI 10.17487/RFC2119, March 1997, 292 . 294 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 295 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 296 DOI 10.17487/RFC2784, March 2000, 297 . 299 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 300 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 301 May 2017, . 303 7.2. Informative References 305 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 306 RFC 4303, DOI 10.17487/RFC4303, December 2005, 307 . 309 Authors' Addresses 311 Brian Weis 312 Cisco Systems, Inc. 313 170 W. Tasman Drive 314 San Jose, California 95134-1706 315 USA 317 Phone: +1-408-526-4796 318 Email: bew@cisco.com 320 Frank Brockners 321 Cisco Systems, Inc. 322 Hansaallee 249, 3rd Floor 323 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 324 Germany 326 Email: fbrockne@cisco.com 328 Craig Hill 329 Cisco Systems, Inc. 330 13600 Dulles Technology Drive 331 Herndon, Virginia 20171 332 United States 334 Email: crhill@cisco.com 336 Shwetha Bhandari 337 Cisco Systems, Inc. 338 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 339 Bangalore, KARNATAKA 560 087 340 India 342 Email: shwethab@cisco.com 344 Vengada Prasad Govindan 345 Cisco Systems, Inc. 347 Email: venggovi@cisco.com 348 Carlos Pignataro 349 Cisco Systems, Inc. 350 7200-11 Kit Creek Road 351 Research Triangle Park, NC 27709 352 United States 354 Email: cpignata@cisco.com 356 Hannes Gredler 357 RtBrick Inc. 359 Email: hannes@rtbrick.com 361 John Leddy 362 Comcast 364 Email: John_Leddy@cable.comcast.com 366 Stephen Youell 367 JP Morgan Chase 368 25 Bank Street 369 London E14 5JP 370 United Kingdom 372 Email: stephen.youell@jpmorgan.com 374 Tal Mizrahi 375 Marvell 376 6 Hamada St. 377 Yokneam 20692 378 Israel 380 Email: talmi@marvell.com 382 Aviv Kfir 383 Mellanox Technologies, Inc. 384 350 Oakmead Parkway, Suite 100 385 Sunnyvale, CA 94085 386 U.S.A. 388 Email: avivk@mellanox.com 389 Barak Gafni 390 Mellanox Technologies, Inc. 391 350 Oakmead Parkway, Suite 100 392 Sunnyvale, CA 94085 393 U.S.A. 395 Email: gbarak@mellanox.com 397 Petr Lapukhov 398 Facebook 399 1 Hacker Way 400 Menlo Park, CA 94025 401 US 403 Email: petr@fb.com 405 Mickey Spiegel 406 Barefoot Networks 407 2185 Park Boulevard 408 Palo Alto, CA 94306 409 US 411 Email: mspiegel@barefootnetworks.com