idnits 2.17.1 draft-ao-sfc-oam-path-consistency-10.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 (January 19, 2021) is 1193 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-07 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-nsh-integrity-02 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: July 23, 2021 Individual contributor 6 Z. Chen 7 China Telecom 8 K. Leung 9 Cisco System 10 G. Mishra 11 Verizon Inc. 12 January 19, 2021 14 SFC OAM for path consistency 15 draft-ao-sfc-oam-path-consistency-10 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 July 23, 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 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Conventions used in this document . . . . . . . . . . . . . . 3 67 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 3. Consistency OAM: Theory of Operation . . . . . . . . . . . . 3 70 3.1. COAM packet . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. SFF Information Record TLV . . . . . . . . . . . . . . . 5 72 3.3. SF Information Sub-TLV . . . . . . . . . . . . . . . . . 5 73 3.4. SF Information Sub-TLV Construction . . . . . . . . . . . 6 74 3.4.1. Multiple SFs as hops of SFP . . . . . . . . . . . . . 7 75 3.4.2. Multiple SFs for load balance . . . . . . . . . . . . 7 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 5.1. COAM Message Types . . . . . . . . . . . . . . . . . . . 8 79 5.2. SFF Information Record TLV Type . . . . . . . . . . . . . 9 80 5.3. SF Information Sub-TLV Type . . . . . . . . . . . . . . . 9 81 5.4. SF Identifier Types . . . . . . . . . . . . . . . . . . . 9 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 7.2. Informational References . . . . . . . . . . . . . . . . 10 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 Service Function Chain (SFC) is a chain with a series of ordered 91 Service Functions (SFs). Service Function Path (SFP) is a path of a 92 SFC. SFC is described in detail in the SFC architecture document 93 [RFC7665]. The SFs in the SFC are ordered, i.e., only when an SF 94 processes traffic, then it can be processed by the next SF. Changes 95 in the order are very likely to cause errors. That's why an operator 96 needs to ensure that the order of traversing the SFs is as defined by 97 the control plane or the orchestrator. This document refers to the 98 correlation between the state of the control plane and the SFP itself 99 as the SFP consistency. The need to verify the consistency of the 100 particular SFP, using a mechanism of an active OAM protocol, is noted 101 in [RFC8924]. 103 This document defines the method to check the path consistency of the 104 SFP. It is an extension of the SFC Echo-request/Echo-reply specified 105 in the [I-D.ietf-sfc-multi-layer-oam]. 107 2. Conventions used in this document 109 2.1. Acronyms 111 SFC: Service Function Chain. An ordered set of some abstract SFs. 113 SFF: Service Function Forwarder 115 SF: Service Function 117 OAM: Operation, Administration and Maintenance 119 SFP: Service Function Path 121 COAM: Consistency OAM, OAM that can be used to check the consistency 122 of the Service Function Path. 124 MAC: Message Authentication Code 126 2.2. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 3. Consistency OAM: Theory of Operation 136 Consistency OAM (COAM) uses two functions: COAM Request and COAM 137 Reply. Every SFF that receives the COAM Request MUST perform the 138 following actions: 140 o Collect information of the traversed by the COAM Request packet 141 SFs and send it to the ingress SFF as COAM Reply packet over IP 142 network [I-D.ietf-sfc-multi-layer-oam]; 144 o Forward the COAM Request to the next downstream SFF if the one 145 exists. 147 As a result, the ingress SFF collects information about all traversed 148 SFFs and SFs, information on the actual path the COAM packet has 149 traveled. That information is used to verify the SFC's path 150 consistency. The mechanism for the SFP consistency verification is 151 outside the scope of this document. 153 3.1. COAM packet 155 Consistency OAM introduces two new types of messages to the SFC Echo 156 Request/Reply operation defined in [I-D.ietf-sfc-multi-layer-oam] 157 with the following values detailed in Section 5.1: 159 o TBA1 - COAM Request 161 o TBA2 - COAM Reply 163 Upon receiving the COAM Request, the SFF MUST respond with the COAM 164 Reply. The SFF MUST include the SFs information, as described in 165 Section 3.3 and Section 3.2. 167 The COAM packet, defined in [I-D.ietf-sfc-multi-layer-oam], is 168 displayed in Figure 1. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Version Number | Global Flags | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Message Type | Reply mode | Return Code | Return S.code | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Sender's Handle | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Sequence Number | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Type | Reserved | Length | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 ~ Value ~ 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Figure 1: COAM Packet Header 188 The initiator of COAM Request MAY require the collected information 189 in the COAM Reply be sent in the integrity-protected mode using the a 190 Message Authentication Code (MAC) Context Header, defined in 191 [I-D.ietf-sfc-nsh-integrity]. If the NSH of the received SFC Echo 192 Reply includes the MAC Context Header, the authentication of the 193 packet MUST be verified before using any data. If the verification 194 fails, the receiver MUST stop processing the SFF Information Record 195 TLV and notify an operator. Specification of the notification 196 mechanism is outside the scope of this document. 198 3.2. SFF Information Record TLV 200 For COAM Request, the SFF MUST include the Information of SFs into 201 the SF Information Record TLV in the COAM Reply message. Every SFF 202 sends back a single COAM Reply Message, including information on all 203 the SFs attached to the SFF on the SFP as requested in the COAM 204 Request message. 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 |SFF Record TLV | Reserved | Length | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Service Path Identifier (SPI) | Reserved | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | | 214 | SF Information Sub-TLV | 215 ~ ~ 216 | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 2: SFF Information Record TLV 221 SFF Information Record TLV is a variable-length TLV that includes the 222 information of all SFFs mapped to the particular SFF instance for the 223 specified SFP. Figure 2 presents the format of an SFC Echo Request/ 224 Reply TLV, where fields are defined as the following: 226 Reserved - one-octet-long field. 228 Service Path Identifier (SPI): The identifier of SFP to which all 229 the SFs in this TLV belong. 231 SF Information Sub-TLV: The Sub-TLV is as defined in Figure 3. 233 3.3. SF Information Sub-TLV 235 Every SFF receiving COAM Request packet MUST include the SF 236 characteristic data into the COAM Reply packet. The data format of 237 an SF sub-TLV, included in a COAM Reply packet, is displayed in 238 Figure 3. 240 After the COAM Request message traverses the SFP, all the information 241 of the SFs on the SFP is collected from the TLVs included in COAM 242 Reply messages. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 |SF sub-TLV| Reserved | Length | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 |Service Index | SF Type | SF ID Type | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | SF Identifiers | 252 ~ ~ 253 | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 3: Service Function information sub-TLV 258 SF sub-TLV Type: Two octets long field. It indicates that the TLV is 259 an SF TLV that contains the information of one SF. 261 Length: Two octets long field. The value of the field is the length 262 of the data following the Length field counted in octets. 264 Service Index: Indicates the SF's position on the SFP. 266 SF Type: Two octets long field. It is defined in 267 [I-D.ietf-bess-nsh-bgp-control-plane] and indicates the type of SF, 268 e.g., Firewall, Deep Packet Inspection, WAN optimization controller, 269 etc. 271 Reserved: For future use. MUST be zeroed on transmission and MUST be 272 ignored on receipt. 274 SF ID Type: One octet-long field with values defined as Section 5.4. 276 SF Identifier: An identifier of the SF. The length of the SF 277 Identifier depends on the type of the SF ID Type. For example, if 278 the SF Identifier is its IPv4 address, the SF Identifier should be 32 279 bits. SF ID Type and SF Identifier may be a list, indicating the 280 list of the SFs are which are included in a load balance group. 282 3.4. SF Information Sub-TLV Construction 284 Each SFF in the SFP MUST send one and only one COAM Reply 285 corresponding to the COAM Request. If only one SF is attached to the 286 SFF in such SFP, only one SF information sub-TLV is included in the 287 COAM Reply. If several SFs attached to the SFF in the SFP, SF 288 Information Sub-TLV MUST be constructed as described below in either 289 Section 3.4.1 and Section 3.4.2. 291 3.4.1. Multiple SFs as hops of SFP 293 Multiple SFs attached to the same SFF are the hops of the SFP. The 294 service indexes of these SFs are different. Service function types 295 of these SFs could be different or be the same. Information about 296 all SFs MAY be included in the COAM Reply message. Information about 297 each SF MUST be listed as separate SF Information Sub-TLVs in the 298 COAM Reply message. 300 An example of the COAM procedure for this case is shown in Figure 4. 301 The Service Function Path(SPI=x) is SF1->SF2->SF4->SF3. The SF1, SF2 302 and SF3 are attached to SFF1, and SF4 is attached to SFF2. The COAM 303 Request message is sent to the SFFs in the sequence of the 304 SFP(SFF1->SFF2->SFF1). Every SFF(SFF1, SFF2) replies with the 305 information of SFs belonging to the SFP. The SF information Sub-TLV 306 in Figure 3 contains information for each SF (SF1, SF2, SF3, and 307 SF4). 309 SF1 SF2 SF4 SF3 310 +------+------+ | | 311 COAM Req ......> SFF1 ......> SFF2 ......> SFF1 312 (SPI=x) . . . 313 <............ <.......... <........... 314 COAM Reply1(SF1,SF2) COAM Reply2(SF4) COAM Reply3(SF3) 316 Figure 4: Example 1 for COAM Reply with multiple SFs 318 3.4.2. Multiple SFs for load balance 320 Multiple SFs may be attached to the same SFF to balance the load; in 321 other words, that means that the particular traffic flow will 322 traverse only one of these SFs. These SFs have the same Service 323 Function Type and Service Index. For this case, the SF identifiers 324 and SF ID Type of all these SFs will be listed in the SF Identifiers 325 field and SF ID Type in a single SF information sub-TLV of COAM Reply 326 message. The number of these SFs can be calculated according to SF 327 ID Type and the value of the Length field of the sub-TLV. 329 An example of the COAM procedure for this case is shown in Figure 5. 330 The Service Function Path (SPI=x) is SF1a/SF1b->SF2a/SF2b. The 331 Service Functions SF1a and SF1b are attached to SFF1, which balances 332 the load among them. The Service Functions SF2a and SF2b are 333 attached to SFF2, which, in turn, balances its load between them. 335 The COAM Request message is sent to the SFFs in the sequence of the 336 SFP (i.e. SFF1->SFF2). Every SFF (SFF1, SFF2) replies with the 337 information of SFs belonging to the SFP. The SF information Sub-TLV 338 in Figure 3 contains information for all SFs at that hop. 340 /SF1a /SF2a 341 \SF1b \SF2b 342 | | 343 SFF1 SFF2 344 COAM Req .........> . .........> . 345 (SPI=x) . . 346 <............ <............... 347 COAM Reply1({SF1a,SF1b}) COAM Reply2({SF2a,SF2b}) 349 Figure 5: Example 2 for COAM Reply with multiple SFs 351 4. Security Considerations 353 Security considerations discussed in [RFC8300] and 354 [I-D.ietf-sfc-multi-layer-oam] apply to this document. 356 Also, since Service Function sub-TLV discloses information about the 357 SFP the spoofed COAM Request packet may be used to obtain network 358 information, it is RECOMMENDED that implementations provide a means 359 of checking the source addresses of COAM Request messages, specified 360 in SFC Source TLV [I-D.ietf-sfc-multi-layer-oam], against an access 361 list before accepting the message. 363 5. IANA Considerations 365 5.1. COAM Message Types 367 IANA is requested to assign values from its Message Types sub- 368 registry in SFC Echo Request/Echo Reply Message Types registry as 369 follows: 371 +-------+------------------------------+---------------+ 372 | Value | Description | Reference | 373 +-------+------------------------------+---------------+ 374 | TBA1 | SFP Consistency Echo Request | This document | 375 | TBA2 | SFP Consistency Echo Reply | This document | 376 +-------+------------------------------+---------------+ 378 Table 1: SFP Consistency Echo Request/Echo Reply Message Types 380 5.2. SFF Information Record TLV Type 382 IANA is requested to assign a new type value from SFC OAM TLV Type 383 registry as follows: 385 +-------+-----------------------------+---------------+ 386 | Value | Description | Reference | 387 +-------+-----------------------------+---------------+ 388 | TBA3 | SFF Information Record Type | This document | 389 +-------+-----------------------------+---------------+ 391 Table 2: SFF-Information Record 393 5.3. SF Information Sub-TLV Type 395 IANA is requested to assign a new type value from SFC OAM TLV Type 396 registry as follows: 398 +-------+----------------+---------------+ 399 | Value | Description | Reference | 400 +-------+----------------+---------------+ 401 | TBA4 | SF Information | This document | 402 +-------+----------------+---------------+ 404 Table 3: SF-Information Sub-TLV Type 406 5.4. SF Identifier Types 408 IANA is requested to create in the registry SF Types the new sub- 409 registry SF Identifier Types. All code points in the range 1 through 410 191 in this registry shall be allocated according to the "IETF 411 Review" procedure as specified in [RFC8126] and assign values as 412 follows: 414 +------------+-------------+-------------------------+ 415 | Value | Description | Reference | 416 +------------+-------------+-------------------------+ 417 | 0 | Reserved | This document | 418 | TBA6 | IPv4 | This document | 419 | TBA7 | IPv6 | This document | 420 | TBA8 | MAC | This document | 421 | TBA8+1-191 | Unassigned | IETF Review | 422 | 192-251 | Unassigned | First Come First Served | 423 | 252-254 | Unassigned | Private Use | 424 | 255 | Reserved | This document | 425 +------------+-------------+-------------------------+ 427 Table 4: SF Identifier Type 429 6. Acknowledgements 431 The authors are thankful to John Drake for his review and the 432 reference to the work on BGP Control Plane for NSH SFC. The authors 433 express their appreciation to Joel M. Halpern for his suggestion 434 about the load balancing scenario. The authors also thank Dirk von 435 Hugo, for his useful comments. 437 7. References 439 7.1. Normative References 441 [I-D.ietf-sfc-multi-layer-oam] 442 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active 443 OAM for Service Function Chains in Networks", draft-ietf- 444 sfc-multi-layer-oam-07 (work in progress), December 2020. 446 [I-D.ietf-sfc-nsh-integrity] 447 Boucadair, M., Reddy.K, T., and D. Wing, "Integrity 448 Protection for the Network Service Header (NSH) and 449 Encryption of Sensitive Context Headers", draft-ietf-sfc- 450 nsh-integrity-02 (work in progress), January 2021. 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, 454 DOI 10.17487/RFC2119, March 1997, 455 . 457 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 458 Writing an IANA Considerations Section in RFCs", BCP 26, 459 RFC 8126, DOI 10.17487/RFC8126, June 2017, 460 . 462 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 463 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 464 May 2017, . 466 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 467 "Network Service Header (NSH)", RFC 8300, 468 DOI 10.17487/RFC8300, January 2018, 469 . 471 7.2. Informational References 473 [I-D.ietf-bess-nsh-bgp-control-plane] 474 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 475 Jalil, "BGP Control Plane for the Network Service Header 476 in Service Function Chaining", draft-ietf-bess-nsh-bgp- 477 control-plane-18 (work in progress), August 2020. 479 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 480 Chaining (SFC) Architecture", RFC 7665, 481 DOI 10.17487/RFC7665, October 2015, 482 . 484 [RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, 485 R., and A. Ghanwani, "Service Function Chaining (SFC) 486 Operations, Administration, and Maintenance (OAM) 487 Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020, 488 . 490 Authors' Addresses 492 Greg Mirsky 493 ZTE Corp. 494 1900 McCarthy Blvd. #205 495 Milpitas, CA 95035 496 USA 498 Email: gregimirsky@gmail.com 500 Ting Ao 501 Individual contributor 502 No.889, BiBo Road 503 Shanghai 201203 504 China 506 Phone: +86 17721209283 507 Email: 18555817@qq.com 509 Zhonghua Chen 510 China Telecom 511 No.1835, South PuDong Road 512 Shanghai 201203 513 China 515 Phone: +86 18918588897 516 Email: 18918588897@189.cn 517 Kent Leung 518 Cisco System 519 170 West Tasman Drive 520 San Jose, CA 95134 521 USA 523 Email: kleung@cisco.com 525 Gyan Mishra 526 Verizon Inc. 528 Email: gyan.s.mishra@verizon.com