idnits 2.17.1 draft-mizrahi-ippm-ioam-profile-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 (August 5, 2020) is 1354 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 224, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 Summary: 0 errors (**), 0 flaws (~~), 3 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 Smart Platforms iLab 4 Intended status: Informational F. Brockners 5 Expires: February 6, 2021 S. Bhandari 6 R. Sivakolundu 7 C. Pignataro 8 Cisco 9 A. Kfir 10 B. Gafni 11 Mellanox Technologies, Inc. 12 M. Spiegel 13 Barefoot Networks 14 T. Zhou 15 Huawei 16 J. Lemon 17 Broadcom 18 August 5, 2020 20 In Situ OAM Profiles 21 draft-mizrahi-ippm-ioam-profile-03 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 February 6, 2021. 55 Copyright Notice 57 Copyright (c) 2020 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. Normative References . . . . . . . . . . . . . . . . . . . . 5 83 Appendix A. An IOAM Profile Example . . . . . . . . . . . . . . 5 84 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 85 A.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 86 A.3. IOAM Options . . . . . . . . . . . . . . . . . . . . . . 6 87 A.4. IOAM Option Header Field Values . . . . . . . . . . . . . 6 88 A.5. Opaque State Snapshot . . . . . . . . . . . . . . . . . . 6 89 A.6. Profile Coexistence . . . . . . . . . . . . . . . . . . . 6 90 A.7. Validity . . . . . . . . . . . . . . . . . . . . . . . . 6 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 93 1. Introduction 95 IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the 96 network by incorporating IOAM data fields into in-flight data 97 packets. 99 This document introduces the concept of use case driven IOAM 100 profiles. The motivation for defining profiles is to limit the scope 101 of IOAM features, allowing simpler implementation, verification, and 102 interoperability testing in the context of specific use cases that do 103 not require the full functionality of IOAM. 105 An IOAM profile defines a use case or a set of use cases for IOAM, 106 and an associated set of rules that restrict the scope and features 107 of the IOAM specification, thereby limiting it to a subset of the 108 full functionality. Based on the guidelines in this document, future 109 documents may define one or more IOAM profiles. The current document 110 does not specify any IOAM profiles. 112 This document does not require any changes to the Data Fields for In- 113 situ OAM [I-D.ietf-ippm-ioam-data]. Furthermore, it is expected that 114 future IOAM profile specifications will not require changes to IOAM, 115 since a profile, by definition, derives a subset of the existing 116 functionality. 118 2. Specifying an IOAM Profile 120 2.1. Overview 122 A profile defines a set of rules that limit the scope or 123 functionality of IOAM. By default, any detail in IOAM that is not 124 specifically addressed or limited by the profile is as defined in 125 IOAM [I-D.ietf-ippm-ioam-data]. The rest of this section presents a 126 set of topics that may be addressed in a profile specification. A 127 profile may include some or all of these topics, and optionally other 128 topics. 130 A profile may in part be defined using a specific assignment to the 131 IOAM YANG model. The IOAM YANG model [I-D.zhou-ippm-ioam-yang] 132 defines a set of IOAM-related attributes, such as which IOAM option 133 types are enabled, and which data fields are used. For example, an 134 IOAM profile that only uses the icremental trace option may be 135 defined as such by an assignment to the respective attributes that 136 are defined in the YANG model. It should be noted that while the 137 YANG model assists in the definition of a profile, it does not 138 replace the profile definition. Specifically, a profile definition 139 includes the use case(s) for using the profile, and possibly some 140 properties that cannot be defined by an assignment to the YANG model, 141 such as the semantics of the Opaque State Snapshot field. 143 2.2. Use Cases 145 An IOAM profile should define the use case(s) for using the profile. 146 The use case may describe deployment scenarios or specific 147 applications that make use of IOAM data. The use case should 148 typically define the required functionality from IOAM. For example, 149 an IOAM profile may be defined such that it requires transit delay 150 monitoring, but does not require path tracing. These requirements 151 then affect which IOAM data fields are used in the profile. 153 2.3. IOAM Options 155 IOAM data may be represented in one of four possible IOAM options: 156 Pre-allocated Trace Option, Incremental Trace Option, Proof Of 157 Transit (POT) Option, and Edge-to-Edge Option. An IOAM profile may 158 specify a subset of allowed options. A profile may define some 159 options as mandatory in the current profile, or some options as 160 forbidden in the current profile. Moreover, in cases where IOAM 161 defines several possible modes of operation, a profile may choose one 162 of these modes of operation as the only allowed mode. 164 For each IOAM option, a profile specification may limit the scope of 165 the profile to certain features. For example, a profile may be 166 defined to use the Incremental Trace Option such that only specific 167 data types are used in the profile, while others are not. 169 2.4. IOAM Option Header Field Values 171 An IOAM profile may define specific values or specific value range 172 for some of the fields in the IOAM option headers. For example, a 173 profile may define a specific value that is allowed to be used in the 174 Flags field of the trace option header. 176 2.5. Opaque State Snapshot 178 The Opaque State Snapshot, as defined in [I-D.ietf-ippm-ioam-data], 179 is a variable length field that may be used in IOAM trace options. 180 The Opaque State Snapshot is defined in a flexible Type/Length/Value 181 manner. An IOAM profile may define a specific format for the Opaque 182 State Snapshot including for example a specific length and a specific 183 interpretation of the opaque data. In this case, the IOAM profile 184 ought to also specify a Schema ID value. 186 2.6. Timestamp Format 188 A profile may specify a specific timestamp format to be used in IOAM 189 data fields. 191 3. IANA Considerations 193 This document does not include any requests from IANA. 195 [RFC-Editor Note: feel free to remove this Section.] 197 4. Security Considerations 199 The security considerations of IOAM in general are discussed in 200 [I-D.ietf-ippm-ioam-data]. This document presents the concept of 201 IOAM profiles; since an IOAM profile is a specific use case of IOAM, 202 any security threat that is relevant to the profile is also relevant 203 to the full-blown IOAM, as defined in [I-D.ietf-ippm-ioam-data]. 204 Therefore, the current document does not present any new security 205 considerations beyond [I-D.ietf-ippm-ioam-data]. 207 Moreover, in some cases a profile may limit the set of features of 208 IOAM in a way that reduces the set of potential threats compared to a 209 full implementation of IOAM. In fact, a particular IOAM profile can 210 optimize a particular security posture or requirement. 212 5. Normative References 214 [I-D.ietf-ippm-ioam-data] 215 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 216 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 217 progress), July 2020. 219 [I-D.zhou-ippm-ioam-yang] 220 Zhou, T., Guichard, J., Brockners, F., and S. Raghavan, "A 221 YANG Data Model for In-Situ OAM", draft-zhou-ippm-ioam- 222 yang-08 (work in progress), July 2020. 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, 226 DOI 10.17487/RFC2119, March 1997, 227 . 229 Appendix A. An IOAM Profile Example 230 A.1. Overview 232 This section presents an example of an IOAM profile specification. 233 The profile makes use of the Hop limit, Node ID and Transit delay 234 data fields, and is thus called the HNT profile for short. 236 A.2. Use Cases 238 This profile is intended for path tracing and transit delay 239 monitoring, while using compact data with just two data fields per 240 packet. The profile can be useful in networks with a large number of 241 hops. 243 A.3. IOAM Options 245 The HNT profile makes use of the Incremental Trace Option. A packet 246 that includes IOAM data according to the current profile includes a 247 single IOAM option - the Incremental Trace Option. Specifically, two 248 data fields are used in this profile: the Hop_Lim and node_id field, 249 and the transit delay field. 251 A.4. IOAM Option Header Field Values 253 The IOAM-Trace-Type field in the header of the Incremental Trace 254 Option in this profile has a fixed value; Bit 0 (the most significant 255 bit) and Bit 4 are set, while the rest of the bits are zero, 256 indicating the two data fields that are used in the option. 258 A.5. Opaque State Snapshot 260 The opaque state snapshot is never used in this profile. Note that 261 the NodeLen field, as defined in [I-D.ietf-ippm-ioam-data], 262 represents the length of the data excluding the opaque state 263 snapshot. Since this field is not used in the current profile, the 264 NodeLen represents the actual length of the data. 266 A.6. Profile Coexistence 268 It is assumed that the current profile is used in a confined 269 administrative domain in which no other IOAM profiles are used. 270 Therefore, it is assumed that the current profile does not coexist 271 with other profiles. 273 A.7. Validity 275 An IOAM transit/decapsulating node that receives a packet with IOAM 276 options that do not comply to the current profile should forward/ 277 decapsulate the packet without IOAM processing, if it is able to do 278 so. If a decapsulating node is not able to decapsulate an IOAM 279 option that is not compliant to the current profile, the packet is 280 discarded. 282 Authors' Addresses 284 Tal Mizrahi 285 Huawei Smart Platforms iLab 286 8-2 Matam 287 Haifa 3190501 288 Israel 290 Email: tal.mizrahi.phd@gmail.com 292 Frank Brockners 293 Cisco Systems, Inc. 294 Hansaallee 249, 3rd Floor 295 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 296 Germany 298 Email: fbrockne@cisco.com 300 Shwetha Bhandari 301 Cisco Systems, Inc. 302 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 303 Bangalore, KARNATAKA 560 087 304 India 306 Email: shwethab@cisco.com 308 Ramesh Sivakolundu 309 Cisco Systems, Inc. 310 170 West Tasman Dr. 311 SAN JOSE, CA 95134 312 U.S.A. 314 Email: sramesh@cisco.com 315 Carlos Pignataro 316 Cisco Systems, Inc. 317 7200-11 Kit Creek Road 318 Research Triangle Park, NC 27709 319 United States 321 Email: cpignata@cisco.com 323 Aviv Kfir 324 Mellanox Technologies, Inc. 325 350 Oakmead Parkway, Suite 100 326 Sunnyvale, CA 94085 327 U.S.A. 329 Email: avivk@mellanox.com 331 Barak Gafni 332 Mellanox Technologies, Inc. 333 350 Oakmead Parkway, Suite 100 334 Sunnyvale, CA 94085 335 U.S.A. 337 Email: gbarak@mellanox.com 339 Mickey Spiegel 340 Barefoot Networks 341 4750 Patrick Henry Drive 342 Santa Clara, CA 95054 343 US 345 Email: mspiegel@barefootnetworks.com 347 Tianran Zhou 348 Huawei 349 156 Beiqing Rd. 350 Beijing 100095 351 China 353 Email: zhoutianran@huawei.com 354 Jennifer Lemon 355 Broadcom 356 270 Innovation Drive 357 San Jose, CA 95134 358 US 360 Email: jennifer.lemon@broadcom.com