idnits 2.17.1 draft-ao-sfc-oam-path-consistency-08.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 (June 3, 2020) is 1394 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-06 == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-14 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: December 5, 2020 Individual contributor 6 Z. Chen 7 China Telecom 8 K. Leung 9 Cisco System 10 June 3, 2020 12 SFC OAM for path consistency 13 draft-ao-sfc-oam-path-consistency-08 15 Abstract 17 Service Function Chain (SFC) defines an ordered set of service 18 functions (SFs) to be applied to packets and/or frames and/or flows 19 selected as a result of classification. SFC Operation, 20 Administration and Maintenance can monitor the continuity of the SFC, 21 i.e., that all elements of the SFC are reachable to each other in the 22 downstream direction. But SFC OAM must support verification that the 23 order of traversing these SFs corresponds to the state defined by the 24 SFC control plane or orchestrator, the metric referred in this 25 document as the path consistency of the SFC. This document defines a 26 new SFC active OAM method to support SFC consistency check, i.e. 27 verification that all elements of the given SFC are being traversed 28 in the expected order. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 5, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 4 71 3.3. SF Information Sub-TLV . . . . . . . . . . . . . . . . . 5 72 3.4. SF Information Sub-TLV Construction . . . . . . . . . . . 6 73 3.4.1. Multiple SFs as hops of SFP . . . . . . . . . . . . . 6 74 3.4.2. Multiple SFs for load balance . . . . . . . . . . . . 7 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 5.1. COAM Message Types . . . . . . . . . . . . . . . . . . . 8 78 5.2. SFF Information Record TLV Type . . . . . . . . . . . . . 8 79 5.3. SF Information Sub-TLV Type . . . . . . . . . . . . . . . 8 80 5.4. SF Identifier Types . . . . . . . . . . . . . . . . . . . 9 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 7.2. Informational References . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 for the ability to verify the 99 consistency of the particular SFP, using a mechanism of an active OAM 100 protocol, is noted in [I-D.ietf-sfc-oam-framework]. 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. Terminology 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 2.2. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 3. Consistency OAM: Theory of Operation 133 Consistency OAM (COAM) uses two functions: COAM Request and COAM 134 Reply. Every SFF that receives the COAM Request MUST perform the 135 following actions: 137 o Collect information of traversed by the COAM Request packet SFs 138 and send it to the ingress SFF as COAM Reply packet over IP 139 network [I-D.ietf-sfc-multi-layer-oam]; 141 o Forward the COAM Request to next downstream SFF if the one exists. 143 As a result, the ingress SFF collects information about all traversed 144 SFFs and SFs, information on the actual path the COAM packet has 145 traveled. That information used to verify the SFC's path 146 consistency. The mechanism for the SFP consistency verification is 147 outside the scope of this document. 149 3.1. COAM packet 151 Consistency OAM introduces two new types of messages to the SFC Echo 152 request/reply operation [I-D.ietf-sfc-multi-layer-oam] with the 153 following values detailed in Section 5.1: 155 o TBA1 - COAM Request 157 o TBA2 - COAM Reply 159 Upon receiving the COAM Request, the SFF MUST respond with the COAM 160 Reply. The SFF MUST include the SFs information, as described in 161 Section 3.3 and Section 3.2. 163 The COAM packet is displayed in Figure 1. 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Message Type | Reply mode | Return Code | Return S.code | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Sender's Handle | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Sequence Number | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Type | Length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 ~ Value ~ 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 1: COAM Packet Header 180 3.2. SFF Information Record TLV 182 For COAM Request, the SFF MUST include the Information of SFs into 183 the SF Information Record TLV in the COAM Reply message. Every SFF 184 sends back a single COAM Reply Message, including information on all 185 the SFs attached to the SFF on the SFP as requested in the COAM 186 Request message. 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | SFF Record TLV Type | Length | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Service Path Identifier(SPI) | Reserved | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | | 196 | SF Information Sub-TLV | 197 ~ ~ 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 2: SFF Information Record TLV 203 Service Path Identifier(SPI): The identifier of SFP to which all the 204 SFs in this TLV belong. 206 SF Information Sub-TLV: The Sub-TLV as defined in Figure 3. 208 3.3. SF Information Sub-TLV 210 Every SFF receiving COAM Request packet MUST include the SF 211 characteristic data into the COAM Reply packet. The data format of 212 an SF sub-TLV, included in a COAM Reply packet, is displayed in 213 Figure 3. 215 After the COAM Request message traverses the SFP, all the information 216 of the SFs on the SFP is collected from the TLVs included in COAM 217 Reply messages. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | SF sub-TLV Type | Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 |Service Index | SF Type | SF ID Type | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | SF Identifiers | 227 ~ ~ 228 | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 3: Service Function information sub-TLV 233 SF sub-TLV Type: Two octets long field. It indicates that the TLV is 234 an SF TLV which contains the information of one SF. 236 Length: Two octets long field. The value of the field is the length 237 of the data following the Length field counted in octets. 239 Service Index: Indicates the SF's position on the SFP. 241 SF Type: Two octets long field. It is defined in 242 [I-D.ietf-bess-nsh-bgp-control-plane] and indicates the type of SF, 243 e.g., Firewall, Deep Packet Inspection, WAN optimization controller, 244 etc. 246 Reserved: For future use. MUST be zeroed on transmission and MUST be 247 ignored on receipt. 249 SF ID Type: One octet-long field with values defined as Section 5.4. 251 SF Identifier: An identifier of the SF. The length of the SF 252 Identifier depends on the type of the SF ID Type. For example, if 253 the SF Identifier is its IPv4 address, the SF Identifier should be 32 254 bits. SF ID Type and SF Identifier may be a list, indicating the 255 list of the SFs are which are included in a load balance group. 257 3.4. SF Information Sub-TLV Construction 259 Each SFF in the SFP MUST send one and only one COAM Reply 260 corresponding to the COAM Request. If there is only one SF attached 261 to the SFF in such SFP, only one SF information sub-TLV is included 262 in the on COAM Reply. If there are several SFs attached to the SFF 263 in the SFP, SF Information Sub-TLV MUST be constructed as described 264 below in either Section 3.4.1 and Section 3.4.2. 266 3.4.1. Multiple SFs as hops of SFP 268 Multiple SFs attached to one SFF are the hops of the SFP, the service 269 indexes of these SFs are different. Service function types of these 270 SFs could be different or be the same. Information about all SFs MAY 271 be included in the COAM Reply message. Information about each SF 272 MUST be listed as separate SF Information Sub-TLVs in the COAM Reply 273 message. 275 An example of the COAM procedure for this case is shown in Figure 4. 276 The Service Function Path(SPI=x) is SF1->SF2->SF4->SF3. The SF1, SF2 277 and SF3 are attached to SFF1, and SF4 is attached to SFF2. The COAM 278 Request message is sent to the SFFs in the sequence of the 279 SFP(SFF1->SFF2->SFF1). Every SFF(SFF1, SFF2) replies with the 280 information of SFs belonging to the SFP. The SF information Sub-TLV 281 in Figure 3 contains information for each SF(SF1, SF2, SF3 and SF4). 283 SF1 SF2 SF4 SF3 284 +------+------+ | | 285 COAM Req ......> SFF1 ......> SFF2 ......> SFF1 286 (SPI=x) . . . 287 <............ <.......... <........... 288 COAM Reply1(SF1,SF2) COAM Reply2(SF4) COAM Reply3(SF3) 290 Figure 4: Example 1 for COAM Reply with multiple SFs 292 3.4.2. Multiple SFs for load balance 294 Multiple SFs may be attached to one SFF to balance the load; in other 295 words, that means that the particular traffic flow will traverse only 296 one of these SFs. These SFs have the same Service Function Type and 297 Service Index. For this case, the SF identifiers and SF ID Type of 298 all these SFs will be listed in the SF Identifiers field and SF ID 299 Type in a single SF information sub-TLV of COAM Reply message. The 300 number of these SFs can be calculated according to SF ID Type and the 301 value of the Length field of the sub-TLV. 303 An example of the COAM procedure for this case is shown in Figure 4. 304 The Service Function Path (SPI=x) is SF1a/SF1b->SF2a/SF2b. The 305 Service Functions SF1a and SF1b are attached to SFF1, which balances 306 the load among them The Service Functions SF2a and SF2b are attached 307 to SFF2, which also balances its load between them. The COAM Request 308 message is sent to the SFFs in the sequence of the SFP (i.e. 309 SFF1->SFF2). Every SFF (SFF1, SFF2) replies with the information of 310 SFs belonging to the SFP. The SF information Sub-TLV in Figure 3 311 contains information for all SFs at that hop. 313 /SF1a /SF2a 314 \SF1b \SF2b 315 | | 316 SFF1 SFF2 317 COAM Req .........> . .........> . 318 (SPI=x) . . 319 <............ <............... 320 COAM Reply1({SF1a,SF1b}) COAM Reply2({SF2a,SF2b}) 322 Figure 5: Example 2 for COAM Reply with multiple SFs 324 4. Security Considerations 326 Security considerations discussed in [RFC8300] and 327 [I-D.ietf-sfc-multi-layer-oam] apply to this document. 329 Also, since Service Function sub-TLV discloses information about the 330 SFP the spoofed COAM Request packet may be used to obtain network 331 information, it is RECOMMENDED that implementations provide a means 332 of checking the source addresses of COAM Request messages, specified 333 in SFC Source TLV [I-D.ietf-sfc-multi-layer-oam], against an access 334 list before accepting the message. 336 5. IANA Considerations 338 5.1. COAM Message Types 340 IANA is requested to assign values from its Message Types sub- 341 registry in SFC Echo Request/Echo Reply Message Types registry as 342 follows: 344 +-------+------------------------------+---------------+ 345 | Value | Description | Reference | 346 +-------+------------------------------+---------------+ 347 | TBA1 | SFP Consistency Echo Request | This document | 348 | TBA2 | SFP Consistency Echo Reply | This document | 349 +-------+------------------------------+---------------+ 351 Table 1: SFP Consistency Echo Request/Echo Reply Message Types 353 5.2. SFF Information Record TLV Type 355 IANA is requested to assign new type value from SFC OAM TLV Type 356 registry as follows: 358 +-------+-----------------------------+---------------+ 359 | Value | Description | Reference | 360 +-------+-----------------------------+---------------+ 361 | TBA3 | SFF Information Record Type | This document | 362 +-------+-----------------------------+---------------+ 364 Table 2: SFF-Information Record 366 5.3. SF Information Sub-TLV Type 368 IANA is requested to assign new type value from SFC OAM TLV Type 369 registry as follows: 371 +-------+----------------+---------------+ 372 | Value | Description | Reference | 373 +-------+----------------+---------------+ 374 | TBA4 | SF Information | This document | 375 +-------+----------------+---------------+ 377 Table 3: SF-Information Sub-TLV Type 379 5.4. SF Identifier Types 381 IANA is requested to create in the registry SF Types the new sub- 382 registry SF Identifier Types. All code points in the range 1 through 383 191 in this registry shall be allocated according to the "IETF 384 Review" procedure as specified in [RFC8126] and assign values as 385 follows: 387 +------------+-------------+-------------------------+ 388 | Value | Description | Reference | 389 +------------+-------------+-------------------------+ 390 | 0 | Reserved | This document | 391 | TBA6 | IPv4 | This document | 392 | TBA7 | IPv6 | This document | 393 | TBA8 | MAC | This document | 394 | TBA8+1-191 | Unassigned | IETF Review | 395 | 192-251 | Unassigned | First Come First Served | 396 | 252-254 | Unassigned | Private Use | 397 | 255 | Reserved | This document | 398 +------------+-------------+-------------------------+ 400 Table 4: SF Identifier Type 402 6. Acknowledgements 404 The authors are thankful to John Drake for his review and the 405 reference to the work on BGP Control Plane for NSH SFC. The authors 406 express their appreciation to Joel M. Halpern for his suggestion 407 about the load balance scenario. The authors also thank Dirk von 408 Hugo for his useful comments. 410 7. References 412 7.1. Normative References 414 [I-D.ietf-sfc-multi-layer-oam] 415 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active 416 OAM for Service Function Chains in Networks", draft-ietf- 417 sfc-multi-layer-oam-06 (work in progress), June 2020. 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, 421 DOI 10.17487/RFC2119, March 1997, 422 . 424 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 425 Writing an IANA Considerations Section in RFCs", BCP 26, 426 RFC 8126, DOI 10.17487/RFC8126, June 2017, 427 . 429 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 430 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 431 May 2017, . 433 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 434 "Network Service Header (NSH)", RFC 8300, 435 DOI 10.17487/RFC8300, January 2018, 436 . 438 7.2. Informational References 440 [I-D.ietf-bess-nsh-bgp-control-plane] 441 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 442 Jalil, "BGP Control Plane for the Network Service Header 443 in Service Function Chaining", draft-ietf-bess-nsh-bgp- 444 control-plane-14 (work in progress), June 2020. 446 [I-D.ietf-sfc-oam-framework] 447 Aldrin, S., Pignataro, C., Nainar, N., Krishnan, R., and 448 A. Ghanwani, "Service Function Chaining (SFC) Operations, 449 Administration and Maintenance (OAM) Framework", draft- 450 ietf-sfc-oam-framework-15 (work in progress), May 2020. 452 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 453 Chaining (SFC) Architecture", RFC 7665, 454 DOI 10.17487/RFC7665, October 2015, 455 . 457 Authors' Addresses 459 Greg Mirsky 460 ZTE Corp. 461 1900 McCarthy Blvd. #205 462 Milpitas, CA 95035 463 USA 465 Email: gregimirsky@gmail.com 466 Ting Ao 467 Individual contributor 468 No.889, BiBo Road 469 Shanghai 201203 470 China 472 Phone: +86 17721209283 473 Email: 18555817@qq.com 475 Zhonghua Chen 476 China Telecom 477 No.1835, South PuDong Road 478 Shanghai 201203 479 China 481 Phone: +86 18918588897 482 Email: 18918588897@189.cn 484 Kent Leung 485 Cisco System 486 170 West Tasman Drive 487 San Jose, CA 95134 488 USA 490 Email: kleung@cisco.com