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