idnits 2.17.1 draft-ao-sfc-oam-path-consistency-11.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 (30 March 2021) is 1123 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 (-28) exists of draft-ietf-sfc-multi-layer-oam-09 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-nsh-integrity-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track T. Ao 5 Expires: 1 October 2021 Individual contributor 6 Z. Chen 7 China Telecom 8 K. Leung 9 Cisco System 10 G. Mishra 11 Verizon Inc. 12 30 March 2021 14 SFC OAM for path consistency 15 draft-ao-sfc-oam-path-consistency-11 17 Abstract 19 Service Function Chain (SFC) defines an ordered set of service 20 functions (SFs) to be applied to packets and/or frames and/or flows 21 selected due to classification. SFC Operation, Administration and 22 Maintenance can monitor the continuity of the SFC, i.e., that all SFC 23 elements are reachable to each other in the downstream direction. 24 But SFC OAM must support verification that the order of traversing 25 these SFs corresponds to the state defined by the SFC control plane 26 or orchestrator, the metric referred to in this document as the path 27 consistency of the SFC. This document defines a new SFC active OAM 28 method to support SFC consistency check, i.e., verification that all 29 elements of the given SFC are being traversed in the expected order. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 1 October 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions used in this document . . . . . . . . . . . . . . 3 66 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 3. Consistency OAM: Theory of Operation . . . . . . . . . . . . 3 69 3.1. COAM packet . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. SFF Information Record TLV . . . . . . . . . . . . . . . 5 71 3.3. SF Information Sub-TLV . . . . . . . . . . . . . . . . . 6 72 3.4. SF Information Sub-TLV Construction . . . . . . . . . . . 7 73 3.4.1. Multiple SFs as hops of SFP . . . . . . . . . . . . . 7 74 3.4.2. Multiple SFs for load balance . . . . . . . . . . . . 8 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 5.1. COAM Message Types . . . . . . . . . . . . . . . . . . . 9 78 5.2. SFF Information Record TLV Type . . . . . . . . . . . . . 9 79 5.3. SF Information Sub-TLV Type . . . . . . . . . . . . . . . 9 80 5.4. SF Identifier Types . . . . . . . . . . . . . . . . . . . 10 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 7.2. Informational References . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 Service Function Chain (SFC) is a chain with a series of ordered 90 Service Functions (SFs). Service Function Path (SFP) is a path of a 91 SFC. SFC is described in detail in the SFC architecture document 92 [RFC7665]. The SFs in the SFC are ordered, i.e., only when an SF 93 processes traffic, then it can be processed by the next SF. Changes 94 in the order are very likely to cause errors. That's why an operator 95 needs to ensure that the order of traversing the SFs is as defined by 96 the control plane or the orchestrator. This document refers to the 97 correlation between the state of the control plane and the SFP itself 98 as the SFP consistency. The need to verify the consistency of the 99 particular SFP, using a mechanism of an active OAM protocol, is noted 100 in [RFC8924]. 102 This document defines the method to check the path consistency of the 103 SFP. It is an extension of the SFC Echo-request/Echo-reply specified 104 in the [I-D.ietf-sfc-multi-layer-oam]. 106 2. Conventions used in this document 108 2.1. Acronyms 110 SFC: Service Function Chain. An ordered set of some abstract SFs. 112 SFF: Service Function Forwarder 114 SF: Service Function 116 OAM: Operation, Administration and Maintenance 118 SFP: Service Function Path 120 COAM: Consistency OAM, OAM that can be used to check the consistency 121 of the Service Function Path. 123 MAC: Message Authentication Code 125 2.2. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. Consistency OAM: Theory of Operation 135 Consistency OAM (COAM) uses two functions: COAM Request and COAM 136 Reply. Every SFF that receives the COAM Request MUST perform the 137 following actions: 139 * Collect information of the traversed by the COAM Request packet 140 SFs and send it to the ingress SFF as COAM Reply packet over IP 141 network [I-D.ietf-sfc-multi-layer-oam]; 143 * Forward the COAM Request to the next downstream SFF if the one 144 exists. 146 As a result, the ingress SFF collects information about all traversed 147 SFFs and SFs, information on the actual path the COAM packet has 148 traveled. That information is used to verify the SFC's path 149 consistency. The mechanism for the SFP consistency verification is 150 outside the scope of this document. 152 3.1. COAM packet 154 Consistency OAM introduces two new types of messages to the SFC Echo 155 Request/Reply operation defined in [I-D.ietf-sfc-multi-layer-oam] 156 with the following values detailed in Section 5.1: 158 * TBA1 - COAM Request 160 * TBA2 - COAM Reply 162 Upon receiving the COAM Request, the SFF MUST respond with the COAM 163 Reply. The SFF MUST include the SFs information, as described in 164 Section 3.3 and Section 3.2. 166 The COAM packet, defined in [I-D.ietf-sfc-multi-layer-oam], is 167 displayed in Figure 1. 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Version Number | Global Flags | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Message Type | Reply mode | Return Code | Return S.code | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Sender's Handle | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Sequence Number | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Type | Reserved | Length | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 ~ Value ~ 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 1: COAM Packet Header 186 The initiator of COAM Request MAY require the collected information 187 in the COAM Reply be sent in the integrity-protected mode using the a 188 Message Authentication Code (MAC) Context Header, defined in 189 [I-D.ietf-sfc-nsh-integrity]. If the NSH of the received SFC Echo 190 Reply includes the MAC Context Header, the authentication of the 191 packet MUST be verified before using any data. If the verification 192 fails, the receiver MUST stop processing the SFF Information Record 193 TLV and notify an operator. Specification of the notification 194 mechanism is outside the scope of this document. 196 3.2. SFF Information Record TLV 198 For COAM Request, the SFF MUST include the Information of SFs into 199 the SF Information Record TLV in the COAM Reply message. Every SFF 200 sends back a single COAM Reply Message, including information on all 201 the SFs attached to the SFF on the SFP as requested in the COAM 202 Request message. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |SFF Record TLV | Reserved | Length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Service Path Identifier (SPI) | Reserved | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | | 212 | SF Information Sub-TLV | 213 ~ ~ 214 | | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 2: SFF Information Record TLV 219 SFF Information Record TLV is a variable-length TLV that includes the 220 information of all SFFs mapped to the particular SFF instance for the 221 specified SFP. Figure 2 presents the format of an SFC Echo Request/ 222 Reply TLV, where fields are defined as the following: 224 Reserved - one-octet-long field. 226 Service Path Identifier (SPI): The identifier of SFP to which all 227 the SFs in this TLV belong. 229 SF Information Sub-TLV: The Sub-TLV is as defined in Figure 3. 231 3.3. SF Information Sub-TLV 233 Every SFF receiving COAM Request packet MUST include the SF 234 characteristic data into the COAM Reply packet. The data format of 235 an SF sub-TLV, included in a COAM Reply packet, is displayed in 236 Figure 3. 238 After the COAM Request message traverses the SFP, all the information 239 of the SFs on the SFP is collected from the TLVs included in COAM 240 Reply messages. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 |SF sub-TLV| Reserved | Length | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 |Service Index | SF Type | SF ID Type | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | SF Identifiers | 250 ~ ~ 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 3: Service Function information sub-TLV 256 SF sub-TLV Type: Two octets long field. It indicates that the TLV is 257 an SF TLV that contains the information of one SF. 259 Length: Two octets long field. The value of the field is the length 260 of the data following the Length field counted in octets. 262 Service Index: Indicates the SF's position on the SFP. 264 SF Type: Two octets long field. It is defined in 265 [I-D.ietf-bess-nsh-bgp-control-plane] and indicates the type of SF, 266 e.g., Firewall, Deep Packet Inspection, WAN optimization controller, 267 etc. 269 Reserved: For future use. MUST be zeroed on transmission and MUST be 270 ignored on receipt. 272 SF ID Type: One octet-long field with values defined as Section 5.4. 274 SF Identifier: An identifier of the SF. The length of the SF 275 Identifier depends on the type of the SF ID Type. For example, if 276 the SF Identifier is its IPv4 address, the SF Identifier should be 32 277 bits. SF ID Type and SF Identifier may be a list, indicating the 278 list of the SFs are which are included in a load balance group. 280 3.4. SF Information Sub-TLV Construction 282 Each SFF in the SFP MUST send one and only one COAM Reply 283 corresponding to the COAM Request. If only one SF is attached to the 284 SFF in such SFP, only one SF information sub-TLV is included in the 285 COAM Reply. If several SFs attached to the SFF in the SFP, SF 286 Information Sub-TLV MUST be constructed as described below in either 287 Section 3.4.1 and Section 3.4.2. 289 3.4.1. Multiple SFs as hops of SFP 291 Multiple SFs attached to the same SFF are the hops of the SFP. The 292 service indexes of these SFs are different. Service function types 293 of these SFs could be different or be the same. Information about 294 all SFs MAY be included in the COAM Reply message. Information about 295 each SF MUST be listed as separate SF Information Sub-TLVs in the 296 COAM Reply message. 298 An example of the COAM procedure for this case is shown in Figure 4. 299 The Service Function Path(SPI=x) is SF1->SF2->SF4->SF3. The SF1, SF2 300 and SF3 are attached to SFF1, and SF4 is attached to SFF2. The COAM 301 Request message is sent to the SFFs in the sequence of the 302 SFP(SFF1->SFF2->SFF1). Every SFF(SFF1, SFF2) replies with the 303 information of SFs belonging to the SFP. The SF information Sub-TLV 304 in Figure 3 contains information for each SF (SF1, SF2, SF3, and 305 SF4). 307 SF1 SF2 SF4 SF3 308 +------+------+ | | 309 COAM Req ......> SFF1 ......> SFF2 ......> SFF1 310 (SPI=x) . . . 311 <............ <.......... <........... 312 COAM Reply1(SF1,SF2) COAM Reply2(SF4) COAM Reply3(SF3) 314 Figure 4: Example 1 for COAM Reply with multiple SFs 316 3.4.2. Multiple SFs for load balance 318 Multiple SFs may be attached to the same SFF to balance the load; in 319 other words, that means that the particular traffic flow will 320 traverse only one of these SFs. These SFs have the same Service 321 Function Type and Service Index. For this case, the SF identifiers 322 and SF ID Type of all these SFs will be listed in the SF Identifiers 323 field and SF ID Type in a single SF information sub-TLV of COAM Reply 324 message. The number of these SFs can be calculated according to SF 325 ID Type and the value of the Length field of the sub-TLV. 327 An example of the COAM procedure for this case is shown in Figure 5. 328 The Service Function Path (SPI=x) is SF1a/SF1b->SF2a/SF2b. The 329 Service Functions SF1a and SF1b are attached to SFF1, which balances 330 the load among them. The Service Functions SF2a and SF2b are 331 attached to SFF2, which, in turn, balances its load between them. 332 The COAM Request message is sent to the SFFs in the sequence of the 333 SFP (i.e. SFF1->SFF2). Every SFF (SFF1, SFF2) replies with the 334 information of SFs belonging to the SFP. The SF information Sub-TLV 335 in Figure 3 contains information for all SFs at that hop. 337 /SF1a /SF2a 338 \SF1b \SF2b 339 | | 340 SFF1 SFF2 341 COAM Req .........> . .........> . 342 (SPI=x) . . 343 <............ <............... 344 COAM Reply1({SF1a,SF1b}) COAM Reply2({SF2a,SF2b}) 346 Figure 5: Example 2 for COAM Reply with multiple SFs 348 4. Security Considerations 350 Security considerations discussed in [RFC8300] and 351 [I-D.ietf-sfc-multi-layer-oam] apply to this document. 353 Also, since Service Function sub-TLV discloses information about the 354 SFP the spoofed COAM Request packet may be used to obtain network 355 information, it is RECOMMENDED that implementations provide a means 356 of checking the source addresses of COAM Request messages, specified 357 in SFC Source TLV [I-D.ietf-sfc-multi-layer-oam], against an access 358 list before accepting the message. 360 5. IANA Considerations 361 5.1. COAM Message Types 363 IANA is requested to assign values from its Message Types sub- 364 registry in SFC Echo Request/Echo Reply Message Types registry as 365 follows: 367 +=======+==============================+===============+ 368 | Value | Description | Reference | 369 +=======+==============================+===============+ 370 | TBA1 | SFP Consistency Echo Request | This document | 371 +-------+------------------------------+---------------+ 372 | TBA2 | SFP Consistency Echo Reply | This document | 373 +-------+------------------------------+---------------+ 375 Table 1: SFP Consistency Echo Request/Echo Reply 376 Message Types 378 5.2. SFF Information Record TLV Type 380 IANA is requested to assign a new type value from SFC OAM TLV Type 381 registry as follows: 383 +=======+=============================+===============+ 384 | Value | Description | Reference | 385 +=======+=============================+===============+ 386 | TBA3 | SFF Information Record Type | This document | 387 +-------+-----------------------------+---------------+ 389 Table 2: SFF-Information Record 391 5.3. SF Information Sub-TLV Type 393 IANA is requested to assign a new type value from SFC OAM TLV Type 394 registry as follows: 396 +=======+================+===============+ 397 | Value | Description | Reference | 398 +=======+================+===============+ 399 | TBA4 | SF Information | This document | 400 +-------+----------------+---------------+ 402 Table 3: SF-Information Sub-TLV Type 404 5.4. SF Identifier Types 406 IANA is requested to create in the registry SF Types the new sub- 407 registry SF Identifier Types. All code points in the range 1 through 408 191 in this registry shall be allocated according to the "IETF 409 Review" procedure as specified in [RFC8126] and assign values as 410 follows: 412 +============+=============+=========================+ 413 | Value | Description | Reference | 414 +============+=============+=========================+ 415 | 0 | Reserved | This document | 416 +------------+-------------+-------------------------+ 417 | TBA6 | IPv4 | This document | 418 +------------+-------------+-------------------------+ 419 | TBA7 | IPv6 | This document | 420 +------------+-------------+-------------------------+ 421 | TBA8 | MAC | This document | 422 +------------+-------------+-------------------------+ 423 | TBA8+1-191 | Unassigned | IETF Review | 424 +------------+-------------+-------------------------+ 425 | 192-251 | Unassigned | First Come First Served | 426 +------------+-------------+-------------------------+ 427 | 252-254 | Unassigned | Private Use | 428 +------------+-------------+-------------------------+ 429 | 255 | Reserved | This document | 430 +------------+-------------+-------------------------+ 432 Table 4: SF Identifier Type 434 6. Acknowledgements 436 The authors are thankful to John Drake for his review and the 437 reference to the work on BGP Control Plane for NSH SFC. The authors 438 express their appreciation to Joel M. Halpern for his suggestion 439 about the load balancing scenario. The authors also thank Dirk von 440 Hugo, for his useful comments. 442 7. References 444 7.1. Normative References 446 [I-D.ietf-sfc-multi-layer-oam] 447 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active 448 OAM for Service Function Chaining", Work in Progress, 449 Internet-Draft, draft-ietf-sfc-multi-layer-oam-09, 11 450 February 2021, . 453 [I-D.ietf-sfc-nsh-integrity] 454 Boucadair, M., Reddy, T., and D. Wing, "Integrity 455 Protection for the Network Service Header (NSH) and 456 Encryption of Sensitive Context Headers", Work in 457 Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-05, 458 23 March 2021, . 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, 463 DOI 10.17487/RFC2119, March 1997, 464 . 466 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 467 Writing an IANA Considerations Section in RFCs", BCP 26, 468 RFC 8126, DOI 10.17487/RFC8126, June 2017, 469 . 471 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 472 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 473 May 2017, . 475 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 476 "Network Service Header (NSH)", RFC 8300, 477 DOI 10.17487/RFC8300, January 2018, 478 . 480 7.2. Informational References 482 [I-D.ietf-bess-nsh-bgp-control-plane] 483 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 484 Jalil, "BGP Control Plane for the Network Service Header 485 in Service Function Chaining", Work in Progress, Internet- 486 Draft, draft-ietf-bess-nsh-bgp-control-plane-18, 21 August 487 2020, . 490 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 491 Chaining (SFC) Architecture", RFC 7665, 492 DOI 10.17487/RFC7665, October 2015, 493 . 495 [RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, 496 R., and A. Ghanwani, "Service Function Chaining (SFC) 497 Operations, Administration, and Maintenance (OAM) 498 Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020, 499 . 501 Authors' Addresses 503 Greg Mirsky 504 ZTE Corp. 506 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 508 Ting Ao 509 Individual contributor 510 No.889, BiBo Road 511 Shanghai 512 201203 513 China 515 Phone: +86 17721209283 516 Email: 18555817@qq.com 518 Zhonghua Chen 519 China Telecom 520 No.1835, South PuDong Road 521 Shanghai 522 201203 523 China 525 Phone: +86 18918588897 526 Email: 18918588897@189.cn 528 Kent Leung 529 Cisco System 530 170 West Tasman Drive 531 San Jose, CA 95134, 532 United States of America 534 Email: kleung@cisco.com 536 Gyan Mishra 537 Verizon Inc. 539 Email: gyan.s.mishra@verizon.com