idnits 2.17.1 draft-ietf-sfc-ioam-nsh-06.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 (July 31, 2021) is 997 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) == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-14 ** Downref: Normative reference to an Experimental draft: draft-ietf-sfc-proof-of-transit (ref. 'I-D.ietf-sfc-proof-of-transit') Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC F. Brockners, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track S. Bhandari, Ed. 5 Expires: February 1, 2022 Thoughtspot 6 July 31, 2021 8 Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data 9 draft-ietf-sfc-ioam-nsh-06 11 Abstract 13 In-situ Operations, Administration, and Maintenance (IOAM) records 14 operational and telemetry information in the packet while the packet 15 traverses a path between two points in the network. This document 16 outlines how IOAM data fields are encapsulated in the Network Service 17 Header (NSH). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 1, 2022. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. IOAM data fields encapsulation in NSH . . . . . . . . . . . . 3 56 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Discussion of the encapsulation approach . . . . . . . . 4 58 4.2. IOAM and the use of the NSH O-bit . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 9.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 In-situ OAM (IOAM), as defined in [I-D.ietf-ippm-ioam-data], records 71 OAM information within the packet while the packet traverses a 72 particular network domain. The term "in-situ" refers to the fact 73 that the OAM data is added to the data packets rather than is being 74 sent within packets specifically dedicated to OAM. This document 75 defines how IOAM data fields are transported as part of the Network 76 Service Header (NSH) [RFC8300] encapsulation for the Service Function 77 Chaining (SFC) [RFC7665]. The IOAM-Data-Fields are defined in 78 [I-D.ietf-ippm-ioam-data]. An implementation of IOAM which leverages 79 NSH to carry the IOAM data is available from the FD.io open source 80 software project [FD.io]. 82 2. Conventions 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in BCP 87 14 [RFC2119] [RFC8174] when, and only when, they appear in all 88 capitals, as shown here. 90 Abbreviations used in this document: 92 IOAM: In-situ Operations, Administration, and Maintenance 94 NSH: Network Service Header 95 OAM: Operations, Administration, and Maintenance 97 SFC: Service Function Chaining 99 TLV: Type, Length, Value 101 3. IOAM data fields encapsulation in NSH 103 The NSH is defined in [RFC8300]. IOAM-Data-Fields are carried in NSH 104 using a next protocol header which follows the NSH MD context 105 headers. An IOAM header is added containing the different IOAM-Data- 106 Fields. The IOAM-Data-Fields MUST follow the definitions in 107 [I-D.ietf-ippm-ioam-data]. If "proof-of-transit" is used in 108 conjunction with NSH, the implementation of proof of transit MUST 109 follow [I-D.ietf-sfc-proof-of-transit]. In an administrative domain 110 where IOAM is used, insertion of the IOAM header in NSH is enabled at 111 the NSH tunnel endpoints, which also serve as IOAM encapsulating/ 112 decapsulating nodes by means of configuration. 114 0 1 2 3 115 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 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 117 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| NP = TBD_IOAM | | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 119 | Service Path Identifier | Service Index | S 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 121 | ... | | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 123 | IOAM-Type | IOAM HDR len | Reserved | Next Protocol | | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 125 ! | O 126 ! | A 127 ~ IOAM Option and Data Space ~ M 128 | | | 129 | | | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 131 | | 132 | | 133 | Payload + Padding (L2/L3/ESP/...) | 134 | | 135 | | 136 | | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 The NSH header and fields are defined in [RFC8300]. The "NSH Next 140 Protocol" value (referred to as "NP" in the diagram above) is 141 TBD_IOAM. 143 The IOAM related fields in NSH are defined as follows: 145 IOAM-Type: 8-bit field defining the IOAM-Option-Type, as defined 146 in the IOAM Option-Type Registry (see Section 7.2 of 147 [I-D.ietf-ippm-ioam-data]). 149 IOAM HDR Len: 8 bit Length field contains the length of the IOAM 150 header in 4-octet units. 152 Reserved bits: Reserved bits are present for future use. The 153 reserved bits MUST be set to 0x0 upon transmission and ignored 154 upon receipt. 156 Next Protocol: 8-bit unsigned integer that determines the type of 157 header following IOAM. The semantics of this field are 158 identical to the Next Protocol field in [RFC8300]. 160 IOAM Option and Data Space: IOAM-Option-Type and IOAM-Data-Field 161 as specified by the IOAM-Type field are present (see Section 4 162 of [I-D.ietf-ippm-ioam-data]). 164 Multiple IOAM-Option-Types MAY be included within the NSH 165 encapsulation. For example, if a NSH encapsulation contains two 166 IOAM-Option-Types before a data payload, the Next Protocol field of 167 the first IOAM option will contain the value of TBD_IOAM, while the 168 Next Protocol field of the second IOAM-Option-Type will contain the 169 "NSH Next Protocol" number indicating the type of the data payload. 171 4. Considerations 173 This section summarizes a set of considerations on the overall 174 approach taken for IOAM data encapsulation in NSH, as well as 175 deployment considerations. 177 4.1. Discussion of the encapsulation approach 179 This section discusses several approaches for encapsulating IOAM- 180 Data-Fields in NSH and presents the rationale for the approach chosen 181 in this document. 183 An encapsulation of IOAM-Data-Fields in NSH should be friendly to an 184 implementation in both hardware as well as software forwarders and 185 support a wide range of deployment cases, including large networks 186 that desire to leverage multiple IOAM-Data-Fields at the same time. 188 Hardware and software friendly implementation: Hardware forwarders 189 benefit from an encapsulation that minimizes iterative look-ups of 190 fields within the packet: Any operation which looks up the value of a 191 field within the packet, based on which another lookup is performed, 192 consumes additional gates and time in an implementation - both of 193 which are desired to be kept to a minimum. This means that flat TLV 194 structures are to be preferred over nested TLV structures. IOAM- 195 Data-Fields are grouped into several categories, including trace, 196 proof-of-transit, and edge-to-edge. Each of these options defines a 197 TLV structure. A hardware-friendly encapsulation approach avoids 198 grouping these three option categories into yet another TLV 199 structure, but would rather carry the options as a serial sequence. 201 Total length of the IOAM-Data-Fields: The total length of IOAM-Data- 202 Fields can grow quite large in case multiple different IOAM-Data- 203 Fields are used and large path-lengths need to be considered. If for 204 example an operator would consider using the IOAM Trace Option-Type 205 and capture node-id, app_data, egress/ingress interface-id, timestamp 206 seconds, timestamps nanoseconds at every hop, then a total of 20 207 octets would be added to the packet at every hop. In case this 208 particular deployment would have a maximum path length of 15 hops in 209 the IOAM domain, then a maximum of 300 octets were to be encapsulated 210 in the packet. 212 Different approaches for encapsulating IOAM-Data-Fields in NSH could 213 be considered: 215 1. Encapsulation of IOAM-Data-Fields as "NSH MD Type 2" (see 216 [RFC8300], Section 2.5). Each IOAM-Option-Type (e.g. trace, 217 proof-of-transit, and edge-to-edge) would be specified by a type, 218 with the different IOAM-Data-Fields being TLVs within this the 219 particular option type. NSH MD Type 2 offers support for 220 variable length meta-data. The length field is 6-bits, resulting 221 in a maximum of 256 (2^6 x 4) octets. 223 2. Encapsulation of IOAM-Data-Fields using the "Next Protocol" 224 field. Each IOAM-Option-Type (e.g trace, proof-of-transit, and 225 edge-to-edge) would be specified by its own "next protocol". 227 3. Encapsulation of IOAM-Data-Fields using the "Next Protocol" 228 field. A single NSH protocol type code point would be allocated 229 for IOAM. A "sub-type" field would then specify what IOAM 230 options type (trace, proof-of-transit, edge-to-edge) is carried. 232 The third option has been chosen here. This option avoids the 233 additional layer of TLV nesting that the use of NSH MD Type 2 would 234 result in. In addition, this option does not constrain IOAM data to 235 a maximum of 256 octets, thus allowing support for very large 236 deployments. 238 4.2. IOAM and the use of the NSH O-bit 240 [RFC8300] defines an "O bit" for OAM packets. Per [RFC8300] the O 241 bit must be set for OAM packets and must not be set for non-OAM 242 packets. Packets with IOAM data included MUST follow this 243 definition, i.e. the O bit MUST NOT be set for regular customer 244 traffic which also carries IOAM data and the O bit MUST be set for 245 OAM packets which carry only IOAM data without any regular data 246 payload. 248 5. IANA Considerations 250 IANA is requested to allocate protocol numbers for the following "NSH 251 Next Protocol" related to IOAM: 253 +---------------+-------------+---------------+ 254 | Next Protocol | Description | Reference | 255 +---------------+-------------+---------------+ 256 | x | TBD_IOAM | This document | 257 +---------------+-------------+---------------+ 259 6. Security Considerations 261 IOAM is considered a "per domain" feature, where one or several 262 operators decide on leveraging and configuring IOAM according to 263 their needs. Still, operators need to properly secure the IOAM 264 domain to avoid malicious configuration and use, which could include 265 injecting malicious IOAM packets into a domain. For additional IOAM 266 related security considerations, see Section 8 in 267 [I-D.ietf-ippm-ioam-data]. For proof of transit related security 268 considerations, see Section 7 in [I-D.ietf-sfc-proof-of-transit]. 270 7. Acknowledgements 272 The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari 273 Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya 274 Nadahalli, Stefano Previdi, Hemant Singh, Erik Nordmark, LJ Wobker, 275 and Andrew Yourtchenko for the comments and advice. 277 8. Contributors 279 In addition to editors listed on the title page, the following people 280 have contributed to this document: 282 Vengada Prasad Govindan 283 Cisco Systems, Inc. 284 Email: venggovi@cisco.com 286 Carlos Pignataro 287 Cisco Systems, Inc. 288 7200-11 Kit Creek Road 289 Research Triangle Park, NC 27709 290 United States 291 Email: cpignata@cisco.com 293 Hannes Gredler 294 RtBrick Inc. 295 Email: hannes@rtbrick.com 297 John Leddy 298 Email: john@leddy.net 300 Stephen Youell 301 JP Morgan Chase 302 25 Bank Street 303 London E14 5JP 304 United Kingdom 305 Email: stephen.youell@jpmorgan.com 307 Tal Mizrahi 308 Huawei Network.IO Innovation Lab 309 Israel 310 Email: tal.mizrahi.phd@gmail.com 312 David Mozes 313 Email: mosesster@gmail.com 315 Petr Lapukhov 316 Facebook 317 1 Hacker Way 318 Menlo Park, CA 94025 319 US 320 Email: petr@fb.com 321 Remy Chang 322 Barefoot Networks 323 2185 Park Boulevard 324 Palo Alto, CA 94306 325 US 327 9. References 329 9.1. Normative References 331 [I-D.ietf-ippm-ioam-data] 332 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 333 for In-situ OAM", draft-ietf-ippm-ioam-data-14 (work in 334 progress), June 2021. 336 [I-D.ietf-sfc-proof-of-transit] 337 Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. 338 Youell, "Proof of Transit", draft-ietf-sfc-proof-of- 339 transit-08 (work in progress), November 2020. 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, 343 DOI 10.17487/RFC2119, March 1997, 344 . 346 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 347 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 348 May 2017, . 350 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 351 "Network Service Header (NSH)", RFC 8300, 352 DOI 10.17487/RFC8300, January 2018, 353 . 355 9.2. Informative References 357 [FD.io] "Fast Data Project: FD.io", . 359 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 360 Chaining (SFC) Architecture", RFC 7665, 361 DOI 10.17487/RFC7665, October 2015, 362 . 364 Authors' Addresses 366 Frank Brockners (editor) 367 Cisco Systems, Inc. 368 Hansaallee 249, 3rd Floor 369 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 370 Germany 372 Email: fbrockne@cisco.com 374 Shwetha Bhandari (editor) 375 Thoughtspot 376 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 377 Bangalore, KARNATAKA 560 102 378 India 380 Email: shwetha.bhandari@thoughtspot.com