idnits 2.17.1 draft-mizrahi-ippm-ioam-profile-02.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 6, 2020) is 1540 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-08 == Outdated reference: A later version (-08) exists of draft-zhou-ippm-ioam-yang-05 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 Smart Platforms iLab 4 Intended status: Informational F. Brockners 5 Expires: August 9, 2020 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 February 6, 2020 20 In Situ OAM Profiles 21 draft-mizrahi-ippm-ioam-profile-02 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 9, 2020. 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 . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 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., Pignataro, C., Gredler, H., 216 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 217 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 218 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 219 ietf-ippm-ioam-data-08 (work in progress), October 2019. 221 [I-D.zhou-ippm-ioam-yang] 222 Zhou, T., Guichard, J., Brockners, F., and S. Raghavan, "A 223 YANG Data Model for In-Situ OAM", draft-zhou-ippm-ioam- 224 yang-05 (work in progress), January 2020. 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 233 A.1. Overview 235 This section presents an example of an IOAM profile specification. 236 The profile makes use of the Hop limit, Node ID and Transit delay 237 data fields, and is thus called the HNT profile for short. 239 A.2. Use Cases 241 This profile is intended for path tracing and transit delay 242 monitoring, while using compact data with just two data fields per 243 packet. The profile can be useful in networks with a large number of 244 hops. 246 A.3. IOAM Options 248 The HNT profile makes use of the Incremental Trace Option. A packet 249 that includes IOAM data according to the current profile includes a 250 single IOAM option - the Incremental Trace Option. Specifically, two 251 data fields are used in this profile: the Hop_Lim and node_id field, 252 and the transit delay field. 254 A.4. IOAM Option Header Field Values 256 The IOAM-Trace-Type field in the header of the Incremental Trace 257 Option in this profile has a fixed value; Bit 0 (the most significant 258 bit) and Bit 4 are set, while the rest of the bits are zero, 259 indicating the two data fields that are used in the option. 261 A.5. Opaque State Snapshot 263 The opaque state snapshot is never used in this profile. Note that 264 the NodeLen field, as defined in [I-D.ietf-ippm-ioam-data], 265 represents the length of the data excluding the opaque state 266 snapshot. Since this field is not used in the current profile, the 267 NodeLen represents the actual length of the data. 269 A.6. Profile Coexistence 271 It is assumed that the current profile is used in a confined 272 administrative domain in which no other IOAM profiles are used. 273 Therefore, it is assumed that the current profile does not coexist 274 with other profiles. 276 A.7. Validity 278 An IOAM transit/decapsulating node that receives a packet with IOAM 279 options that do not comply to the current profile should forward/ 280 decapsulate the packet without IOAM processing, if it is able to do 281 so. If a decapsulating node is not able to decapsulate an IOAM 282 option that is not compliant to the current profile, the packet is 283 discarded. 285 Authors' Addresses 287 Tal Mizrahi 288 Huawei Smart Platforms iLab 289 8-2 Matam 290 Haifa 3190501 291 Israel 293 Email: tal.mizrahi.phd@gmail.com 295 Frank Brockners 296 Cisco Systems, Inc. 297 Hansaallee 249, 3rd Floor 298 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 299 Germany 301 Email: fbrockne@cisco.com 303 Shwetha Bhandari 304 Cisco Systems, Inc. 305 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 306 Bangalore, KARNATAKA 560 087 307 India 309 Email: shwethab@cisco.com 311 Ramesh Sivakolundu 312 Cisco Systems, Inc. 313 170 West Tasman Dr. 314 SAN JOSE, CA 95134 315 U.S.A. 317 Email: sramesh@cisco.com 318 Carlos Pignataro 319 Cisco Systems, Inc. 320 7200-11 Kit Creek Road 321 Research Triangle Park, NC 27709 322 United States 324 Email: cpignata@cisco.com 326 Aviv Kfir 327 Mellanox Technologies, Inc. 328 350 Oakmead Parkway, Suite 100 329 Sunnyvale, CA 94085 330 U.S.A. 332 Email: avivk@mellanox.com 334 Barak Gafni 335 Mellanox Technologies, Inc. 336 350 Oakmead Parkway, Suite 100 337 Sunnyvale, CA 94085 338 U.S.A. 340 Email: gbarak@mellanox.com 342 Mickey Spiegel 343 Barefoot Networks 344 4750 Patrick Henry Drive 345 Santa Clara, CA 95054 346 US 348 Email: mspiegel@barefootnetworks.com 350 Tianran Zhou 351 Huawei 352 156 Beiqing Rd. 353 Beijing 100095 354 China 356 Email: zhoutianran@huawei.com 357 Jennifer Lemon 358 Broadcom 359 270 Innovation Drive 360 San Jose, CA 95134 361 US 363 Email: jennifer.lemon@broadcom.com