idnits 2.17.00 (12 Aug 2021) /tmp/idnits65042/draft-mizrahi-ippm-ioam-profile-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 document date (February 17, 2022) is 86 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 232, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Mizrahi 3 Internet-Draft Huawei 4 Intended status: Informational F. Brockners 5 Expires: August 21, 2022 Cisco 6 S. Bhandari, Ed. 7 Thoughtspot 8 R. Sivakolundu 9 C. Pignataro 10 Cisco 11 A. Kfir 12 B. Gafni 13 Nvidia 14 M. Spiegel 15 Barefoot Networks 16 T. Zhou 17 Huawei 18 February 17, 2022 20 In Situ OAM Profiles 21 draft-mizrahi-ippm-ioam-profile-06 23 Abstract 25 In Situ Operations, Administration and Maintenance (IOAM) is used for 26 monitoring network performance and for detecting traffic bottlenecks 27 and anomalies. This is achieved by incorporating IOAM data into in- 28 flight data packets. This document introduces the concept of use 29 case-driven IOAM profiles. An IOAM profile defines a use case or a 30 set of use cases for IOAM, and an associated set of rules that 31 restrict the scope and features of the IOAM specification, thereby 32 limiting it to a subset of the full functionality. The motivation 33 for defining profiles is to limit the scope of IOAM features, 34 allowing simpler implementation, verification, and interoperability 35 testing in the context of specific use cases that do not require the 36 full functionality of IOAM. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on August 21, 2022. 55 Copyright Notice 57 Copyright (c) 2022 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Specifying an IOAM Profile . . . . . . . . . . . . . . . . . 3 74 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2.3. IOAM Options . . . . . . . . . . . . . . . . . . . . . . 4 77 2.4. IOAM Option Header Field Values . . . . . . . . . . . . . 4 78 2.5. Opaque State Snapshot . . . . . . . . . . . . . . . . . . 4 79 2.6. Timestamp Format . . . . . . . . . . . . . . . . . . . . 5 80 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 82 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 84 5.2. Informative References . . . . . . . . . . . . . . . . . 6 85 Appendix A. An IOAM Profile Example . . . . . . . . . . . . . . 6 86 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 87 A.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 88 A.3. IOAM Options . . . . . . . . . . . . . . . . . . . . . . 6 89 A.4. IOAM Option Header Field Values . . . . . . . . . . . . . 6 90 A.5. Opaque State Snapshot . . . . . . . . . . . . . . . . . . 6 91 A.6. Profile Coexistence . . . . . . . . . . . . . . . . . . . 7 92 A.7. Validity . . . . . . . . . . . . . . . . . . . . . . . . 7 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 95 1. Introduction 97 IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the 98 network by incorporating IOAM data fields into in-flight data 99 packets. 101 This document introduces the concept of use case driven IOAM 102 profiles. The motivation for defining profiles is to limit the scope 103 of IOAM features, allowing simpler implementation, verification, and 104 interoperability testing in the context of specific use cases that do 105 not require the full functionality of IOAM. 107 An IOAM profile defines a use case or a set of use cases for IOAM, 108 and an associated set of rules that restrict the scope and features 109 of the IOAM specification, thereby limiting it to a subset of the 110 full functionality. Based on the guidelines in this document, future 111 documents may define one or more IOAM profiles. The current document 112 does not specify any IOAM profiles. 114 This document does not require any changes to the Data Fields for In- 115 situ OAM [I-D.ietf-ippm-ioam-data]. Furthermore, it is expected that 116 future IOAM profile specifications will not require changes to IOAM, 117 since a profile, by definition, derives a subset of the existing 118 functionality. 120 The Linux IOAM profile [I-D.mizrahi-ippm-ioam-linux-profile] was 121 implemented in the Linux kernel starting from version 5.15. Another 122 example of an IOAM profile is presented in Appendix A. 124 2. Specifying an IOAM Profile 126 2.1. Overview 128 A profile defines a set of rules that limit the scope or 129 functionality of IOAM. By default, any detail in IOAM that is not 130 specifically addressed or limited by the profile is as defined in 131 IOAM [I-D.ietf-ippm-ioam-data]. The rest of this section presents a 132 set of topics that may be addressed in a profile specification. A 133 profile may include some or all of these topics, and optionally other 134 topics. 136 A profile may in part be defined using a specific assignment to the 137 IOAM YANG model. The IOAM YANG model [I-D.ietf-ippm-ioam-yang] 138 defines a set of IOAM-related attributes, such as which IOAM option 139 types are enabled, and which data fields are used. For example, an 140 IOAM profile that only uses the icremental trace option may be 141 defined as such by an assignment to the respective attributes that 142 are defined in the YANG model. It should be noted that while the 143 YANG model assists in the definition of a profile, it does not 144 replace the profile definition. Specifically, a profile definition 145 includes the use case(s) for using the profile, and possibly some 146 properties that cannot be defined by an assignment to the YANG model, 147 such as the semantics of the Opaque State Snapshot field. 149 2.2. Use Cases 151 An IOAM profile should define the use case(s) for using the profile. 152 The use case may describe deployment scenarios or specific 153 applications that make use of IOAM data. The use case should 154 typically define the required functionality from IOAM. For example, 155 an IOAM profile may be defined such that it requires transit delay 156 monitoring, but does not require path tracing. These requirements 157 then affect which IOAM data fields are used in the profile. 159 2.3. IOAM Options 161 IOAM data may be represented in one of four possible IOAM options: 162 Pre-allocated Trace Option, Incremental Trace Option, Proof Of 163 Transit (POT) Option, and Edge-to-Edge Option. An IOAM profile may 164 specify a subset of allowed options. A profile may define some 165 options as mandatory in the current profile, or some options as 166 forbidden in the current profile. Moreover, in cases where IOAM 167 defines several possible modes of operation, a profile may choose one 168 of these modes of operation as the only allowed mode. 170 For each IOAM option, a profile specification may limit the scope of 171 the profile to certain features. For example, a profile may be 172 defined to use the Incremental Trace Option such that only specific 173 data types are used in the profile, while others are not. 175 2.4. IOAM Option Header Field Values 177 An IOAM profile may define specific values or specific value range 178 for some of the fields in the IOAM option headers. For example, a 179 profile may define a specific value that is allowed to be used in the 180 Flags field of the trace option header. 182 2.5. Opaque State Snapshot 184 The Opaque State Snapshot, as defined in [I-D.ietf-ippm-ioam-data], 185 is a variable length field that may be used in IOAM trace options. 186 The Opaque State Snapshot is defined in a flexible Type/Length/Value 187 manner. An IOAM profile may define a specific format for the Opaque 188 State Snapshot including for example a specific length and a specific 189 interpretation of the opaque data. In this case, the IOAM profile 190 ought to also specify a Schema ID value. 192 2.6. Timestamp Format 194 A profile may specify a specific timestamp format to be used in IOAM 195 data fields. 197 3. IANA Considerations 199 This document does not include any requests from IANA. 201 [RFC-Editor Note: feel free to remove this Section.] 203 4. Security Considerations 205 The security considerations of IOAM in general are discussed in 206 [I-D.ietf-ippm-ioam-data]. This document presents the concept of 207 IOAM profiles; since an IOAM profile is a specific use case of IOAM, 208 any security threat that is relevant to the profile is also relevant 209 to the full-blown IOAM, as defined in [I-D.ietf-ippm-ioam-data]. 210 Therefore, the current document does not present any new security 211 considerations beyond [I-D.ietf-ippm-ioam-data]. 213 Moreover, in some cases a profile may limit the set of features of 214 IOAM in a way that reduces the set of potential threats compared to a 215 full implementation of IOAM. In fact, a particular IOAM profile can 216 optimize a particular security posture or requirement. 218 5. References 220 5.1. Normative References 222 [I-D.ietf-ippm-ioam-data] 223 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 224 for In-situ OAM", draft-ietf-ippm-ioam-data-17 (work in 225 progress), December 2021. 227 [I-D.ietf-ippm-ioam-yang] 228 Zhou, T., Guichard, J., Brockners, F., and S. Raghavan, "A 229 YANG Data Model for In-Situ OAM", draft-ietf-ippm-ioam- 230 yang-03 (work in progress), January 2022. 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, 234 DOI 10.17487/RFC2119, March 1997, 235 . 237 5.2. Informative References 239 [I-D.mizrahi-ippm-ioam-linux-profile] 240 Mizrahi, T., Iurman, J., and F. Brockners, "In Situ OAM 241 Profile for the Linux Kernel Implementation", draft- 242 mizrahi-ippm-ioam-linux-profile-02 (work in progress), 243 January 2022. 245 Appendix A. An IOAM Profile Example 247 A.1. Overview 249 This section presents an example of an IOAM profile specification. 250 The profile makes use of the Hop limit, Node ID and Transit delay 251 data fields, and is thus called the HNT profile for short. 253 A.2. Use Cases 255 This profile is intended for path tracing and transit delay 256 monitoring, while using compact data with just two data fields per 257 packet. The profile can be useful in networks with a large number of 258 hops. 260 A.3. IOAM Options 262 The HNT profile makes use of the Incremental Trace Option. A packet 263 that includes IOAM data according to the current profile includes a 264 single IOAM option - the Incremental Trace Option. Specifically, two 265 data fields are used in this profile: the Hop_Lim and node_id field, 266 and the transit delay field. 268 A.4. IOAM Option Header Field Values 270 The IOAM-Trace-Type field in the header of the Incremental Trace 271 Option in this profile has a fixed value; Bit 0 (the most significant 272 bit) and Bit 4 are set, while the rest of the bits are zero, 273 indicating the two data fields that are used in the option. 275 A.5. Opaque State Snapshot 277 The opaque state snapshot is never used in this profile. Note that 278 the NodeLen field, as defined in [I-D.ietf-ippm-ioam-data], 279 represents the length of the data excluding the opaque state 280 snapshot. Since this field is not used in the current profile, the 281 NodeLen represents the actual length of the data. 283 A.6. Profile Coexistence 285 It is assumed that the current profile is used in a confined 286 administrative domain in which no other IOAM profiles are used. 287 Therefore, it is assumed that the current profile does not coexist 288 with other profiles. 290 A.7. Validity 292 An IOAM transit/decapsulating node that receives a packet with IOAM 293 options that do not comply to the current profile should forward/ 294 decapsulate the packet without IOAM processing, if it is able to do 295 so. If a decapsulating node is not able to decapsulate an IOAM 296 option that is not compliant to the current profile, the packet is 297 discarded. 299 Authors' Addresses 301 Tal Mizrahi 302 Huawei 303 8-2 Matam 304 Haifa 3190501 305 Israel 307 Email: tal.mizrahi.phd@gmail.com 309 Frank Brockners 310 Cisco Systems, Inc. 311 Hansaallee 249, 3rd Floor 312 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 313 Germany 315 Email: fbrockne@cisco.com 317 Shwetha Bhandari (editor) 318 Thoughtspot 319 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 320 Bangalore, KARNATAKA 560 102 321 India 323 Email: shwetha.bhandari@thoughtspot.com 324 Ramesh Sivakolundu 325 Cisco Systems, Inc. 326 170 West Tasman Dr. 327 SAN JOSE, CA 95134 328 U.S.A. 330 Email: sramesh@cisco.com 332 Carlos Pignataro 333 Cisco Systems, Inc. 334 7200-11 Kit Creek Road 335 Research Triangle Park, NC 27709 336 United States 338 Email: cpignata@cisco.com 340 Aviv Kfir 341 Nvidia 343 Email: avivk@nvidia.com 345 Barak Gafni 346 Nvidia 347 350 Oakmead Parkway, Suite 100 348 Sunnyvale, CA 94085 349 U.S.A. 351 Email: gbarak@nvidia.com 353 Mickey Spiegel 354 Barefoot Networks 355 4750 Patrick Henry Drive 356 Santa Clara, CA 95054 357 US 359 Email: mspiegel@barefootnetworks.com 360 Tianran Zhou 361 Huawei 362 156 Beiqing Rd. 363 Beijing 100095 364 China 366 Email: zhoutianran@huawei.com