idnits 2.17.1 draft-mizrahi-ippm-ioam-profile-01.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 (September 11, 2019) is 1689 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 222, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-07 == Outdated reference: A later version (-08) exists of draft-zhou-ippm-ioam-yang-04 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 Network.IO Innovation Lab 4 Intended status: Informational F. Brockners 5 Expires: March 14, 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 September 11, 2019 20 In Situ OAM Profiles 21 draft-mizrahi-ippm-ioam-profile-01 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 March 14, 2020. 55 Copyright Notice 57 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 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 [I-D.zhou-ippm-ioam-yang]. It should be noted that 132 while the YANG model assists in the definition of a profile, it does 133 not replace the profile definition. Specifically, a profile 134 definition includes the use case(s) for using the profile, and 135 possibly some properties that cannot be defined by an assignment to 136 the YANG model, such as the semantics of the Opaque State Snapshot 137 field. 139 2.2. Use Cases 141 An IOAM profile should define the use case(s) for using the profile. 142 The use case may describe deployment scenarios or specific 143 applications that make use of IOAM data. The use case should 144 typically define the required functionality from IOAM. For example, 145 an IOAM profile may be defined such that it requires transit delay 146 monitoring, but does not require path tracing. These requirements 147 then affect which IOAM data fields are used in the profile. 149 2.3. IOAM Options 151 IOAM data may be represented in one of four possible IOAM options: 152 Pre-allocated Trace Option, Incremental Trace Option, Proof Of 153 Transit (POT) Option, and Edge-to-Edge Option. An IOAM profile may 154 specify a subset of allowed options. A profile may define some 155 options as mandatory in the current profile, or some options as 156 forbidden in the current profile. Moreover, in cases where IOAM 157 defines several possible modes of operation, a profile may choose one 158 of these modes of operation as the only allowed mode. 160 For each IOAM option, a profile specification may limit the scope of 161 the profile to certain features. For example, a profile may be 162 defined to use the Incremental Trace Option such that only specific 163 data types are used in the profile, while others are not. 165 2.4. IOAM Option Header Field Values 167 An IOAM profile may define specific values or specific value range 168 for some of the fields in the IOAM option headers. For example, a 169 profile may define a specific value that is allowed to be used in the 170 Flags field of the trace option header. 172 2.5. Opaque State Snapshot 174 The Opaque State Snapshot, as defined in [I-D.ietf-ippm-ioam-data], 175 is a variable length field that may be used in IOAM trace options. 176 The Opaque State Snapshot is defined in a flexible Type/Length/Value 177 manner. An IOAM profile may define a specific format for the Opaque 178 State Snapshot including for example a specific length and a specific 179 interpretation of the opaque data. In this case, the IOAM profile 180 ought to also specify a Schema ID value. 182 2.6. Timestamp Format 184 A profile may specify a specific timestamp format to be used in IOAM 185 data fields. 187 3. IANA Considerations 189 This document does not include any requests from IANA. 191 [RFC-Editor Note: feel free to remove this Section.] 193 4. Security Considerations 195 The security considerations of IOAM in general are discussed in 196 [I-D.ietf-ippm-ioam-data]. This document presents the concept of 197 IOAM profiles; since an IOAM profile is a specific use case of IOAM, 198 any security threat that is relevant to the profile is also relevant 199 to the full-blown IOAM, as defined in [I-D.ietf-ippm-ioam-data]. 200 Therefore, the current document does not present any new security 201 considerations beyond [I-D.ietf-ippm-ioam-data]. 203 Moreover, in some cases a profile may limit the set of features of 204 IOAM in a way that reduces the set of potential threats compared to a 205 full implementation of IOAM. In fact, a particular IOAM profile can 206 optimize a particular security posture or requirement. 208 5. Normative References 210 [I-D.ietf-ippm-ioam-data] 211 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 212 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 213 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 214 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 215 data-07 (work in progress), September 2019. 217 [I-D.zhou-ippm-ioam-yang] 218 Zhou, T., Guichard, J., Brockners, F., and S. Raghavan, "A 219 YANG Data Model for In-Situ OAM", draft-zhou-ippm-ioam- 220 yang-04 (work in progress), June 2019. 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, 224 DOI 10.17487/RFC2119, March 1997, 225 . 227 Appendix A. An IOAM Profile Example 229 A.1. Overview 231 This section presents an example of an IOAM profile specification. 232 The profile makes use of the Hop limit, Node ID and Transit delay 233 data fields, and is thus called the HNT profile for short. 235 A.2. Use Cases 237 This profile is intended for path tracing and transit delay 238 monitoring, while using compact data with just two data fields per 239 packet. The profile can be useful in networks with a large number of 240 hops. 242 A.3. IOAM Options 244 The HNT profile makes use of the Incremental Trace Option. A packet 245 that includes IOAM data according to the current profile includes a 246 single IOAM option - the Incremental Trace Option. Specifically, two 247 data fields are used in this profile: the Hop_Lim and node_id field, 248 and the transit delay field. 250 A.4. IOAM Option Header Field Values 252 The IOAM-Trace-Type field in the header of the Incremental Trace 253 Option in this profile has a fixed value; Bit 0 (the most significant 254 bit) and Bit 4 are set, while the rest of the bits are zero, 255 indicating the two data fields that are used in the option. 257 A.5. Opaque State Snapshot 259 The opaque state snapshot is never used in this profile. Note that 260 the NodeLen field, as defined in [I-D.ietf-ippm-ioam-data], 261 represents the length of the data excluding the opaque state 262 snapshot. Since this field is not used in the current profile, the 263 NodeLen represents the actual length of the data. 265 A.6. Profile Coexistence 267 It is assumed that the current profile is used in a confined 268 administrative domain in which no other IOAM profiles are used. 269 Therefore, it is assumed that the current profile does not coexist 270 with other profiles. 272 A.7. Validity 274 An IOAM transit/decapsulating node that receives a packet with IOAM 275 options that do not comply to the current profile should forward/ 276 decapsulate the packet without IOAM processing, if it is able to do 277 so. If a decapsulating node is not able to decapsulate an IOAM 278 option that is not compliant to the current profile, the packet is 279 discarded. 281 Authors' Addresses 283 Tal Mizrahi 284 Huawei Network.IO Innovation Lab 285 Israel 287 Email: tal.mizrahi.phd@gmail.com 289 Frank Brockners 290 Cisco Systems, Inc. 291 Hansaallee 249, 3rd Floor 292 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 293 Germany 295 Email: fbrockne@cisco.com 297 Shwetha Bhandari 298 Cisco Systems, Inc. 299 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 300 Bangalore, KARNATAKA 560 087 301 India 303 Email: shwethab@cisco.com 305 Ramesh Sivakolundu 306 Cisco Systems, Inc. 307 170 West Tasman Dr. 308 SAN JOSE, CA 95134 309 U.S.A. 311 Email: sramesh@cisco.com 313 Carlos Pignataro 314 Cisco Systems, Inc. 315 7200-11 Kit Creek Road 316 Research Triangle Park, NC 27709 317 United States 319 Email: cpignata@cisco.com 320 Aviv Kfir 321 Mellanox Technologies, Inc. 322 350 Oakmead Parkway, Suite 100 323 Sunnyvale, CA 94085 324 U.S.A. 326 Email: avivk@mellanox.com 328 Barak Gafni 329 Mellanox Technologies, Inc. 330 350 Oakmead Parkway, Suite 100 331 Sunnyvale, CA 94085 332 U.S.A. 334 Email: gbarak@mellanox.com 336 Mickey Spiegel 337 Barefoot Networks 338 4750 Patrick Henry Drive 339 Santa Clara, CA 95054 340 US 342 Email: mspiegel@barefootnetworks.com 344 Tianran Zhou 345 Huawei 346 156 Beiqing Rd. 347 Beijing 100095 348 China 350 Email: zhoutianran@huawei.com 352 John Lemon 353 Broadcom 354 270 Innovation Drive 355 San Jose, CA 95134 356 US 358 Email: john.lemon@broadcom.com