idnits 2.17.1 draft-lm-mpls-sfc-path-verification-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2020) is 1278 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-spring-sr-service-programming-03 == Outdated reference: A later version (-15) exists of draft-ietf-sfc-nsh-tlv-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Y. Liu 3 Internet-Draft G. Mirsky 4 Intended status: Standards Track ZTE Corporation 5 Expires: April 28, 2021 October 25, 2020 7 MPLS-based Service Function Path(SFP) Consistency Verification 8 draft-lm-mpls-sfc-path-verification-01 10 Abstract 12 This document proposes a method to verify the correlation between 13 Service Function Chaining control and/or management plane view of the 14 specified Service Function Path and the state of its data. It works 15 for both SR service programming and MPLS-based NSH SFC. 17 This document defines the signaling of the Generic Associated Channel 18 (G-ACh) over a Service Function Path (SFP) with an MPLS forwarding 19 plane using the basic unit defined in RFC 8595. The document also 20 describes the processing of the G-ACh by the elements of the SFP. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 28, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 3 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. MPLS-based SFP Consistency Verification . . . . . . . . . . . 4 61 3.1. Special-purpose Label in SFC-MPLS Environment . . . . . . 5 62 3.1.1. G-ACh over SFC-MPLS . . . . . . . . . . . . . . . . . 6 63 3.2. MPLS-based SFP Consistency Verification . . . . . . . . . 6 64 3.3. SFC Info Sub-TLV . . . . . . . . . . . . . . . . . . . . 7 65 3.4. SFC Basic Unit FEC Sub-TLV . . . . . . . . . . . . . . . 8 66 3.5. Theory of Operation . . . . . . . . . . . . . . . . . . . 9 67 3.5.1. MPLS-based service programming . . . . . . . . . . . 10 68 3.5.2. Path Consistency in SFC-MPLS . . . . . . . . . . . . 10 69 3.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 10 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 5.1. SFC Validation TLV . . . . . . . . . . . . . . . . . . . 11 73 5.1.1. Sub-TLVs for SFC Validation TLV . . . . . . . . . . . 11 74 5.2. SFC Basic Unit sub-TLV . . . . . . . . . . . . . . . . . 12 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 6.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 Service Function Chain (SFC) defined in [RFC7665] as an ordered set 83 of service functions (SFs) to be applied to packets and/or frames, 84 and/or flows selected as a result of classification. 86 SFC can be achieved through a variety of encapsulation methods, such 87 as NSH [RFC8300], SR service programming 88 [I-D.ietf-spring-sr-service-programming] and MPLS-based NSH SFC 89 [RFC8595]. 91 This document describes extensions to MPLS LSP ping [RFC8029] 92 mechanisms to support verification between the control/management 93 plane and the data plane state for both SR-MPLS service programming 94 and MPLS-based NSH SFC. 96 An MPLS LSP ping is a component of the MPLS Operation, 97 Administration, and Maintenance (OAM) toolset. OAM packets used to 98 monitor a specific Service Function Path (SFP) can be transported 99 over a Generic Associated Channel (G-ACh). This document defines the 100 signaling of the G-ACh over an SFP with an MPLS forwarding plane 101 using the basic unit defined in [RFC8595]. The document also 102 describes the processing of the G-ACh by the elements of the SFP. 104 2. Conventions used in this document 106 2.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 2.2. Acronyms 116 SFC: Service Function Chain 118 SFF: Service Function Forwarder 120 SF: Service Function 122 SFI: Instance of an SF 124 SFP: Service Function Path 126 RSP: Rendered Service Path 128 SFC-MPLS: SFC over an MPLS forwarding plane 130 SPL: Special-Purpose Label 132 bSPL: Base SPL 134 eSPL: Extended SPL 136 GAL: Generic Associated Channel Label 138 ELI: Entropy Label Indicator 140 OAM: Operation, Administration, and Maintenance 142 G-ACh: Generic Associated Channel 143 GAL: Generic Associated Channel Label 145 3. MPLS-based SFP Consistency Verification 147 MPLS echo request and reply messages [RFC8029] can be extended to 148 support the verification of the consistency of an MPLS-based Service 149 Function Path (SFP). 151 SR-MPLS/MPLS can be used to realize an SFP. Two methods have been 152 defined: 154 o [I-D.ietf-spring-sr-service-programming] describes how to achieve 155 service function chaining in SR-enabled MPLS and IPv6 networks. 156 In an SR-MPLS network, each SF is associated with an MPLS label. 157 As a result, an SFP can be encoded as a stack of MPLS labels and 158 pushed on top of the packet. 160 o [RFC8595] provides another method to realize SFC in an MPLS 161 network by means of using a logical representation of the Network 162 Service Header (NSH) in an MPLS label stack. This method, 163 throughout this document, is referred to as SFC over an MPLS data 164 plane (SFC-MPLS). When an MPLS label stack is used to carry a 165 logical NSH, a basic unit of representation is used, which can be 166 present one or more times in the label stack. This unit comprises 167 two MPLS labels, one carries a label to provide a context within 168 the SFC scope (the SFC Context Label), and the other carries a 169 label to show which SF is to be enacted (the SF Label). This two- 170 label unit is shown in Figure 1. 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | SFC Context Label | TC |S| TTL | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | SF Label | TC |S| TTL | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 1: The Basic Unit of MPLS Label Stack for SFC 182 In MPLS Label Switched Paths (LSPs), MPLS LSP ping [RFC8029] is used 183 to check the correctness of the data plane functioning and to verify 184 the data plane against the control plane. 186 The proposed extension of MPLS LSP ping allows verification of the 187 correlation between the control/management (if data model-based 188 central controller used) plane and the data plane state in SR-MPLS/ 189 MPLS-based SFC. 191 Generally, except for the designed specific functions, the packet 192 processing functions supported by SFs are limited. SFs may not 193 support control and/or management protocols operated over the G-ACh 194 defined n [RFC5586], e.g., MPLS OAM protocols like LSP ping. To 195 avoid such packets mishandled, SFFs are responsible for MPLS echo 196 request processing. To support that processing, the basic unit can 197 use the mechanism described in Section 3.1. 199 3.1. Special-purpose Label in SFC-MPLS Environment 201 When an SFC-MPLS is used, an SFF needs to identify an OAM packet with 202 the SFP scope. To achieve that, this specification first defines the 203 use of a base special-purpose label (bSPL) [RFC3032] or an extended 204 special-purpose label (eSPL) [RFC7274] (referred in this document as 205 SPL Unit) with the basic unit defined in [RFC8595]. And based on 206 that, the use of Generic Associated Channel Label (GAL) [RFC5586] 207 with the basic unit in the SFC-MPLS environment. 209 Special-purpose label (SPL), whether bSPL or eSPL, have special 210 significance in the data and control planes. An ability to use an 211 SPL in the basic unit allows for a closer functional match between 212 the NSH-based SFC and SFC-MPLS. For example, Entropy Label Indicator 213 (ELI) [RFC6790] with the basic unit can be used as the Flow ID TLV 214 [I-D.ietf-sfc-nsh-tlv] to allow an SFF to balance SFC flows among SFs 215 of the same type. An SPL MAY be used with the basic unit in SFC- 216 MPLS, as displayed in Figure 2. Note that an SPL unit MAY be present 217 in one or more basic units when MPLS label stacking is used to carry 218 the SFC information. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | SFC Context Label | TC |S| TTL | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | SPL Unit | 226 ~ ~ 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | SF Label | TC |S| TTL | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 2: Special-purpose Label Unit with the Basic Unit of MPLS 232 Label Stack for SFC 234 3.1.1. G-ACh over SFC-MPLS 236 SFC-MPLS environment could include instances of an SF (SFI) or SFC 237 proxies that cannot properly process control and/or management 238 protocol messages that are exchanged between nodes over the G-ACh 239 associated with the particular SFP. To support OAM over G-ACh, it is 240 beneficial to avoid handing over a test packet to the SFI or SFC 241 proxy. Hence, this specification defines that if the Generic 242 Associated Channel Label (GAL) immediately follows the SFC Context 243 label [RFC8595], then the packet is recognized as an SFP OAM packet. 245 Below are the processing rules of an SFP OAM packet by an SFF: 247 o An SFF MUST NOT pass the packet to a local SFI or SFC proxy. 249 o The SFF MUST decrement SF Label entry's TTL value. If the 250 resulting value equals zero, the SFF MUST pass the SFP OAM packet 251 to the control plane for processing. An implementation that 252 supports this specification MUST provide control to limit the rate 253 of SFP OAM packets passed to the control plane for processing. 255 o If the TTL value is not zero, the SFP OAM packet is processed as 256 defined in Section 6, Section 7, and Section 8 [RFC8595], 257 according to the type of MPLS forwarding used in the SFP. 259 3.2. MPLS-based SFP Consistency Verification 261 An MPLS SFC validation request/reply is an MPLS echo request/reply 262 that includes an SFC validation TLV (shown in Figure 3). 264 Nodes examine and process the TLV only if configured to do so; other 265 nodes MUST ignore the TLV and process the packet as a standard MPLS 266 echo packet. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | TLV Type=TBA1 | Length | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 | SFC Information Sub-TLV(s) | 275 ~ ~ 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 3: SFC Validation TLV 281 SFC Information Sub-TLV: The Sub-TLV, as presented in Figure 4, MUST 282 NOT be included in an MPLS SFC validation request. 284 3.3. SFC Info Sub-TLV 286 Upon receiving the SFC validation request, the SFF MUST respond with 287 an echo reply, which includes the SFC detailed information. 289 The SFC detailed information is recorded in SFC info sub-TLV. 291 Two types of sub-TLVs are defined in this section, and those are used 292 in MPLS-based service programming 293 [I-D.ietf-spring-sr-service-programming] and MPLS-based NSH [RFC8595] 294 respectively. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | sub-TLV Type=TBA2 | Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | SFF Label | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | SF Label | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | SF Type | SR Proxy Type | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 4: SFC Info Sub-TLV for SR-MPLS-based Service Programming 310 Type TBA2 sub-TLV: used in SR-MPLS-based service programming 312 SFF Label: represents the SID of the SFF 314 SF Label: represents the service SID of the SF or SR proxy 316 SF Type: indicates the type of SF, such as DPI, firewall, etc. 318 SR Proxy Type: It is defined in 319 [I-D.ietf-spring-sr-service-programming] and indicates the type of SR 320 proxy if it exists. 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | sub-TLV Type=TBA3 | Length | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | SFC-FWD Type | Reserved | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | SFC context Label | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | SF Label | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | SF Type | Reserved | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 5: SFC Info Sub-TLV for MPLS-based NSH 338 Figure 5 presents the format of a sub-TLV for MPLS-based NSH. The 339 fields are as follows: 341 Type TBA3 sub-TLV: used in MPLS-based NSH 343 SFC-FWD Type: indicates the forwarding type of the data plane, and 344 has the following values: 346 0x10: MPLS-based NSH [RFC8595] label swapping 348 0x11: MPLS-based NSH [RFC8595] label stacking 350 SFC context Label: The meaning of the SFC context label depends on 351 the SFC Type. If SFC-FWD Type is 0x10, the SFC context Label 352 represents SPI. If SFC-FWD Type is 0x11, the SFC context Label 353 represents the context label [RFC8595]. 355 SF Label: The meaning of the SF label depends on the SFC-FWD Type. 356 If SFC Type is 0x10, the SF Label represents SI. If SFC Type is 357 0x11, the SF Label represents the SFI index [RFC8595]. 359 SF Type: It is defined in [I-D.ietf-bess-nsh-bgp-control-plane] and 360 indicates the type of SF, such as DPI, firewall, etc. 362 3.4. SFC Basic Unit FEC Sub-TLV 364 Unlike standard MPLS forwarding, based on a single label, packet 365 forwarding defined in [RFC8595] is based on the basic unit of MPLS 366 label stack for SFC(SFC Context Label+SF Label). A new SFC Basic 367 Unit FEC sub-TLV with Type value (TBA4) is defined in this document. 369 The SFC Basic Unit FEC sub-TLV MAY be used to carry the corresponding 370 FEC of the basic unit. 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Route Distinguisher (RD) | 376 | (8 octets) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | SF Type | Reserved | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Figure 6: SFC Basic Unit sub-TLV 383 The format of the basic unit sub-TLV is shown in Figure 6 and 384 includes the following fields: 386 Route Distinguisher (RD): 8 octets field in SFIR Route Type 387 specific NLRI [I-D.ietf-bess-nsh-bgp-control-plane]. 389 SF Type: 2 octets. It is defined in [I-D.ietf-bess-nsh-bgp- 390 control-plane] and indicates the type of SF, such as DPI, 391 firewall, etc. 393 SFC Basic Unit sub-TLV is defined for Target FEC Stack TLV(Type 1 394 TLV). 396 A node that receives an LSP ping with the Target FEC Stack TLV and 397 the SFC Basic Unit FEC Sub-TLV included will check if it is its Route 398 Distinguisher and whether it advertised that Service Function Type. 399 If the validation is not passed, the SFF will generate an MPLS echo 400 reply with an error code as defined in [RFC8029]. 402 3.5. Theory of Operation 404 An MPLS SFC validation request is an MPLS echo request with an SFC 405 validation TLV, and the echo request is sent with a label stack 406 corresponding to the SFP being tested. To trace SFC-MPLS, the 407 Generic Associated Channel Label (GAL) which immediately follows the 408 SFC Context label is also included. 410 Sending an SFC echo request to the control plane is triggered by one 411 of the following packet processing exceptions: IP TTL expiration, 412 MPLS TTL expiration, or the receiver is the terminal SFF for an SFP. 414 After general packet sanity verifying [RFC8029], Section 3.5.1 and 415 Section 3.5.2 in this document separately describe the following 416 processing procedures in service programming and MPLS-based NSH. 418 After all SFFs on the SFP send back MPLS echo reply, the sender 419 collects information about all traversed SFFs and SFs on the rendered 420 service path (RSP). 422 3.5.1. MPLS-based service programming 424 [I-D.ietf-spring-sr-service-programming] describes how a service can 425 be associated with a SID to achieve service function chaining. In an 426 SR-MPLS network, the SFP is encoded as a stack of MPLS labels. That 427 stack is pushed on top of the packet. 429 Before generating an echo relpy, an SFF MUST parse through the label 430 stack until the next label is not a local service SID to get all the 431 SFs attached to the SFF on the SFP and record the corresponding 432 Label-stack-depth. 434 The SFF then sends an MPLS echo reply with all the SF information 435 recorded in SFC Information Sub-TLV, including the service SID and 436 the SF type. 438 3.5.2. Path Consistency in SFC-MPLS 440 [RFC8595] describes how Service Function Chaining (SFC) can be 441 achieved in an MPLS network using a logical representation of the 442 Network Service Header (NSH) in an MPLS label stack. 444 SFC forwarding can be achieved by label swapping, label stacking, or 445 the mix of both. When an SFF receives a packet containing an MPLS 446 label stack, it examines the top basic unit of MPLS label stack for 447 SFC, {SPI, SI} or {context label, SFI index}, to determine where to 448 send the packet next. 450 As described in Section 3.1.1, the packet with GAL is recognized by 451 the SFF as an SFP OAM packet. The SFF then decrements SF Label 452 entry's TTL value. If the resulting value equals zero, the SFF 453 passes the SFP OAM packet to the control plane for processing. The 454 system that supports ths specification generates a reply message, 455 including in it the SFC info sub-TLV as desribed in Section 3.3. 457 3.6. Discussion 459 In [RFC8595], it says, "when an SFF receives a packet from any 460 component of the SFC system (classifier, SFI, or another SFF), it 461 MUST discard any packets with TTL set to zero". To trace SFC, it 462 should be changed to allow punting the packet to the control plane 463 though under throttling control. 465 4. Security Considerations 467 This specification defines the processing of an SFP OAM packet. Such 468 packets could be used as an attack vector. A system that supports 469 this specification MUST provide control to limit the rate of SFP OAM 470 packets sent to the control plane for processing. 472 5. IANA Considerations 474 This document requests assigning type values for TLVs and sub-TLVs 475 from the IANA "Multiprotocol Label Switching (MPLS) Label Switched 476 Paths (LSPs) Ping Parameters" registry as described in the sub- 477 sections below. 479 5.1. SFC Validation TLV 481 IANA is requested to assign a type from the Standards Action range of 482 the "TLVs" registry according to Table 1: 484 +-------+----------------+---------------+ 485 | Value | Description | Reference | 486 +-------+----------------+---------------+ 487 | TBA1 | SFC Validation | This document | 488 +-------+----------------+---------------+ 490 Table 1: Type Value for SFC Validation TLV 492 5.1.1. Sub-TLVs for SFC Validation TLV 494 Two sub-TLVs of SFC Validation TLV is defined in this document 495 according to Table 2. 497 +-------+-------------------------------------------+---------------+ 498 | Value | Description | Reference | 499 +-------+-------------------------------------------+---------------+ 500 | TBA2 | Info for SR-MPLS- | This document | 501 | | based Service Programming | | 502 | TBA3 | Info for MPLS-based NSH | This document | 503 +-------+-------------------------------------------+---------------+ 505 Table 2: Sub-TLV Values for SFC Validation TLV 507 5.2. SFC Basic Unit sub-TLV 509 IANA is requested to assign a type from the Standards Action range of 510 the "Sub-TLVs for TLV Types 1, 16, and 21" registry according to 511 Table 3: 513 +-------+----------------+---------------+ 514 | Value | Description | Reference | 515 +-------+----------------+---------------+ 516 | TBA4 | SFC Basic Unit | This document | 517 +-------+----------------+---------------+ 519 Table 3: Type Value for SFC Basic Unit sub-TLV 521 6. References 523 6.1. Normative References 525 [I-D.ietf-bess-nsh-bgp-control-plane] 526 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 527 Jalil, "BGP Control Plane for the Network Service Header 528 in Service Function Chaining", draft-ietf-bess-nsh-bgp- 529 control-plane-18 (work in progress), August 2020. 531 [I-D.ietf-spring-sr-service-programming] 532 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 533 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 534 Henderickx, W., and S. Salsano, "Service Programming with 535 Segment Routing", draft-ietf-spring-sr-service- 536 programming-03 (work in progress), September 2020. 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, 540 DOI 10.17487/RFC2119, March 1997, 541 . 543 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 544 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 545 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 546 . 548 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 549 "MPLS Generic Associated Channel", RFC 5586, 550 DOI 10.17487/RFC5586, June 2009, 551 . 553 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 554 and Retiring Special-Purpose MPLS Labels", RFC 7274, 555 DOI 10.17487/RFC7274, June 2014, 556 . 558 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 559 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 560 Switched (MPLS) Data-Plane Failures", RFC 8029, 561 DOI 10.17487/RFC8029, March 2017, 562 . 564 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 565 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 566 May 2017, . 568 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 569 "Network Service Header (NSH)", RFC 8300, 570 DOI 10.17487/RFC8300, January 2018, 571 . 573 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 574 Forwarding Plane for Service Function Chaining", RFC 8595, 575 DOI 10.17487/RFC8595, June 2019, 576 . 578 6.2. Informative References 580 [I-D.ietf-sfc-nsh-tlv] 581 Wei, Y., Elzur, U., and S. Majee, "Network Service Header 582 Metadata Type 2 Variable-Length Context Headers", draft- 583 ietf-sfc-nsh-tlv-03 (work in progress), May 2020. 585 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 586 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 587 RFC 6790, DOI 10.17487/RFC6790, November 2012, 588 . 590 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 591 Chaining (SFC) Architecture", RFC 7665, 592 DOI 10.17487/RFC7665, October 2015, 593 . 595 Authors' Addresses 596 Liu Yao 597 ZTE Corporation 598 No. 50 Software Ave, Yuhuatai Distinct 599 Nanjing 600 China 602 Email: liu.yao71@zte.com.cn 604 Greg Mirsky 605 ZTE Corporation 607 Email: gregimirsky@gmail.com