idnits 2.17.1 draft-mirsky-rtgwg-oam-identify-04.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 26, 2020) is 1511 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-07 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-14 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-09 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-02 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-multi-layer-oam-04 == Outdated reference: A later version (-15) exists of draft-ietf-sfc-oam-framework-11 == Outdated reference: A later version (-15) exists of draft-mirsky-ippm-hybrid-two-step-04 == Outdated reference: A later version (-14) exists of draft-mirsky-sfc-pmamm-09 == Outdated reference: A later version (-04) exists of draft-mmbb-nvo3-geneve-oam-01 -- 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 February 26, 2020 5 Expires: August 29, 2020 7 Identification of Overlay Operations, Administration, and Maintenance 8 (OAM) 9 draft-mirsky-rtgwg-oam-identify-04 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 https://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 August 29, 2020. 35 Copyright Notice 37 Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions used in this document . . . . . . . . . . . . . . 2 54 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 55 2.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. A Control Channel in an Overlay Network . . . . . . . . . . . 3 57 4. Overlay Network Encapsulations . . . . . . . . . . . . . . . 4 58 4.1. Encapsulations with Meta-data . . . . . . . . . . . . . . 4 59 4.1.1. Available Solutions . . . . . . . . . . . . . . . . . 6 60 4.2. Fixed-size Encapsulations . . . . . . . . . . . . . . . . 6 61 4.3. Source Information Availability . . . . . . . . . . . . . 7 62 4.4. On-path OAM . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 9.2. Informational References . . . . . . . . . . . . . . . . 9 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 Operations, Administration, and Maintenance (OAM) protocols are used 75 to detect, localize defects in the network, and monitor network 76 performance. Some OAM functions, e.g., failure detection, work in 77 the network proactively, while others, e.g., defect localization, 78 usually performed on-demand. These tasks achieved by a combination 79 of active, passive, and hybrid OAM methods, as defined in [RFC7799]. 81 This document analyzes how the presence of Operations, 82 Administration, and Maintenance (OAM) control command and/or special 83 data, i.e., OAM packet, is identified in some overlay networks, and 84 an impact the choice of identification may have on OAM functionality 85 of active and hybrid OAM methods for the respective overlay network 86 encapsulation. 88 2. Conventions used in this document 90 2.1. Terminology 92 AMM Alternate Marking method 94 BIER Bit Indexed Explicit Replication 96 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 ACH Associated Channed Header 115 Underlay Network or Underlay Layer: The network that provides 116 connectivity between the DetNet nodes. MPLS network that provides 117 LSP connectivity between DetNet nodes is an example of an underlay 118 layer. 120 2.2. Keywords 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 3. A Control Channel in an Overlay Network 130 There's a need for a general control channel between the endpoints of 131 an overlay network for OAM protocols that can be used for fault 132 detection, diagnostics, maintenance, and other functions. Such a 133 control tunnel is dedicated to carrying only control and management 134 data between tunnel endpoints. In other words, the control channel 135 of an overlay network SHOULD NOT carry the client's data. And the 136 endpoint node SHOULD NOT forward a packet received over the control 137 channel. The identification of the control channel might be using 138 different methods. For example, Virtual Network Identifier might be 139 used to identify the control channel in VXLAN and Geneve. 141 4. Overlay Network Encapsulations 143 New overlay network encapsulations analyzed in two groups: 145 o encapsulations that support optional meta-data; 147 o fixed-size encapsulations. 149 4.1. Encapsulations with Meta-data 151 Number of the new encapsulation protocols (e.g., Geneve 152 [I-D.ietf-nvo3-geneve], GUE [I-D.ietf-intarea-gue], and SFC NSH 153 [RFC8300]) support use of Type-Length-Value (TLV) encoding to include 154 optional information into the header. The identification of OAM in 155 these protocols is as the following: 157 Geneve: 159 O (1 bit): after the WGLC discussion, the interpretation of the 160 O field has changed. The O field now identifies a control 161 packet. This packet contains a control message. Control 162 messages are sent between tunnel endpoints. Tunnel Endpoints 163 MUST NOT forward the payload and transit devices MUST NOT 164 attempt to interpret it. Since these are infrequent control 165 messages, it is RECOMMENDED that tunnel endpoints direct these 166 packets to a high priority control queue (for example, to 167 direct the packet to a general purpose CPU from a forwarding 168 ASIC or to separate out control traffic on a NIC). Transit 169 devices MUST NOT alter forwarding behavior on the basis of this 170 bit, such as ECMP link selection. 172 [I-D.mmbb-nvo3-geneve-oam] defines the Geneve encapsulation for 173 active OAM. Initially, four options have been presented: 175 + with IP/UDP header demultiplexing active OAM protocols, 176 e.g., Fault Management and Performance Monitoring, can be 177 done using the destination UDP port number. 179 + demultiplex active OAM protocols by the value of the 180 Protocol Type field in the Geneve header. 182 + with using MPLS Generic Associated Channel Label [RFC5586] 183 and Associated Channel Header (ACH) [RFC4385]. Active OAM 184 protocols are demultiplexed using the value of the Channel 185 Type field. 187 + using the new EtherType to identify Geneve OAM and the ACH. 188 Active OAM protocols will be demultiplexed based on the 189 Channel Type field's value. 191 GUE: 193 C-bit provides the separate namespace to carry formatted data 194 that are implicitly addressed to the decapsulator to monitor or 195 control the state or behavior of a tunnel. The payload is 196 interpreted as a control message with the type specified in the 197 proto/ctype field. The format and contents of the control 198 message are indicated by the type and can be variable length. 200 SFC NSH: 202 O bit: Setting this bit indicates an OAM packet. 204 Common between Geneve and NSH is the use of the dedicated flag to 205 identify the OAM packet and, at the same time, the presence of the 206 field that identifies the protocol of the payload that immediately 207 follows after the encapsulation header. [RFC8393] points out that if 208 the value of that field interpreted as none, i.e., no payload follows 209 the header, then OAM may be included in TLVs, thus creating an active 210 OAM packet. The problem with this mechanism to support active OAM 211 methods may be a limitation of the size of data that can be included 212 in a TLV. For example, the maximum size of data in an NSH Meta-data 213 Type 2, as defined in section 2.5.1 [RFC8300], is 512 octets. The 214 maximum length of data in Geneve Option, per section 3.5 215 [I-D.ietf-nvo3-geneve], is 128 octets. Thus, using one TLV as active 216 OAM packet, would not allow creating test packets of larger size, 217 which is useful when measuring packet loss and latency with synthetic 218 traffic as part of the service activation procedure. 220 [I-D.ietf-sfc-oam-framework] suggests that the O bit used to identify 221 OAM packet and the Next Protocol field identifies the OAM function: 223 While the presence of OAM marker in the overlay header (e.g., O 224 bit in the NSH header) indicates it as OAM packet, it is not 225 sufficient to signal for which OAM function the packet is 226 intended. 228 At the same time, some of in-situ OAM proposals, e.g., 229 [I-D.ietf-sfc-ioam-nsh], suggest using TLV to communicate hybrid OAM 230 commands and data. The proposed resolution of using the combination 231 of O bit and the Next Protocol field: 233 ... the O bit MUST NOT be set for regular customer traffic which 234 also carries IOAM data and the O bit MUST be set for OAM packets 235 which carry only IOAM data without any regular data payload. 237 implies that the O bit only identifies the active OAM packet and not 238 set when hybrid OAM methods used. 240 4.1.1. Available Solutions 242 One of the possible solutions for encapsulations with meta-data has 243 been specified in [I-D.ietf-sfc-multi-layer-oam]: 245 To identify the active OAM message the value on the Next Protocol 246 field MUST be set to Active SFC OAM. The rules of interpreting the 247 values of O bit and the Next Protocol field are as follows: 249 o O bit set and the Next Protocol value is not one of identifying 250 active or hybrid OAM protocol (per [RFC7799] definitions), e.g., 251 defined in this specification Active SFC OAM - a Fixed-Length 252 Context Header or Variable-Length Context Header(s) contain OAM 253 command or data and the type of payload determined by the Next 254 Protocol field; 256 o O bit set and the Next Protocol value is one of identifying active 257 or hybrid OAM protocol - the payload that immediately follows SFC 258 NSH contains OAM command or data; 260 o O bit is clear - no OAM in a Fixed-Length Context Header or 261 Variable-Length Context Header(s) and the payload determined by 262 the value of the Next Protocol field; 264 o O bit is clear, and the Next Protocol value is one of identifying 265 active or hybrid OAM protocol MUST be identified and reported as 266 the erroneous combination. An implementation MAY have control to 267 enable processing of the OAM payload. 269 From the above-listed rules follows the recommendation to avoid the 270 combination of OAM in a Fixed-Length Context Header or Variable- 271 Length Context Header(s) and in the payload immediately following the 272 SFC NSH because there is no unambiguous way to identify such 273 combination using the O bit and the Next Protocol field. 275 4.2. Fixed-size Encapsulations 277 Number of the new encapsulation protocols (e.g., VXLAN-GPE 278 [I-D.ietf-nvo3-vxlan-gpe], BIER [RFC8296]) suse fixed-size header. 279 The identification of OAM in these protocols is as the following: 281 VXLAN-GPE: 283 OAM Flag Bit (O bit): The O bit is set to indicate that the 284 packet is an OAM packet. 286 BIER: 288 OAM packet identified by the value of the Next Protocol field. 289 IANA BIER Next Protocol Identifiers registry includes the 290 identifier for OAM (5). 292 The use of a combination of OAM Flag Bit and the Next Protocol field 293 in VXLAN-GPE requires clarification of the header interpretation when 294 the OAM Flag Bit is set, and the value of the Next Protocol field is 295 one of defined in section 3.2 of [I-D.ietf-nvo3-vxlan-gpe]. 297 BIER encapsulation, defined in [RFC8296], identifies OAM message 298 immediately following the BIER header by the value of the Next 299 Protocol field. 301 4.3. Source Information Availability 303 Availability of the packet originator's source information is 304 required for active two-way OAM, e.g., echo request/reply. In cases 305 when the underlay network is IPv4/IPv6 the source information will be 306 derived from the underlay. But when using MPLS underlay network 307 encapsulation of an active OAM packet have to follow specific rules: 309 o if available, use Sender ID in the overlay domain (example BFIR ID 310 in BIER [RFC8296]; 312 o use IP/UDP encapsulation of an OAM packet in the overlay (similar 313 to Section 4.3 [RFC8029]). 315 4.4. On-path OAM 317 In addition to active methods, OAM toolset may include methods that 318 don't use specially constructed and injected in the network test 319 packets. [RFC7799] defines OAM methods that are neither entirely 320 active nor passive but are a combination of both as hybrid methods. 322 One of the examples of the hybrid OAM methods, in-situ OAM, mentioned 323 in Section 4.1. Another example, Alternate Marking method (AMM) 324 [RFC8321], enables on-path OAM functions, e.g., delay and loss 325 measurements, using the data traffic. Because AMM impact on the 326 network can be minimized, measured metrics can be correlated to the 327 network conditions experienced by the specific service. Of all 328 listed in Section 4, BIER allocated the field that may be used for 329 AMM, as discussed in [I-D.ietf-bier-pmmm-oam]. Applicability of AMM 330 to other overlay protocols, i.e., SFC NSH discussed in 331 [I-D.mirsky-sfc-pmamm], Geneve [I-D.fmm-nvo3-pm-alt-mark], and in 332 IPv6 networks [I-D.fioccola-v6ops-ipv6-alt-mark], been actively 333 discussed. 335 Hybrid Two-step (HTS), defined in [I-D.mirsky-ippm-hybrid-two-step], 336 provides on-path collection and transport of the telemetry 337 information. HTS enables accurate and consistent measurements by 338 separating the measurement action from the transporting data while 339 ensuring that the follow-up packet that carries the telemetry 340 information does follow the data packet that had triggered the 341 measurement. 343 5. Conclusions 345 OAM control commands and data may be present as part of the overlay 346 encapsulation header or as a payload that follows the overlay network 347 header. The recommendations: 349 o OAM in the overlay header, if supported by the overlay network, 350 identified by the dedicated flag. Use of this method as active 351 OAM is possible, but functionality is limited. 353 o OAM that follows the overlay header identified as payload type, 354 e.g., by the value of the Next Protocol field. 356 6. IANA Considerations 358 This document does not propose any IANA consideration. This section 359 may be removed. 361 7. Security Considerations 363 This document lists the OAM requirements for a DetNet domain and does 364 not raise any security concerns or issues in addition to ones common 365 to networking. 367 8. Acknowledgment 369 TBD 371 9. References 372 9.1. Normative References 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, 376 DOI 10.17487/RFC2119, March 1997, 377 . 379 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 380 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 381 May 2017, . 383 9.2. Informational References 385 [I-D.fioccola-v6ops-ipv6-alt-mark] 386 Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6 387 Performance Measurement with Alternate Marking Method", 388 draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress), 389 June 2018. 391 [I-D.fmm-nvo3-pm-alt-mark] 392 Fioccola, G., Mirsky, G., and T. Mizrahi, "Performance 393 Measurement (PM) with Alternate Marking in Network 394 Virtualization Overlays (NVO3)", draft-fmm-nvo3-pm-alt- 395 mark-03 (work in progress), October 2018. 397 [I-D.ietf-bier-pmmm-oam] 398 Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, 399 "Performance Measurement (PM) with Marking Method in Bit 400 Index Explicit Replication (BIER) Layer", draft-ietf-bier- 401 pmmm-oam-07 (work in progress), January 2020. 403 [I-D.ietf-intarea-gue] 404 Herbert, T., Yong, L., and O. Zia, "Generic UDP 405 Encapsulation", draft-ietf-intarea-gue-09 (work in 406 progress), October 2019. 408 [I-D.ietf-nvo3-geneve] 409 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 410 Network Virtualization Encapsulation", draft-ietf- 411 nvo3-geneve-14 (work in progress), September 2019. 413 [I-D.ietf-nvo3-vxlan-gpe] 414 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 415 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-09 (work 416 in progress), December 2019. 418 [I-D.ietf-sfc-ioam-nsh] 419 Brockners, F. and S. Bhandari, "Network Service Header 420 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 421 ietf-sfc-ioam-nsh-02 (work in progress), September 2019. 423 [I-D.ietf-sfc-multi-layer-oam] 424 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active 425 OAM for Service Function Chains in Networks", draft-ietf- 426 sfc-multi-layer-oam-04 (work in progress), November 2019. 428 [I-D.ietf-sfc-oam-framework] 429 Aldrin, S., Pignataro, C., Kumar, N., Krishnan, R., and A. 430 Ghanwani, "Service Function Chaining (SFC) Operations, 431 Administration and Maintenance (OAM) Framework", draft- 432 ietf-sfc-oam-framework-11 (work in progress), September 433 2019. 435 [I-D.mirsky-ippm-hybrid-two-step] 436 Mirsky, G., Lingqiang, W., and G. Zhui, "Hybrid Two-Step 437 Performance Measurement Method", draft-mirsky-ippm-hybrid- 438 two-step-04 (work in progress), October 2019. 440 [I-D.mirsky-sfc-pmamm] 441 Mirsky, G., Fioccola, G., and T. Mizrahi, "Performance 442 Measurement (PM) with Alternate Marking Method in Service 443 Function Chaining (SFC) Domain", draft-mirsky-sfc-pmamm-09 444 (work in progress), December 2019. 446 [I-D.mmbb-nvo3-geneve-oam] 447 Mirsky, G., Xiao, M., Boutros, S., and D. Black, "OAM for 448 use in GENEVE", draft-mmbb-nvo3-geneve-oam-01 (work in 449 progress), January 2020. 451 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 452 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 453 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 454 February 2006, . 456 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 457 "MPLS Generic Associated Channel", RFC 5586, 458 DOI 10.17487/RFC5586, June 2009, 459 . 461 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 462 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 463 May 2016, . 465 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 466 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 467 Switched (MPLS) Data-Plane Failures", RFC 8029, 468 DOI 10.17487/RFC8029, March 2017, 469 . 471 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 472 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 473 for Bit Index Explicit Replication (BIER) in MPLS and Non- 474 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 475 2018, . 477 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 478 "Network Service Header (NSH)", RFC 8300, 479 DOI 10.17487/RFC8300, January 2018, 480 . 482 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 483 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 484 "Alternate-Marking Method for Passive and Hybrid 485 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 486 January 2018, . 488 [RFC8393] Farrel, A. and J. Drake, "Operating the Network Service 489 Header (NSH) with Next Protocol "None"", RFC 8393, 490 DOI 10.17487/RFC8393, May 2018, 491 . 493 Author's Address 495 Greg Mirsky 496 ZTE Corp. 498 Email: gregimirsky@gmail.com