idnits 2.17.1 draft-mirsky-rtgwg-oam-identify-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 (March 6, 2019) is 1870 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-bier-pmmm-oam-05 == Outdated reference: A later version (-09) exists of draft-ietf-intarea-gue-06 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-10 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-06 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-00 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-multi-layer-oam-01 == Outdated reference: A later version (-15) exists of draft-ietf-sfc-oam-framework-05 == Outdated reference: A later version (-15) exists of draft-mirsky-ippm-hybrid-two-step-02 == Outdated reference: A later version (-14) exists of draft-mirsky-sfc-pmamm-06 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Informational March 6, 2019 5 Expires: September 7, 2019 7 Identification of Overlay Operations, Administration, and Maintenance 8 (OAM) 9 draft-mirsky-rtgwg-oam-identify-02 11 Abstract 13 This document analyzes how the presence of Operations, 14 Administration, and Maintenance (OAM) control command and/or special 15 data is identified in some overlay networks and an impact on the 16 choice of identification may have on OAM functionality. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 7, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions used in this document . . . . . . . . . . . . . . 3 54 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Overlay Network Encapsulations . . . . . . . . . . . . . . . . 4 57 3.1. Encapsulations with Meta-data . . . . . . . . . . . . . . 4 58 3.1.1. Available Solutions . . . . . . . . . . . . . . . . . 5 59 3.2. Fixed-size Encapsulations . . . . . . . . . . . . . . . . 6 60 3.3. Source Information Availability . . . . . . . . . . . . . 7 61 3.4. On-path OAM . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 68 8.2. Informational References . . . . . . . . . . . . . . . . . 9 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 Operations, Administration, and Maintenance (OAM) protocols are used 74 to detect, localize defects in the network, and monitor network 75 performance. Some OAM functions, e.g., failure detection, work in 76 the network proactively, while others, e.g., defect localization, 77 usually performed on-demand. These tasks achieved by a combination 78 of active, passive, and hybrid OAM methods, as defined in [RFC7799]. 80 This document analyzes how the presence of Operations, 81 Administration, and Maintenance (OAM) control command and/or special 82 data, i.e., OAM packet, is identified in some overlay networks, and 83 an impact the choice of identification may have on OAM functionality 84 of active and hybrid OAM methods for the respective overlay network 85 encapsulation. 87 2. Conventions used in this document 89 2.1. Terminology 91 AMM Alternate Marking method 93 BIER Bit Indexed Explicit Replication 95 DetNet Deterministic Networks 97 GUE Generic UDP Encapsulation 99 HTS Hybrid Two-step 101 NSH Network Service Header 103 NVO3 Network Virtualization Overlays 105 OAM Operations, Administration and Maintenance 107 SFC Service Function Chaining 109 TLV Type-Length-Value 111 VXLAN-GPE Generic Protocol Extension for VXLAN 113 Underlay Network or Underlay Layer: The network that provides 114 connectivity between the DetNet nodes. MPLS network that provides 115 LSP connectivity between DetNet nodes is an example of an underlay 116 layer. 118 2.2. Keywords 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 3. Overlay Network Encapsulations 128 New overlay network encapsulations analyzed in two groups: 130 o encapsulations that support optional meta-data; 132 o fixed-size encapsulations. 134 3.1. Encapsulations with Meta-data 136 Number of the new encapsulation protocols (e.g., Geneve 137 [I-D.ietf-nvo3-geneve], GUE [I-D.ietf-intarea-gue], and SFC NSH 138 [RFC8300]) support use of Type-Length-Value (TLV) encoding to include 139 optional information into the header. The identification of OAM in 140 these protocols is as the following: 142 Geneve: 144 O (1 bit): after the WGLC discussion, the interpretation of the 145 O field has changed. The O field now identifies a control 146 packet. This packet contains a control message. Control 147 messages are sent between tunnel endpoints. Tunnel Endpoints 148 MUST NOT forward the payload and transit devices MUST NOT 149 attempt to interpret it. Since these are infrequent control 150 messages, it is RECOMMENDED that tunnel endpoints direct these 151 packets to a high priority control queue (for example, to 152 direct the packet to a general purpose CPU from a forwarding 153 ASIC or to separate out control traffic on a NIC). Transit 154 devices MUST NOT alter forwarding behavior on the basis of this 155 bit, such as ECMP link selection. 157 GUE: 159 C-bit provides the separate namespace to carry formatted data 160 that are implicitly addressed to the decapsulator to monitor or 161 control the state or behavior of a tunnel. The payload is 162 interpreted as a control message with the type specified in the 163 proto/ctype field. The format and contents of the control 164 message are indicated by the type and can be variable length. 166 SFC NSH: 168 O bit: Setting this bit indicates an OAM packet. 170 Common between Geneve and NSH is the use of the dedicated flag to 171 identify the OAM packet and, at the same time, the presence of the 172 field that identifies the protocol of the payload that immediately 173 follows after the encapsulation header. [RFC8393] points out that if 174 the value of that field interpreted as none, i.e., no payload follows 175 the header, then OAM may be included in TLVs, thus creating an active 176 OAM packet. The problem with this mechanism to support active OAM 177 methods may be a limitation of the size of data that can be included 178 in a TLV. For example, the maximum size of data in an NSH Meta-data 179 Type 2, as defined in section 2.5.1 [RFC8300], is 512 octets. The 180 maximum length of data in Geneve Option, per section 3.5 181 [I-D.ietf-nvo3-geneve], is 128 octets. Thus, using one TLV as active 182 OAM packet, would not allow creating test packets of larger size, 183 which is useful when measuring packet loss and latency with synthetic 184 traffic as part of the service activation procedure. 186 [I-D.ietf-sfc-oam-framework] suggests that the O bit used to identify 187 OAM packet and the Next Protocol field identifies the OAM function: 189 While the presence of OAM marker in the overlay header (e.g., O 190 bit in the NSH header) indicates it as OAM packet, it is not 191 sufficient to signal for which OAM function the packet is 192 intended. 194 At the same time, some of in-situ OAM proposals, e.g., 195 [I-D.ietf-sfc-ioam-nsh], suggest using TLV to communicate hybrid OAM 196 commands and data. The proposed resolution of using the combination 197 of O bit and the Next Protocol field: 199 ... the O bit MUST NOT be set for regular customer traffic which 200 also carries IOAM data and the O bit MUST be set for OAM packets 201 which carry only IOAM data without any regular data payload. 203 implies that the O bit only identifies the active OAM packet and not 204 set when hybrid OAM methods used. 206 3.1.1. Available Solutions 208 One of the possible solutions for encapsulations with meta-data has 209 been specified in [I-D.ietf-sfc-multi-layer-oam]: 211 To identify the active OAM message the value on the Next Protocol 212 field MUST be set to Active SFC OAM. The rules of interpreting the 213 values of O bit and the Next Protocol field are as follows: 215 o O bit set and the Next Protocol value is not one of identifying 216 active or hybrid OAM protocol (per [RFC7799] definitions), e.g., 217 defined in this specification Active SFC OAM - a Fixed-Length 218 Context Header or Variable-Length Context Header(s) contain OAM 219 command or data and the type of payload determined by the Next 220 Protocol field; 222 o O bit set and the Next Protocol value is one of identifying active 223 or hybrid OAM protocol - the payload that immediately follows SFC 224 NSH contains OAM command or data; 226 o O bit is clear - no OAM in a Fixed-Length Context Header or 227 Variable-Length Context Header(s) and the payload determined by 228 the value of the Next Protocol field; 230 o O bit is clear, and the Next Protocol value is one of identifying 231 active or hybrid OAM protocol MUST be identified and reported as 232 the erroneous combination. An implementation MAY have control to 233 enable processing of the OAM payload. 235 From the above-listed rules follows the recommendation to avoid the 236 combination of OAM in a Fixed-Length Context Header or Variable- 237 Length Context Header(s) and in the payload immediately following the 238 SFC NSH because there is no unambiguous way to identify such 239 combination using the O bit and the Next Protocol field. 241 3.2. Fixed-size Encapsulations 243 Number of the new encapsulation protocols (e.g., VXLAN-GPE 244 [I-D.ietf-nvo3-vxlan-gpe], BIER [RFC8296]) suse fixed-size header. 245 The identification of OAM in these protocols is as the following: 247 VXLAN-GPE: 249 OAM Flag Bit (O bit): The O bit is set to indicate that the 250 packet is an OAM packet. 252 BIER: 254 OAM packet identified by the value of the Next Protocol field. 255 IANA BIER Next Protocol Identifiers registry includes the 256 identifier for OAM (5). 258 The use of a combination of OAM Flag Bit and the Next Protocol field 259 in VXLAN-GPE requires clarification of the header interpretation when 260 the OAM Flag Bit is set, and the value of the Next Protocol field is 261 one of defined in section 3.2 of [I-D.ietf-nvo3-vxlan-gpe]. 263 BIER encapsulation, defined in [RFC8296], identifies OAM message 264 immediately following the BIER header by the value of the Next 265 Protocol field. 267 3.3. Source Information Availability 269 Availability of the packet originator's source information is 270 required for active two-way OAM, e.g., echo request/reply. In cases 271 when the underlay network is IPv4/IPv6 the source information will be 272 derived from the underlay. But when using MPLS underlay network 273 encapsulation of an active OAM packet have to follow specific rules: 275 o if available, use Sender ID in the overlay domain (example BFIR ID 276 in BIER [RFC8296]; 278 o use IP/UDP encapsulation of an OAM packet in the overlay (similar 279 to Section 4.3 [RFC8029]). 281 3.4. On-path OAM 283 In addition to active methods, OAM toolset may include methods that 284 don't use specially constructed and injected in the network test 285 packets. [RFC7799] defines OAM methods that are neither entirely 286 active nor passive but are a combination of both as hybrid methods. 288 One of the examples of the hybrid OAM methods, in-situ OAM, mentioned 289 in Section 3.1. Another example, Alternate Marking method (AMM) 290 [RFC8321], enables on-path OAM functions, e.g., delay and loss 291 measurements, using the data traffic. Because AMM impact on the 292 network can be minimized, measured metrics can be correlated to the 293 network conditions experienced by the specific service. Of all 294 listed in Section 3, BIER allocated the field that may be used for 295 AMM, as discussed in [I-D.ietf-bier-pmmm-oam]. Applicability of AMM 296 to other overlay protocols, i.e., SFC NSH discussed in 297 [I-D.mirsky-sfc-pmamm], Geneve [I-D.fmm-nvo3-pm-alt-mark], and in 298 IPv6 networks [I-D.fioccola-v6ops-ipv6-alt-mark], been actively 299 discussed. 301 Hybrid Two-step (HTS), defined in [I-D.mirsky-ippm-hybrid-two-step], 302 provides on-path collection and transport of the telemetry 303 information. HTS enables accurate and consistent measurements by 304 separating the measurement action from the transporting data while 305 ensuring that the follow-up packet that carries the telemetry 306 information does follow the data packet that had triggered the 307 measurement. 309 4. Conclusions 311 OAM control commands and data may be present as part of the overlay 312 encapsulation header or as a payload that follows the overlay network 313 header. The recommendations: 315 o OAM in the overlay header, if supported by the overlay network, 316 identified by the dedicated flag. Use of this method as active 317 OAM is possible, but functionality is limited. 319 o OAM that follows the overlay header identified as payload type, 320 e.g., by the value of the Next Protocol field. 322 5. IANA Considerations 324 This document does not propose any IANA consideration. This section 325 may be removed. 327 6. Security Considerations 329 This document lists the OAM requirements for a DetNet domain and does 330 not raise any security concerns or issues in addition to ones common 331 to networking. 333 7. Acknowledgment 335 TBD 337 8. References 339 8.1. Normative References 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 343 RFC2119, March 1997, 344 . 346 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 347 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 348 May 2017, . 350 8.2. Informational References 352 [I-D.fioccola-v6ops-ipv6-alt-mark] 353 Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6 354 Performance Measurement with Alternate Marking Method", 355 draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress), 356 June 2018. 358 [I-D.fmm-nvo3-pm-alt-mark] 359 Fioccola, G., Mirsky, G., and T. Mizrahi, "Performance 360 Measurement (PM) with Alternate Marking in Network 361 Virtualization Overlays (NVO3)", 362 draft-fmm-nvo3-pm-alt-mark-03 (work in progress), 363 October 2018. 365 [I-D.ietf-bier-pmmm-oam] 366 Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, 367 "Performance Measurement (PM) with Marking Method in Bit 368 Index Explicit Replication (BIER) Layer", 369 draft-ietf-bier-pmmm-oam-05 (work in progress), 370 December 2018. 372 [I-D.ietf-intarea-gue] 373 Herbert, T., Yong, L., and O. Zia, "Generic UDP 374 Encapsulation", draft-ietf-intarea-gue-06 (work in 375 progress), August 2018. 377 [I-D.ietf-nvo3-geneve] 378 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 379 Network Virtualization Encapsulation", 380 draft-ietf-nvo3-geneve-10 (work in progress), March 2019. 382 [I-D.ietf-nvo3-vxlan-gpe] 383 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 384 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work 385 in progress), April 2018. 387 [I-D.ietf-sfc-ioam-nsh] 388 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 389 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 390 D., Lapukhov, P., and R. Chang, "NSH Encapsulation for In- 391 situ OAM Data", draft-ietf-sfc-ioam-nsh-00 (work in 392 progress), May 2018. 394 [I-D.ietf-sfc-multi-layer-oam] 395 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active 396 OAM for Service Function Chains in Networks", 397 draft-ietf-sfc-multi-layer-oam-01 (work in progress), 398 January 2019. 400 [I-D.ietf-sfc-oam-framework] 401 Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan, 402 R., and A. Ghanwani, "Service Function Chaining (SFC) 403 Operation, Administration and Maintenance (OAM) 404 Framework", draft-ietf-sfc-oam-framework-05 (work in 405 progress), September 2018. 407 [I-D.mirsky-ippm-hybrid-two-step] 408 Mirsky, G., Lingqiang, W., and G. Zhui, "Hybrid Two-Step 409 Performance Measurement Method", 410 draft-mirsky-ippm-hybrid-two-step-02 (work in progress), 411 October 2018. 413 [I-D.mirsky-sfc-pmamm] 414 Mirsky, G., Fioccola, G., and T. Mizrahi, "Performance 415 Measurement (PM) with Alternate Marking Method in Service 416 Function Chaining (SFC) Domain", draft-mirsky-sfc-pmamm-06 417 (work in progress), October 2018. 419 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 420 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 421 May 2016, . 423 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 424 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 425 Switched (MPLS) Data-Plane Failures", RFC 8029, 426 DOI 10.17487/RFC8029, March 2017, 427 . 429 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 430 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 431 for Bit Index Explicit Replication (BIER) in MPLS and Non- 432 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, 433 January 2018, . 435 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 436 "Network Service Header (NSH)", RFC 8300, DOI 10.17487/ 437 RFC8300, January 2018, 438 . 440 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 441 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 442 "Alternate-Marking Method for Passive and Hybrid 443 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 444 January 2018, . 446 [RFC8393] Farrel, A. and J. Drake, "Operating the Network Service 447 Header (NSH) with Next Protocol "None"", RFC 8393, 448 DOI 10.17487/RFC8393, May 2018, 449 . 451 Author's Address 453 Greg Mirsky 454 ZTE Corp. 456 Email: gregimirsky@gmail.com