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