idnits 2.17.1 draft-ietf-sfc-multi-layer-oam-13.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 (16 June 2021) is 1045 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-sfc-nsh-integrity-05 == Outdated reference: A later version (-15) exists of draft-ietf-sfc-nsh-tlv-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG G. Mirsky 3 Internet-Draft ZTE Corp. 4 Updates: 8300 (if approved) W. Meng 5 Intended status: Standards Track ZTE Corporation 6 Expires: 18 December 2021 B. Khasnabish 7 C. Wang 8 Individual contributor 9 16 June 2021 11 Active OAM for Service Function Chaining 12 draft-ietf-sfc-multi-layer-oam-13 14 Abstract 16 A set of requirements for active Operation, Administration, and 17 Maintenance (OAM) of Service Function Chains (SFCs) in a network is 18 presented in this document. Based on these requirements, an 19 encapsulation of active OAM messages in SFC and a mechanism to detect 20 and localize defects are described. 22 This document updates RFC 8300. Particularly, it updates the 23 definition of O (OAM) bit in the Network Service Header (NSH) (RFC 24 8300) and defines how an active OAM message is identified in the NSH. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 18 December 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Requirements for Active OAM in SFC . . . . . . . . . . . . . 5 64 4. Active OAM Identification in the NSH . . . . . . . . . . . . 7 65 5. Active SFC OAM Header . . . . . . . . . . . . . . . . . . . . 8 66 6. Echo Request/Echo Reply for SFC . . . . . . . . . . . . . . . 9 67 6.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 11 68 6.2. Authentication in Echo Request/Reply . . . . . . . . . . 11 69 6.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 12 70 6.3.1. Source TLV . . . . . . . . . . . . . . . . . . . . . 12 71 6.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 14 72 6.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 14 73 6.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 15 74 6.6. SFC Echo Reply Reception . . . . . . . . . . . . . . . . 15 75 6.7. Tracing an SFP . . . . . . . . . . . . . . . . . . . . . 16 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 9.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 17 80 9.2. SFC Active OAM . . . . . . . . . . . . . . . . . . . . . 17 81 9.2.1. Version in the Active SFC OAM Header . . . . . . . . 18 82 9.2.2. SFC Active OAM Message Type . . . . . . . . . . . . . 18 83 9.2.3. SFC Active OAM Header Flags . . . . . . . . . . . . . 19 84 9.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 19 85 9.3.1. SFC Echo Request/Reply Version . . . . . . . . . . . 19 86 9.3.2. SFC Echo Request Flags . . . . . . . . . . . . . . . 20 87 9.3.3. SFC Echo Request/Echo Reply Message Types . . . . . . 20 88 9.3.4. SFC Echo Reply Modes . . . . . . . . . . . . . . . . 21 89 9.3.5. SFC Echo Return Codes . . . . . . . . . . . . . . . . 23 90 9.4. SFC Active OAM TLV Type . . . . . . . . . . . . . . . . . 24 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 93 10.2. Informative References . . . . . . . . . . . . . . . . . 25 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 96 1. Introduction 98 [RFC7665] defines data plane elements necessary to implement a 99 Service Function Chaining (SFC). These include: 101 1. Classifiers that perform the classification of incoming packets. 102 Such classification may result in associating a received packet 103 to a service function chain. 105 2. Service Function Forwarders (SFFs) that are responsible for 106 forwarding traffic to one or more connected Service Functions 107 (SFs) according to the information carried in the SFC 108 encapsulation and handling traffic coming back from the SFs and 109 forwarding it to the next SFF. 111 3. SFs that are responsible for executing specific service treatment 112 on received packets. 114 There are different views from different levels of the SFC. One is 115 the service function chain, an entirely abstract view, which defines 116 an ordered set of SFs that must be applied to packets selected based 117 on classification rules. But service function chain doesn't specify 118 the exact mapping between SFFs and SFs. Thus, another logical 119 construct used in SFC is a Service Function Path (SFP). According to 120 [RFC7665], SFP is the instantiation of the SFC in the network and 121 provides a level of indirection between the entirely abstract SFCs 122 and a fully specified ordered list of SFFs and SFs identities that 123 the packet will visit when it traverses the SFC. The latter entity 124 is referred to as Rendered Service Path (RSP). The main difference 125 between SFP and RSP is that the former is the logical construct, 126 while the latter is the realization of the SFP via the sequence of 127 specific SFC data plane elements. 129 This document defines how active Operation, Administration and 130 Maintenance (OAM), per [RFC7799] definition of active OAM, is 131 identified when Network Service Header (NSH) is used as the SFC 132 encapsulation. Following the analysis of SFC OAM in [RFC8924], this 133 document applies and, when necessary, extends requirements listed in 134 Section 4 of [RFC8924] for the use of active OAM in an SFP supporting 135 fault management and performance monitoring. Active OAM tools, 136 conformant to the requirements listed in Section 3, improve, for 137 example, troubleshooting efficiency and defect localization in SFP 138 because they specifically address the architectural principles of 139 NSH. For that purpose, SFC Echo Request and Echo Reply are specified 140 in Section 6. This mechanism enables on-demand Continuity Check, 141 Connectivity Verification among other operations over SFC in 142 networks, addresses functionalities discussed in Sections 4.1, 4.2, 143 and 4.3 of [RFC8924]. SFC Echo Request and Echo Reply, defined in 144 this document, can be used with encapsulations other than NSH, for 145 example, using MPLS encapsulation, as described in [RFC8595]. The 146 applicability of the SFC Echo Request/Reply mechanism in SFC 147 encapsulations other than NSH is outside the scope of this document. 148 Also, this document updates Section 2.2 of [RFC8300] in part of the 149 definition of O bit in the NSH. 151 2. Terminology and Conventions 153 The terminology defined in [RFC7665] is used extensively throughout 154 this document. The reader is expected to be familiar with it. 156 In this document, SFC OAM refers to an active OAM [RFC7799] in an SFC 157 architecture. 159 2.1. Requirements Language 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 2.2. Acronyms 169 E2E: End-to-End 171 FM: Fault Management 173 NSH: Network Service Header 175 OAM: Operations, Administration, and Maintenance 177 RSP: Rendered Service Path 179 SF: Service Function 181 SFC: Service Function Chain 183 SFF: Service Function Forwarder 185 SFP: Service Function Path 187 MAC: Message Authentication Code 189 3. Requirements for Active OAM in SFC 191 As discussed in [RFC8924], SFC-specific means are needed to perform 192 the OAM task of fault management (FM) in an SFC architecture, 193 including failure detection, defect characterization, and 194 localization. This document defines the set of requirements for 195 active FM OAM mechanisms to be used in an SFC architecture. 197 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 198 |SFI11| |SFI12| |SFI21| |SFI22| |SFI31| |SFI32| 199 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 200 \ / \ / \ / 201 +----------+ +----+ +----+ +----+ 202 |Classifier|---|SFF1|---------|SFF2|----------|SFF3| 203 +----------+ +----+ +----+ +----+ 205 Figure 1: An Example of SFC Data Plane Architecture 207 The architecture example depicted in Figure 1 considers a service 208 function chain that includes three distinct service functions. In 209 this example, the SFP traverses SFF1, SFF2, and SFF3, each SFF being 210 connected to two instances of the same service function. End-to-end 211 (E2E) SFC OAM has the Classifier as the ingress and SFF3 as its 212 egress. Segment SFC OAM is between two elements that are part of the 213 same SFP. Following are the requirements for an FM SFC OAM, whether 214 with the E2E or segment scope: 216 REQ#1: Packets of active SFC OAM SHOULD be fate sharing with the 217 monitored SFC data in the forward direction from ingress toward 218 egress endpoint(s) of the OAM test. 220 The fate sharing, in the SFC environment, is achieved when a test 221 packet traverses the same path and receives the same treatment in the 222 transport layer as an SFC-encapsulated packet (e.g., NSH). 224 REQ#2: SFC OAM MUST support monitoring of the continuity of the 225 SFP between any of its elements. 227 An SFC failure might be declared when several consecutive test 228 packets are not received within a pre-determined time. For example, 229 in the E2E FM SFC OAM case, the egress, SFF3, in the example in 230 Figure 1, could be the entity that detects the SFP's failure by 231 monitoring a flow of periodic test packets. The ingress may be 232 capable of recovering from the failure, e.g., using redundant SFC 233 elements. Thus, it is beneficial for the egress to signal the new 234 defect state to the ingress, which in this example is the Classifier. 235 Hence the following requirement: 237 REQ#3: SFC OAM MUST support Remote Defect Indication notification 238 by the egress to the ingress. 240 REQ#4: SFC OAM MUST support connectivity verification of the SFP. 241 Definition of the misconnection defect, entry, and exit criteria 242 are outside the scope of this document. 244 Once the SFF1 detects the defect, the objective of the SFC OAM 245 changes from the detection of a defect to defect characterization and 246 localization. 248 REQ#5: SFC OAM MUST support fault localization of the Loss of 249 Continuity Check within an SFP. 251 REQ#6: SFC OAM MUST support an SFP tracing to discover the RSP. 253 In the example presented in Figure 1, two distinct instances of the 254 same service function share the same SFF. In this example, the SFP 255 can be realized over several RSPs that use different instances of SF 256 of the same type. For example, RSP1(SFI11--SFI21--SFI31) and 257 RSP2(SFI12--SFI22--SFI32). Available RSPs can be discovered using 258 the trace function discussed in Section 4.3 [RFC8924] or the 259 procedure defined in Section 6.7. 261 REQ#7: SFC OAM MUST have the ability to discover and exercise all 262 available RSPs in the network. 264 The SFC OAM layer model described in [RFC8924] offers an approach for 265 defect localization within a service function chain. As the first 266 step, the SFP's continuity for SFFs that are part of the same SFP 267 could be verified. After the reachability of SFFs has already been 268 verified, SFFs that serve an SF may be used as a test packet source. 269 In such a case, SFF can act as a proxy for another element within the 270 service function chain. 272 REQ#8: SFC OAM MUST be able to trigger on-demand FM with responses 273 being directed towards the initiator of such proxy request. 275 4. Active OAM Identification in the NSH 277 The O bit in the NSH is defined in [RFC8300] as follows: 279 O bit: Setting this bit indicates an OAM packet. 281 This document updates that definition as follows: 283 O bit: Setting this bit indicates an OAM command and/or data in 284 the NSH Context Header or packet payload. 286 Active SFC OAM is defined as a combination of OAM commands and/or 287 data included in a message that immediately follows the NSH. To 288 identify the active OAM message, the "Next Protocol" field MUST be 289 set to Active SFC OAM (TBA1) (Section 9.1). The rules for 290 interpreting the values of the O bit and the "Next Protocol" field 291 are as follows: 293 * O bit set and the "Next Protocol" value does not match one of 294 identifying active or hybrid OAM protocols (per classification 295 defined in [RFC7799]), e.g., defined in Section 9.1 Active SFC OAM 296 (TBA1). 298 - a Fixed-Length Context Header or Variable-Length Context 299 Header(s) contain an OAM command or data. 301 - the type of payload is determined by the "Next Protocol" 302 field. 304 * O bit set and the "Next Protocol" value matches one of identifying 305 active or hybrid OAM protocols: 307 - the payload that immediately follows the NSH MUST contain an 308 OAM command or data. 310 * O bit is clear: 312 - no OAM in a Fixed-Length Context Header or Variable-Length 313 Context Header(s). 315 - the payload determined by the "Next Protocol" field MUST be 316 present. 318 * O bit is clear, and the "Next Protocol" field identifies active or 319 hybrid OAM protocol MUST be identified and reported as an 320 erroneous combination. An implementation MAY have control to 321 enable processing of the OAM payload. 323 One conclusion from the above-listed rules of processing the O bit 324 and the "Next Protocol" field is to avoid the combination of OAM in 325 an NSH Context Header (Fixed-Length or Variable-Length) and the 326 payload immediately following the NSH because there is no unambiguous 327 way to identify such combination using the O bit and the Next 328 Protocol field. 330 5. Active SFC OAM Header 332 As demonstrated in Section 4 [RFC8924] and Section 3 of this 333 document, SFC OAM is required to perform multiple tasks. Several 334 active OAM protocols could be used to address all the requirements. 335 When IP/UDP encapsulation of an SFC OAM control message is used, 336 protocols can be demultiplexed using the destination UDP port number. 337 But extra IP/UDP headers, especially in an IPv6 network, add 338 noticeable overhead. This document defines Active OAM Header 339 (Figure 2) to demultiplex active OAM protocols on an SFC. 341 0 1 2 3 342 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | V | Msg Type | Flags | Length | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 ~ SFC Active OAM Control Packet ~ 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 2: SFC Active OAM Header 351 V - two-bit-long field indicates the current version of the SFC 352 active OAM header. The current value is 0. The version number is 353 to be incremented whenever a change is made that affects the 354 ability of an implementation to parse or process the SFC Active 355 OAM header correctly. For example, if syntactic or semantic 356 changes are made to any of the fixed fields. 358 Msg Type - six bits long field identifies OAM protocol, e.g., Echo 359 Request/Reply or Bidirectional Forwarding Detection. 361 Flags - eight bits long field carries bit flags that define 362 optional capability and thus processing of the SFC active OAM 363 control packet, e.g., optional timestamping. No flags are defined 364 in this document. Thus, the bit flags MUST be zeroed on 365 transmission and ignored on receipt. 367 Length - two octets long field that is the length of the SFC 368 active OAM control packet in octets. 370 6. Echo Request/Echo Reply for SFC 372 Echo Request/Reply is a well-known active OAM mechanism extensively 373 used to verify a path's continuity, detect inconsistencies between a 374 state in control and the data planes, and localize defects in the 375 data plane. ICMP ([RFC0792] for IPv4 and [RFC4443] for IPv6 376 networks, respectively) and [RFC8029] are examples of broadly used 377 active OAM protocols based on the Echo Request/Reply principle. The 378 SFC Echo Request/Reply defined in this document addresses several 379 requirements listed in Section 3. Specifically, it can be used to 380 check the continuity of an SFP, trace an SFP, or localize the failure 381 within an SFP. The SFC Echo Request/Reply control message format is 382 presented in Figure 3. 384 0 1 2 3 385 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | V | Reserved | Echo Request Flags | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Message Type | Reply mode | Return Code |Return Subcode | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Sender's Handle | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Sequence Number | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 ~ TLVs ~ 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Figure 3: SFC Echo Request/Reply Format 400 The interpretation of the fields is as follows: 402 Version (V) is a two-bit field that indicates the current version 403 of the SFC Echo Request/Reply. The current value is 0. The 404 version number is to be incremented whenever a change is made that 405 affects the ability of an implementation to parse or process the 406 control packet correctly. If a packet presumed to carry an SFC 407 Echo Request/Reply is received at an SFF, and the SFF does not 408 understand the Version field value, the packet MUST be discarded, 409 and the event SHOULD be logged. 411 Reserved - fourteen-bit field. It MUST be zeroed on transmission 412 and ignored on receipt. 414 The Echo Request Flags is a two-octet bit vector field. Note that 415 a flag defined in the Flags field of the SFC Active OAM header in 416 Figure 2 has no implication of those defined in the Echo Request 417 Flags field of an Echo Request/Reply message. 419 The Message Type is a one-octet field that reflects the packet 420 type. Value TBA3 identifies Echo Request and TBA4 - Echo Reply. 422 The Reply Mode is a one-octet field. It defines the type of the 423 return path requested by the sender of the Echo Request. 425 Return Codes and Subcodes are one-octet fields each. These can be 426 used to inform the sender about the result of processing its 427 request. Initial Return Code values are provided in Table 1. For 428 all Return Code values defined in this document, the value of the 429 Return Subcode field MUST be set to zero. 431 The Sender's Handle is a four-octet field. It MUST be filled in 432 by the sender of the Echo Request and returned unchanged by the 433 Echo Reply sender (if a reply mandated). The sender of the Echo 434 Request SHOULD use a pseudo-random number generator to set the 435 value of the Sender's Handle field. 437 The Sequence Number is a four-octet field. It is assigned by the 438 sender and can be, for example, used to detect missed replies. 439 The initial Sequence Number MUST be randomly generated and then 440 SHOULD be monotonically increasing in the course of the test 441 session. 443 0 1 2 3 444 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Type | Reserved | Length | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 ~ Value ~ 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Figure 4: SFC Echo Request/Reply TLV Format 453 TLV is a variable-length field. Multiple TLVs MAY be placed in an 454 SFC Echo Request/Reply packet. Additional TLVs may be enclosed 455 within a given TLV, subject to the semantics of the (outer) TLV in 456 question. If more than one TLV is to be included, the value of the 457 Type field of the outmost outer TLV MUST be set to "Multiple TLVs 458 Used" (TBA12), as assigned by IANA according to Section 9.4. 459 Figure 4 presents the format of an SFC Echo Request/Reply TLV, where 460 fields are defined as follows: 462 Type - a one-octet-long field that characterizes the 463 interpretation of the Value field. Type values allocated 464 according to Section 9.4. 466 Reserved - one-octet-long field. The value of the Type field 467 determines its interpretation and encoding. 469 Length - two-octet-long field equal to the Value field's length in 470 octets. 472 Value - a variable-length field. The value of the Type field 473 determines its interpretation and encoding. 475 6.1. Return Codes 477 The value of the Return Code field is set to zero by the sender of an 478 Echo Request. The receiver of said Echo Request can set it to one of 479 the values listed in Table 1 in the corresponding Echo Reply that it 480 generates (in cases when the reply is requested). 482 +=======+============================================+ 483 | Value | Description | 484 +=======+============================================+ 485 | 0 | No Return Code | 486 +-------+--------------------------------------------+ 487 | 1 | Malformed Echo Request received | 488 +-------+--------------------------------------------+ 489 | 2 | One or more of the TLVs was not understood | 490 +-------+--------------------------------------------+ 491 | 3 | Authentication failed | 492 +-------+--------------------------------------------+ 494 Table 1: SFC Echo Return Codes 496 6.2. Authentication in Echo Request/Reply 498 Authentication can be used to protect the integrity of the 499 information in SFC Echo Request and/or Echo Reply. In the 500 [I-D.ietf-sfc-nsh-integrity] a variable-length Context Header has 501 been defined to protect the integrity of the NSH and the payload. 502 The header can also be used for the optional encryption of sensitive 503 metadata. MAC#1 Context Header is more suitable for the integrity 504 protection of active SFC OAM, particularly of the defined in this 505 document SFC Echo Request and Echo Reply. On the other hand, using 506 MAC#2 Context Header allows the detection of mishandling of the O-bit 507 by a transient SFC element. 509 6.3. SFC Echo Request Transmission 511 SFC Echo Request control packet MUST use the appropriate transport 512 encapsulation of the monitored SFP. If the NSH is used, Echo Request 513 MUST set O bit, as defined in [RFC8300]. NSH MUST be immediately 514 followed by the SFC Active OAM Header defined in Section 4. The 515 Message Type field's value in the SFC Active OAM Header MUST be set 516 to SFC Echo Request/Echo Reply value (TBA2) per Section 9.2.2. 518 Value of the Reply Mode field MAY be set to: 520 * Do Not Reply (TBA5) if one-way monitoring is desired. If the Echo 521 Request is used to measure synthetic packet loss, the receiver may 522 report loss measurement results to a remote node. Note that ways 523 of learning the identity of that node are outside the scope of 524 this specification. 526 * Reply via an IPv4/IPv6 UDP Packet (TBA6) value likely will be the 527 most used. 529 * Reply via Application Level Control Channel (TBA7) value if the 530 SFP may have bi-directional paths. 532 * Reply via Specified Path (TBA8) value to enforce the use of the 533 particular return path specified in the included TLV to verify bi- 534 directional continuity and also increase the robustness of the 535 monitoring by selecting a more stable path. 536 [I-D.ao-sfc-oam-return-path-specified] provides an example of 537 communicating an explicit path for the Echo Reply. 539 6.3.1. Source TLV 541 Responder to the SFC Echo Request encapsulates the SFC Echo Reply 542 message in IP/UDP packet if the Reply mode is "Reply via an IPv4/IPv6 543 UDP Packet". Because the NSH does not identify the ingress node that 544 generated the Echo Request, the source ID MUST be included in the 545 message and used as the IP destination address and destination UDP 546 port number of the SFC Echo Reply. The sender of the SFC Echo 547 Request MUST include an SFC Source TLV (Figure 5). 549 0 1 2 3 550 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Source ID | Reserved1 | Length | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Port Number | Reserved2 | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | IP Address | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Figure 5: SFC Source TLV 561 where 563 Source ID Type is a one-octet-long field and has the value of 564 TBA13 Section 9.4. 566 Reserved1 - one-octet-long field. 568 Length is a two-octets-long field, and the value equals the length 569 of the Value field in octets. The value of the Length field can 570 be 8 or 20. If the value of the field is neither, the Source TLV 571 is considered to be malformed. 573 Port Number is a two-octets-long field. It contains the UDP port 574 number of the sender of the SFC OAM control message. The value of 575 the field MUST be used as the destination UDP port number in the 576 IP/UDP encapsulation of the SFC Echo Reply message. 578 Reserved2 is a two-octets-long field. The field MUST be zeroed on 579 transmit and ignored on receipt. 581 IP Address field contains the IP address of the sender of the SFC 582 OAM control message, IPv4 or IPv6. The value of the field MUST be 583 used as the destination IP address in the IP/UDP encapsulation of 584 the SFC Echo Reply message. 586 A single Source ID TLV for each address family, i.e., IPv4 and IPv6, 587 MAY be present in an SFC Echo Request message. If the Source TLVs 588 for both address families are present in an SFC Echo Request message, 589 the SFF MUST NOT replicate an SFC Echo Reply but choose the 590 destination IP address for the SFC Echo Reply based on the local 591 policy. If more than one Source ID TLV per the address family is 592 present, the receiver MUST use the first TLV and ignore the rest. 594 6.4. SFC Echo Request Reception 596 Punting received SFC Echo Request to the control plane is triggered 597 by one of the following packet processing exceptions: NSH TTL 598 expiration, NSH Service Index (SI) expiration, or the receiver is the 599 terminal SFF for an SFP. 601 Firstly, if the SFC Echo Request is integrity-protected, the 602 receiving SFF first MUST verify the authentication. Then the 603 receiver SFF MUST validate the Source TLV, as defined in 604 Section 6.3.1. If the authentication validation has failed and the 605 Source TLV is considered properly formatted, the SFF MUST send to the 606 system identified in the Source TLV (see Section 6.5), according to a 607 rate-limit control mechanism, an SFC Echo Reply with the Return Code 608 set to "Authentication failed" and the Subcode set to zero. If the 609 Source TLV is determined malformed, the received SFC Echo Request 610 processing is stopped, the message is dropped, and the event SHOULD 611 be logged, according to a rate-limiting control for logging. Then, 612 the SFF that has received an SFC Echo Request verifies the rest of 613 the received packet's general sanity. If the packet is not well- 614 formed, the receiver SFF SHOULD send an SFC Echo Reply with the 615 Return Code set to "Malformed Echo Request received" and the Subcode 616 set to zero under the control of the rate-limiting mechanism to the 617 system identified in the Source TLV (see Section 6.5). If there are 618 any TLVs that the SFF does not understand, the SFF MUST send an SFC 619 Echo Reply with the Return Code set to 2 ("One or more TLVs was not 620 understood") and set the Subcode to zero. In the latter case, the 621 SFF MAY include an Errored TLVs TLV (Section 6.4.1) that, as sub- 622 TLVs, contains only the misunderstood TLVs. Sender's Handle and 623 Sequence Number fields are not examined but are included in the SFC 624 Echo Reply message. If the sanity check of the received Echo Request 625 succeeded, then the SFF at the end of the SFP MUST set the Return 626 Code value to 5 ("End of the SFP") and the Subcode set to zero. If 627 the SFF is not at the end of the SFP and the TTL value is 1, the 628 value of the Return Code MUST be set to 4 ("TTL Exceeded") and the 629 Subcode set to zero. In all other cases, SFF MUST set the Return 630 Code value to 0 ("No Return Code") and the Subcode set to zero. 632 6.4.1. Errored TLVs TLV 634 If the Return Code for the Echo Reply is determined as 2 ("One or 635 more TLVs was not understood"), the Errored TLVs TLV might be 636 included in an Echo Reply. The use of this TLV is meant to inform 637 the sender of an Echo Request of TLVs either not supported by an 638 implementation or parsed and found to be in error. 640 0 1 2 3 641 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Errored TLVs | Reserved | Length | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Value | 646 . . 647 . . 648 . . 649 | | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 Figure 6: Errored TLVs TLV 654 where 656 The Errored TLVs Type MUST be set to TBA14 Section 9.4. 658 Reserved - one-octet-long field. 660 Length - two-octet-long field equal to the length of the Value 661 field in octets. 663 The Value field contains the TLVs, encoded as sub-TLVs, that were 664 not understood or failed to be parsed correctly. 666 6.5. SFC Echo Reply Transmission 668 The "Reply Mode" field directs whether and how the Echo Reply message 669 should be sent. The sender of the Echo Request MAY use TLVs to 670 request that the corresponding Echo Reply is transmitted over the 671 specified path. [I-D.ao-sfc-oam-return-path-specified] provides an 672 example of a TLV that can be used to specify the return path of the 673 Echo Reply. Value TBA3 is referred to as the "Do not reply" mode and 674 suppresses the Echo Reply packet transmission. The default value 675 (TBA6) for the Reply mode field requests the responder to send the 676 Echo Reply packet out-of-band as IPv4 or IPv6 UDP packet. 678 6.6. SFC Echo Reply Reception 680 An SFF SHOULD NOT accept SFC Echo Reply unless the received message 681 passes the following checks: 683 * the received SFC Echo Reply is well-formed; 685 * it has an outstanding SFC Echo Request sent from the UDP port that 686 matches destination UDP port number of the received packet; 688 * if the matching to the Echo Request found, the value of the 689 Sender's Handle in the Echo Request sent is equal to the value of 690 Sender's Handle in the Echo Reply received; 692 * if all checks passed, the SFF checks if the Sequence Number in the 693 Echo Request sent matches to the Sequence Number in the Echo Reply 694 received. 696 6.7. Tracing an SFP 698 SFC Echo Request/Reply can be used to isolate a defect detected in 699 the SFP and trace an RSP. As for ICMP echo request/reply [RFC0792] 700 and MPLS echo request/reply [RFC8029], this mode is referred to as 701 "traceroute". In the traceroute mode, the sender transmits a 702 sequence of SFC Echo Request messages starting with the NSH TTL value 703 set to 1 and is incremented by 1 in each next Echo Request packet. 704 The sender stops transmitting SFC Echo Request packets when the 705 Return Code in the received Echo Reply equals 5 ("End of the SFP"). 707 Suppose a specialized information element (e.g., IPv6 Flow Label 708 [RFC6437] or Flow ID [I-D.ietf-sfc-nsh-tlv]) is used for distributing 709 the load across Equal Cost Multi-Path or Link Aggregation Group 710 paths. In that case, such an element MAY also be used for the SFC 711 OAM traffic. Doing so is meant to control whether the SFC Echo 712 Request follows the same RSP as the monitored flow. 714 7. Security Considerations 716 When the integrity protection for SFC active OAM, and SFC Echo 717 Request/Reply in particular, is required, it is RECOMMENDED to use 718 one of the Context Headers defined in [I-D.ietf-sfc-nsh-integrity]. 719 MAC#1 (Message Authentication Code) Context Header could be more 720 suitable for active SFC OAM because it does not require re- 721 calculation of the MAC when the value of the NSH Base Header's TTL 722 field is changed. The integrity protection for SFC active OAM can 723 also be achieved using mechanisms in the underlay data plane. For 724 example, if the underlay is an IPv6 network, IP Authentication Header 725 [RFC4302] or IP Encapsulating Security Payload Header [RFC4303] can 726 be used to provide integrity protection. Confidentiality for the SFC 727 Echo Request/Reply exchanges can be achieved using the IP 728 Encapsulating Security Payload Header [RFC4303]. Also, the security 729 needs for SFC Echo Request/Reply are similar to those of ICMP ping 730 [RFC0792], [RFC4443] and MPLS LSP ping [RFC8029]. 732 There are at least three approaches to attacking a node in the 733 overlay network using the mechanisms defined in the document. One is 734 a Denial-of-Service attack, sending an SFC Echo Request to overload 735 an element of the SFC. The second may use spoofing, hijacking, 736 replying, or otherwise tampering with SFC Echo Requests and/or 737 replies to misrepresent, alter the operator's view of the state of 738 the SFC. The third is an unauthorized source using an SFC Echo 739 Request/Reply to obtain information about the SFC and/or its 740 elements, e.g., SFF or SF. 742 It is RECOMMENDED that implementations throttle the SFC ping traffic 743 going to the control plane to mitigate potential Denial-of-Service 744 attacks. 746 Reply and spoofing attacks involving faking or replying to SFC Echo 747 Reply messages would have to match the Sender's Handle and Sequence 748 Number of an outstanding SFC Echo Request message, which is highly 749 unlikely. Thus the non-matching reply would be discarded. 751 To protect against unauthorized sources trying to obtain information 752 about the overlay and/or underlay, an implementation MAY check that 753 the source of the Echo Request is indeed part of the SFP. 755 8. Acknowledgments 757 Authors greatly appreciate thorough review and the most helpful 758 comments from Dan Wing, Dirk von Hugo, and Mohamed Boucadair. 760 9. IANA Considerations 762 9.1. SFC Active OAM Protocol 764 IANA is requested to assign a new type from the SFC Next Protocol 765 registry as follows: 767 +=======+================+===============+ 768 | Value | Description | Reference | 769 +=======+================+===============+ 770 | TBA1 | SFC Active OAM | This document | 771 +-------+----------------+---------------+ 773 Table 2: SFC Active OAM Protocol 775 9.2. SFC Active OAM 777 IANA is requested to create a new SFC Active OAM registry. 779 9.2.1. Version in the Active SFC OAM Header 781 IANA is requested to create in the SFC Active OAM registry a new sub- 782 registry called "SFC Active OAM Header Version". All code points are 783 assigned according to the "IETF Review" procedure specified in 784 [RFC8126]. The remaining code points to be allocated according to 785 Table 3: 787 +==============+=======================+===============+ 788 | Version | Description | Reference | 789 +==============+=======================+===============+ 790 | Version 0b00 | Protocol as defined | This document | 791 | | by this specification | | 792 +--------------+-----------------------+---------------+ 793 | Version 0b01 | Unassigned | This document | 794 +--------------+-----------------------+---------------+ 795 | Version 0b10 | Unassigned | This document | 796 +--------------+-----------------------+---------------+ 797 | Version 0b11 | Unassigned | This document | 798 +--------------+-----------------------+---------------+ 800 Table 3: SFC Active OAM Header Version 802 9.2.2. SFC Active OAM Message Type 804 IANA is requested to create in the SFC Active OAM registry a new sub- 805 registry called "SFC Active OAM Message Type". All code points in 806 the range 1 through 32767 in this registry shall be allocated 807 according to the "IETF Review" procedure specified in [RFC8126]. The 808 remaining code points to be allocated according to Table 4: 810 +===============+=============+=========================+ 811 | Value | Description | Reference | 812 +===============+=============+=========================+ 813 | 0 | Reserved | | 814 +---------------+-------------+-------------------------+ 815 | 1 - 32767 | Reserved | IETF Consensus | 816 +---------------+-------------+-------------------------+ 817 | 32768 - 65530 | Reserved | First Come First Served | 818 +---------------+-------------+-------------------------+ 819 | 65531 - 65534 | Reserved | Private Use | 820 +---------------+-------------+-------------------------+ 821 | 65535 | Reserved | | 822 +---------------+-------------+-------------------------+ 824 Table 4: SFC Active OAM Message Type 826 IANA is requested to assign a new type from the SFC Active OAM 827 Message Type sub-registry as follows: 829 +=======+=============================+===============+ 830 | Value | Description | Reference | 831 +=======+=============================+===============+ 832 | TBA2 | SFC Echo Request/Echo Reply | This document | 833 +-------+-----------------------------+---------------+ 835 Table 5: SFC Echo Request/Echo Reply Type 837 9.2.3. SFC Active OAM Header Flags 839 IANA is requested to create in the SFC Active OAM registry the new 840 sub-registry SFC Active OAM Flags. 842 This sub-registry tracks the assignment of 8 flags in the Flags field 843 of the SFC Active OAM Header. The flags are numbered from 0 (most 844 significant bit, transmitted first) to 7. 846 New entries are assigned by Standards Action. 848 +============+=============+===============+ 849 | Bit Number | Description | Reference | 850 +============+=============+===============+ 851 | 7-0 | Unassigned | This document | 852 +------------+-------------+---------------+ 854 Table 6: SFC Active OAM Header Flags 856 9.3. SFC Echo Request/Echo Reply Parameters 858 IANA is requested to create a new SFC Echo Request/Echo Reply 859 Parameters registry. 861 9.3.1. SFC Echo Request/Reply Version 863 IANA is requested to create in the SFC Echo Request/Echo Reply 864 Parameters registry a new sub-registry called "SFC Echo Request/Reply 865 Version". All code points assigned according to the "IETF Review" 866 procedure specified in [RFC8126]. The remaining code points to be 867 allocated according to Table 7: 869 +==============+=======================+===============+ 870 | Version | Description | Reference | 871 +==============+=======================+===============+ 872 | Version 0b00 | Protocol as defined | This document | 873 | | by this specification | | 874 +--------------+-----------------------+---------------+ 875 | Version 0b01 | Unassigned | This document | 876 +--------------+-----------------------+---------------+ 877 | Version 0b10 | Unassigned | This document | 878 +--------------+-----------------------+---------------+ 879 | Version 0b11 | Unassigned | This document | 880 +--------------+-----------------------+---------------+ 882 Table 7: SFC Echo Request/Reply Version 884 9.3.2. SFC Echo Request Flags 886 IANA is requested to create in the SFC Echo Request/Echo Reply 887 Parameters registry the new sub-registry SFC Echo Request Flags. 889 This sub-registry tracks the assignment of 16 flags in the SFC Echo 890 Request Flags field of the SFC Echo Request message. The flags are 891 numbered from 0 (most significant bit, transmitted first) to 15. 893 New entries are assigned by Standards Action. 895 +============+=============+===============+ 896 | Bit Number | Description | Reference | 897 +============+=============+===============+ 898 | 15-0 | Unassigned | This document | 899 +------------+-------------+---------------+ 901 Table 8: SFC Echo Request Flags 903 9.3.3. SFC Echo Request/Echo Reply Message Types 905 IANA is requested to create in the SFC Echo Request/Echo Reply 906 Parameters registry the new sub-registry Message Types. All code 907 points in the range 1 through 175 in this registry shall be allocated 908 according to the "IETF Review" procedure specified in [RFC8126]. 909 Code points in the range 176 through 239 in this registry shall be 910 allocated according to the "First Come First Served" procedure 911 specified in [RFC8126]. The remaining code points are allocated as 912 specified in Table 9. 914 +===========+==============+===============+ 915 | Value | Description | Reference | 916 +===========+==============+===============+ 917 | 0 | Reserved | This document | 918 +-----------+--------------+---------------+ 919 | 1- 175 | Unassigned | This document | 920 +-----------+--------------+---------------+ 921 | 176 - 239 | Unassigned | This document | 922 +-----------+--------------+---------------+ 923 | 240 - 251 | Experimental | This document | 924 +-----------+--------------+---------------+ 925 | 252 - 254 | Private Use | This document | 926 +-----------+--------------+---------------+ 927 | 255 | Reserved | This document | 928 +-----------+--------------+---------------+ 930 Table 9: SFC Echo Request/Echo Reply 931 Message Types 933 IANA is requested to assign values as listed in Table 10. 935 +=======+==================+===============+ 936 | Value | Description | Reference | 937 +=======+==================+===============+ 938 | TBA3 | SFC Echo Request | This document | 939 +-------+------------------+---------------+ 940 | TBA4 | SFC Echo Reply | This document | 941 +-------+------------------+---------------+ 943 Table 10: SFC Echo Request/Echo Reply 944 Message Types Values 946 9.3.4. SFC Echo Reply Modes 948 IANA is requested to create in the SFC Echo Request/Echo Reply 949 Parameters registry the new sub-registry Reply Mode. All code points 950 in the range 1 through 175 in this registry shall be allocated 951 according to the "IETF Review" procedure specified in [RFC8126]. 952 Code points in the range 176 through 239 in this registry shall be 953 allocated according to the "First Come First Served" procedure 954 specified in [RFC8126]. The remaining code points are allocated 955 according to Table 11. 957 +===========+==============+===============+ 958 | Value | Description | Reference | 959 +===========+==============+===============+ 960 | 0 | Reserved | This document | 961 +-----------+--------------+---------------+ 962 | 1- 175 | Unassigned | This document | 963 +-----------+--------------+---------------+ 964 | 176 - 239 | Unassigned | This document | 965 +-----------+--------------+---------------+ 966 | 240 - 251 | Experimental | This document | 967 +-----------+--------------+---------------+ 968 | 252 - 254 | Private Use | This document | 969 +-----------+--------------+---------------+ 970 | 255 | Reserved | This document | 971 +-----------+--------------+---------------+ 973 Table 11: SFC Echo Reply Mode 975 All code points in the range 1 through 191 in this registry shall be 976 allocated according to the "IETF Review" procedure specified in 977 [RFC8126] and assign values as listed in Table 12. 979 +=======+====================================+===============+ 980 | Value | Description | Reference | 981 +=======+====================================+===============+ 982 | 0 | Reserved | | 983 +-------+------------------------------------+---------------+ 984 | TBA5 | Do Not Reply | This document | 985 +-------+------------------------------------+---------------+ 986 | TBA6 | Reply via an IPv4/IPv6 UDP Packet | This document | 987 +-------+------------------------------------+---------------+ 988 | TBA7 | Reply via Application Level | This document | 989 | | Control Channel | | 990 +-------+------------------------------------+---------------+ 991 | TBA8 | Reply via Specified Path | This document | 992 +-------+------------------------------------+---------------+ 993 | TBA9 | Reply via an IPv4/IPv6 UDP Packet | This document | 994 | | with the data integrity protection | | 995 +-------+------------------------------------+---------------+ 996 | TBA10 | Reply via Application Level | This document | 997 | | Control Channel with the data | | 998 | | integrity protection | | 999 +-------+------------------------------------+---------------+ 1000 | TBA11 | Reply via Specified Path with the | This document | 1001 | | data integrity protection | | 1002 +-------+------------------------------------+---------------+ 1004 Table 12: SFC Echo Reply Mode Values 1006 9.3.5. SFC Echo Return Codes 1008 IANA is requested to create in the SFC Echo Request/Echo Reply 1009 Parameters registry the new sub-registry Return Codes as described in 1010 Table 13. 1012 +=========+=============+=========================+ 1013 | Value | Description | Reference | 1014 +=========+=============+=========================+ 1015 | 0-191 | Unassigned | IETF Review | 1016 +---------+-------------+-------------------------+ 1017 | 192-251 | Unassigned | First Come First Served | 1018 +---------+-------------+-------------------------+ 1019 | 252-254 | Unassigned | Private Use | 1020 +---------+-------------+-------------------------+ 1021 | 255 | Reserved | | 1022 +---------+-------------+-------------------------+ 1024 Table 13: SFC Echo Return Codes 1026 Values defined for the Return Codes sub-registry are listed in 1027 Table 14. 1029 +=======+=================================+===============+ 1030 | Value | Description | Reference | 1031 +=======+=================================+===============+ 1032 | 0 | No Return Code | This document | 1033 +-------+---------------------------------+---------------+ 1034 | 1 | Malformed Echo Request received | This document | 1035 +-------+---------------------------------+---------------+ 1036 | 2 | One or more of the TLVs was not | This document | 1037 | | understood | | 1038 +-------+---------------------------------+---------------+ 1039 | 3 | Authentication failed | This document | 1040 +-------+---------------------------------+---------------+ 1041 | 4 | TTL Exceeded | This document | 1042 +-------+---------------------------------+---------------+ 1043 | 5 | End of the SFP | This document | 1044 +-------+---------------------------------+---------------+ 1046 Table 14: SFC Echo Return Codes Values 1048 9.4. SFC Active OAM TLV Type 1050 IANA is requested to create the SFC Active OAM TLV Type registry. 1051 All code points in the range 1 through 175 in this registry shall be 1052 allocated according to the "IETF Review" procedure specified in 1053 [RFC8126]. Code points in the range 176 through 239 in this registry 1054 shall be allocated according to the "First Come First Served" 1055 procedure specified in [RFC8126]. The remaining code points are 1056 allocated according to Table 15: 1058 +===========+==============+===============+ 1059 | Value | Description | Reference | 1060 +===========+==============+===============+ 1061 | 0 | Reserved | This document | 1062 +-----------+--------------+---------------+ 1063 | 1- 175 | Unassigned | This document | 1064 +-----------+--------------+---------------+ 1065 | 176 - 239 | Unassigned | This document | 1066 +-----------+--------------+---------------+ 1067 | 240 - 251 | Experimental | This document | 1068 +-----------+--------------+---------------+ 1069 | 252 - 254 | Private Use | This document | 1070 +-----------+--------------+---------------+ 1071 | 255 | Reserved | This document | 1072 +-----------+--------------+---------------+ 1074 Table 15: SFC Active OAM TLV Type Registry 1076 This document defines the following new values in SFC Active OAM TLV 1077 Type registry: 1079 +=======+====================+===============+ 1080 | Value | Description | Reference | 1081 +=======+====================+===============+ 1082 | TBA12 | Multiple TLVs Used | This document | 1083 +-------+--------------------+---------------+ 1084 | TBA13 | Source ID TLV | This document | 1085 +-------+--------------------+---------------+ 1086 | TBA14 | Errored TLVs | This document | 1087 +-------+--------------------+---------------+ 1089 Table 16: SFC OAM Type Values 1091 10. References 1093 10.1. Normative References 1095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", BCP 14, RFC 2119, 1097 DOI 10.17487/RFC2119, March 1997, 1098 . 1100 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1101 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1102 May 2017, . 1104 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1105 "Network Service Header (NSH)", RFC 8300, 1106 DOI 10.17487/RFC8300, January 2018, 1107 . 1109 10.2. Informative References 1111 [I-D.ao-sfc-oam-return-path-specified] 1112 Mirsky, G., Ao, T., Chen, Z., and G. Mishra, "Controlled 1113 Return Path for Service Function Chain (SFC) OAM", Work in 1114 Progress, Internet-Draft, draft-ao-sfc-oam-return-path- 1115 specified-09, 30 March 2021, . 1118 [I-D.ietf-sfc-nsh-integrity] 1119 Boucadair, M., Reddy, T., and D. Wing, "Integrity 1120 Protection for the Network Service Header (NSH) and 1121 Encryption of Sensitive Context Headers", Work in 1122 Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-05, 1123 23 March 2021, . 1126 [I-D.ietf-sfc-nsh-tlv] 1127 Wei, Y. (., Elzur, U., Majee, S., and C. Pignataro, 1128 "Network Service Header Metadata Type 2 Variable-Length 1129 Context Headers", Work in Progress, Internet-Draft, draft- 1130 ietf-sfc-nsh-tlv-06, 12 May 2021, 1131 . 1133 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1134 RFC 792, DOI 10.17487/RFC0792, September 1981, 1135 . 1137 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1138 DOI 10.17487/RFC4302, December 2005, 1139 . 1141 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1142 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1143 . 1145 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1146 Control Message Protocol (ICMPv6) for the Internet 1147 Protocol Version 6 (IPv6) Specification", STD 89, 1148 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1149 . 1151 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1152 "IPv6 Flow Label Specification", RFC 6437, 1153 DOI 10.17487/RFC6437, November 2011, 1154 . 1156 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1157 Chaining (SFC) Architecture", RFC 7665, 1158 DOI 10.17487/RFC7665, October 2015, 1159 . 1161 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 1162 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1163 May 2016, . 1165 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 1166 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 1167 Switched (MPLS) Data-Plane Failures", RFC 8029, 1168 DOI 10.17487/RFC8029, March 2017, 1169 . 1171 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1172 Writing an IANA Considerations Section in RFCs", BCP 26, 1173 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1174 . 1176 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 1177 Forwarding Plane for Service Function Chaining", RFC 8595, 1178 DOI 10.17487/RFC8595, June 2019, 1179 . 1181 [RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, 1182 R., and A. Ghanwani, "Service Function Chaining (SFC) 1183 Operations, Administration, and Maintenance (OAM) 1184 Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020, 1185 . 1187 Authors' Addresses 1188 Greg Mirsky 1189 ZTE Corp. 1191 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 1193 Wei Meng 1194 ZTE Corporation 1195 No.50 Software Avenue, Yuhuatai District 1196 Nanjing, 1197 China 1199 Email: meng.wei2@zte.com.cn 1201 Bhumip Khasnabish 1202 Individual contributor 1204 Email: vumip1@gmail.com 1206 Cui Wang 1207 Individual contributor 1209 Email: lindawangjoy@gmail.com