idnits 2.17.1 draft-brockners-ippm-ioam-vxlan-gpe-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 (November 4, 2019) is 1635 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) == Unused Reference: 'ETYPES' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'RFC2784' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC3232' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'RFC7665' is defined on line 352, 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-08 == Outdated reference: A later version (-19) exists of draft-ietf-lisp-gpe-09 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-08 ** 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 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ippm F. Brockners 3 Internet-Draft S. Bhandari 4 Intended status: Standards Track V. Govindan 5 Expires: May 7, 2020 C. Pignataro 6 Cisco 7 H. Gredler 8 RtBrick Inc. 9 J. Leddy 11 S. Youell 12 JMPC 13 T. Mizrahi 14 Huawei Network.IO Innovation Lab 15 A. Kfir 16 B. Gafni 17 Mellanox Technologies, Inc. 18 P. Lapukhov 19 Facebook 20 M. Spiegel 21 Barefoot Networks 22 November 4, 2019 24 VXLAN-GPE Encapsulation for In-situ OAM Data 25 draft-brockners-ippm-ioam-vxlan-gpe-03 27 Abstract 29 In-situ Operations, Administration, and Maintenance (IOAM) records 30 operational and telemetry information in the packet while the packet 31 traverses a path between two points in the network. This document 32 outlines how IOAM data fields are encapsulated in VXLAN-GPE. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 7, 2020. 50 Copyright Notice 52 Copyright (c) 2019 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 (https://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 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. Discussion of the encapsulation approach . . . . . . . . 5 74 4.2. IOAM and the use of the VXLAN O-bit . . . . . . . . . . . 6 75 4.3. Transit devices . . . . . . . . . . . . . . . . . . . . . 6 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 77 5.1. VXLAN-GPE Next Protocol Value . . . . . . . . . . . . . . 6 78 5.2. LISP-GPE Next Protocol Value . . . . . . . . . . . . . . 7 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 83 8.2. Informative References . . . . . . . . . . . . . . . . . 8 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 86 1. Introduction 88 In-situ OAM (IOAM) records OAM information within the packet while 89 the packet traverses a particular network domain. The term "in-situ" 90 refers to the fact that the IOAM data fields are added to the data 91 packets rather than being sent within packets specifically dedicated 92 to OAM. This document defines how IOAM data fields are transported 93 as part of the VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] encapsulation. 94 The IOAM data fields are defined in [I-D.ietf-ippm-ioam-data]. An 95 implementation of IOAM which leverages VXLAN-GPE to carry the IOAM 96 data is available from the FD.io open source software project 97 [FD.io]. 99 2. Conventions 101 2.1. Requirement Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2.2. Abbreviations 109 Abbreviations used in this document: 111 IOAM: In-situ Operations, Administration, and Maintenance 113 OAM: Operations, Administration, and Maintenance 115 VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol 116 Extension 118 3. IOAM Data Field Encapsulation in VXLAN-GPE 120 VXLAN-GPE is defined in [I-D.ietf-nvo3-vxlan-gpe]. IOAM data fields 121 are carried in VXLAN-GPE using a next protocol value of TBD_IOAM. An 122 IOAM header is added containing the different IOAM data fields 123 defined in [I-D.ietf-ippm-ioam-data]. In an administrative domain 124 where IOAM is used, insertion of the IOAM header in VXLAN-GPE is 125 enabled at the VXLAN-GPE tunnel endpoints, which also serve as IOAM 126 encapsulating/decapsulating nodes by means of configuration. 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Outer Ethernet Header | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Outer IP Header | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Outer UDP Header | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 137 |R|R|Ver|I|P|R|O| Reserved | NP=TBD_IOAM | | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE 139 | Virtual Network Identifier (VNI) | Reserved | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 141 | IOAM-Type | IOAM HDR len | Reserved | Next Protocol | | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 143 ! | O 144 ! | A 145 ~ IOAM Option and Data Space ~ M 146 | | | 147 | | | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 149 | | 150 | | 151 | Payload + Padding (L2/L3/ESP/...) | 152 | | 153 | | 154 | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Figure 1: IOAM data encapsulation in VXLAN-GPE 159 The VXLAN-GPE header and fields are defined in 160 [I-D.ietf-nvo3-vxlan-gpe]. The VXLAN Next Protocol value for IOAM is 161 TBD_IOAM. 163 The IOAM related fields in VXLAN-GPE are defined as follows: 165 IOAM-Type: 8-bit field defining the IOAM Option type, as defined in 166 Section 7.2 of [I-D.ietf-ippm-ioam-data]. 168 IOAM HDR len: 8-bit unsigned integer. Length of the IOAM HDR in 169 4-octet units not including the first 4 octects. 171 Reserved: 8-bit reserved field MUST be set to zero upon transmission 172 and ignored upon receipt. 174 Next Protocol: 8-bit unsigned integer that determines the type of 175 header following IOAM protocol. The value is from the IANA 176 registry setup for VXLAN GPE Next Protocol defined in 177 [I-D.ietf-nvo3-vxlan-gpe]. 179 IOAM Option and Data Space: IOAM option header and data is present 180 as specified by the IOAM-Type field, and is defined in Section 4 181 of [I-D.ietf-ippm-ioam-data]. 183 Multiple IOAM options MAY be included within the VXLAN-GPE 184 encapsulation. For example, if a VXLAN-GPE encapsulation contains 185 two IOAM options before a data payload, the Next Protocol field of 186 the first IOAM option will contain the value of TBD_IOAM, while the 187 Next Protocol field of the second IOAM option will contain the VXLAN 188 "Next Protocol" number indicating the type of the data payload. 190 4. Considerations 192 This section summarizes a set of considerations on the overall 193 approach taken for IOAM data encapsulation in VXLAN-GPE, as well as 194 deployment considerations. 196 4.1. Discussion of the encapsulation approach 198 This section is to support the working group discussion in selecting 199 the most appropriate approach for encapsulating IOAM data fields in 200 VXLAN-GPE. 202 An encapsulation of IOAM data fields in VXLAN-GPE should be friendly 203 to an implementation in both hardware as well as software forwarders. 204 Hardware forwarders benefit from an encapsulation that minimizes 205 iterative look-ups of fields within the packet: Any operation which 206 looks up the value of a field within the packet, based on which 207 another lookup is performed, consumes additional gates and time in an 208 implementation - both of which are desired to be kept to a minimum. 209 This means that flat TLV structures are to be preferred over nested 210 TLV structures. IOAM data fields are grouped into three option 211 categories: Trace, proof-of-transit, and edge-to-edge. Each of these 212 three options defines a TLV structure. A hardware-friendly 213 encapsulation approach avoids grouping these three option categories 214 into yet another TLV structure, but would rather carry the options as 215 a serial sequence. 217 Two approaches for encapsulating IOAM data fields in VXLAN-GPE could 218 be considered: 220 1. Use a single GPE protocol type for all IOAM types: IOAM would 221 receive a single GPE protocol type code point. A "sub-type" 222 field would then specify what IOAM options type (trace, proof-of- 223 transit, edge-to-edge) is carried. 225 2. Use one GPE protocol type per IOAM options type: Each IOAM data 226 field option (trace, proof-of-transit, and edge-to-edge) would be 227 specified by its own "next protocol", i.e. each IOAM options type 228 becomes its own GPE protocol type with a dedicated code point. 229 This implies that in case additional IOAM option types would be 230 added in the future, additional GPE protocol type code points 231 would need to be allocated. 233 The first option has been chosen here. Multiple back-to-back IOAM 234 options can be encoded as a succession of IOAM headers, with the same 235 single GPE protocol type appearing as the next protocol before each 236 IOAM header, but different sub-types within each IOAM header. 238 4.2. IOAM and the use of the VXLAN O-bit 240 [I-D.ietf-nvo3-vxlan-gpe] defines an "O bit" for OAM packets. Per 241 [I-D.ietf-nvo3-vxlan-gpe] the O bit indicates that the packet 242 contains an OAM message instead of data payload. Packets that carry 243 IOAM data fields in addition to regular data payload / customer 244 traffic must not set the O bit. Packets that carry only IOAM data 245 fields without any payload must set the O bit. 247 4.3. Transit devices 249 If IOAM is deployed in domains where UDP port numbers are not 250 controlled and do not have a domain-wide meaning, such as on the 251 global Internet, transit devices MUST NOT attempt to modify the IOAM 252 data contained in the IOAM header following the VXLAN-GPE header. In 253 case UDP port numbers are not controlled there might be UDP packets 254 specifying the same UDP port number that VXLAN-GPE utilizes, i.e. 255 4790, but with a payload that is not VXLAN-GPE. The scenario and 256 associated reasoning is discussed in [RFC7605] which states that "it 257 is important to recognize that any interpretation of port numbers -- 258 except at the endpoints -- may be incorrect, because port numbers are 259 meaningful only at the endpoints." 261 5. IANA Considerations 263 5.1. VXLAN-GPE Next Protocol Value 265 IANA is requested to allocate a value in the VXLAN-GPE "Next 266 Protocol" registry for IOAM, which is defined in 267 [I-D.ietf-nvo3-vxlan-gpe]. 269 +---------------+-------------+---------------+ 270 | Next Protocol | Description | Reference | 271 +---------------+-------------+---------------+ 272 | 0x81 | IOAM | This document | 273 +---------------+-------------+---------------+ 275 5.2. LISP-GPE Next Protocol Value 277 IANA is requested to allocate a value in the LISP-GPE "Next Protocol" 278 registry for IOAM, which is defined in [I-D.ietf-lisp-gpe]. 280 +---------------+-------------+---------------+ 281 | Next Protocol | Description | Reference | 282 +---------------+-------------+---------------+ 283 | 0x81 | IOAM | This document | 284 +---------------+-------------+---------------+ 286 6. Security Considerations 288 The security considerations of VXLAN-GPE are discussed in 289 [I-D.ietf-nvo3-vxlan-gpe], and the security considerations of IOAM in 290 general are discussed in [I-D.ietf-ippm-ioam-data]. 292 IOAM is considered a "per domain" feature, where one or several 293 operators decide on leveraging and configuring IOAM according to 294 their needs. Still, operators need to properly secure the IOAM 295 domain to avoid malicious configuration and use, which could include 296 injecting malicious IOAM packets into a domain. 298 7. Acknowledgements 300 The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari 301 Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya 302 Nadahalli, Stefano Previdi, Hemant Singh, Erik Nordmark, LJ Wobker, 303 and Andrew Yourtchenko for the comments and advice. 305 8. References 307 8.1. Normative References 309 [ETYPES] "IANA Ethernet Numbers", 310 . 313 [I-D.ietf-ippm-ioam-data] 314 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 315 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 316 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 317 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 318 ietf-ippm-ioam-data-08 (work in progress), October 2019. 320 [I-D.ietf-lisp-gpe] 321 Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. 322 Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- 323 gpe-09 (work in progress), October 2019. 325 [I-D.ietf-nvo3-vxlan-gpe] 326 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 327 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-08 (work 328 in progress), October 2019. 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, 332 DOI 10.17487/RFC2119, March 1997, 333 . 335 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 336 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 337 DOI 10.17487/RFC2784, March 2000, 338 . 340 [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced 341 by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, 342 January 2002, . 344 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 345 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 346 August 2015, . 348 8.2. Informative References 350 [FD.io] "Fast Data Project: FD.io", . 352 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 353 Chaining (SFC) Architecture", RFC 7665, 354 DOI 10.17487/RFC7665, October 2015, 355 . 357 Authors' Addresses 359 Frank Brockners 360 Cisco Systems, Inc. 361 Hansaallee 249, 3rd Floor 362 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 363 Germany 365 Email: fbrockne@cisco.com 367 Shwetha Bhandari 368 Cisco Systems, Inc. 369 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 370 Bangalore, KARNATAKA 560 087 371 India 373 Email: shwethab@cisco.com 375 Vengada Prasad Govindan 376 Cisco Systems, Inc. 378 Email: venggovi@cisco.com 380 Carlos Pignataro 381 Cisco Systems, Inc. 382 7200-11 Kit Creek Road 383 Research Triangle Park, NC 27709 384 United States 386 Email: cpignata@cisco.com 388 Hannes Gredler 389 RtBrick Inc. 391 Email: hannes@rtbrick.com 393 John Leddy 395 Email: john@leddy.net 396 Stephen Youell 397 JP Morgan Chase 398 25 Bank Street 399 London E14 5JP 400 United Kingdom 402 Email: stephen.youell@jpmorgan.com 404 Tal Mizrahi 405 Huawei Network.IO Innovation Lab 406 Israel 408 Email: tal.mizrahi.phd@gmail.com 410 Aviv Kfir 411 Mellanox Technologies, Inc. 412 350 Oakmead Parkway, Suite 100 413 Sunnyvale, CA 94085 414 U.S.A. 416 Email: avivk@mellanox.com 418 Barak Gafni 419 Mellanox Technologies, Inc. 420 350 Oakmead Parkway, Suite 100 421 Sunnyvale, CA 94085 422 U.S.A. 424 Email: gbarak@mellanox.com 426 Petr Lapukhov 427 Facebook 428 1 Hacker Way 429 Menlo Park, CA 94025 430 US 432 Email: petr@fb.com 433 Mickey Spiegel 434 Barefoot Networks 435 2185 Park Boulevard 436 Palo Alto, CA 94306 437 US 439 Email: mspiegel@barefootnetworks.com