idnits 2.17.1 draft-ao-sfc-oam-path-consistency-06.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 4, 2019) is 1787 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) == Unused Reference: 'I-D.ietf-sfc-nsh-tlv' is defined on line 423, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-11 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-multi-layer-oam-03 == Outdated reference: A later version (-15) exists of draft-ietf-sfc-nsh-tlv-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG T. Ao 3 Internet-Draft Individual 4 Intended status: Standards Track G. Mirsky 5 Expires: December 6, 2019 ZTE Corp. 6 Z. Chen 7 China Telecom 8 K. Leung 9 Cisco System 10 June 4, 2019 12 SFC OAM for path consistency 13 draft-ao-sfc-oam-path-consistency-06 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 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 6, 2019. 47 Copyright Notice 49 Copyright (c) 2019 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 and only when one SF 93 processes traffic then it can be processed by the next SF. Changes 94 in the order may cause errors. Sometimes, an SF uses the metadata 95 from its upstream SF process. That's why it's very important for the 96 operator to make sure that the order of traversing the SFs is exactly 97 as defined by the control plane or the orchestrator. This document 98 refers to the correspondence between the state of the control plane 99 and the SFP itself as the SFP consistency. 101 This document defines the method to check the path consistency of the 102 SFP. It is an extension of the SFC Echo-request/Echo-reply specified 103 in the [I-D.ietf-sfc-multi-layer-oam]. 105 2. Conventions used in this document 107 2.1. Terminology 109 SFC(Service Function Chain): An ordered set of some abstract SFs. 111 SFF: Service Function Forwarder 113 SF: Service Function 115 OAM: Operation, Administration and Maintenance 117 SFP: Service Function Path 119 COAM(Consistency OAM): OAM that can be used to check the consistency 120 of the Service Function Path. 122 2.2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 3. Consistency OAM: Theory of Operation 132 Consistency OAM(COAM) uses two functions: COAM Request and COAM 133 Reply. Every SFF that receives the COAM Request MUST perform the 134 following actions: 136 o Collect information of traversed by the COAM Request packet SFs 137 and send it to the ingress SFF as COAM Reply packet over IP 138 network [I-D.ietf-sfc-multi-layer-oam]; 140 o Forward the COAM Request to next downstream SFF if the one exists. 142 As result, the ingress SFF collects information about all traversed 143 SFFs and SFs, information of the actual path the COAM packet has 144 traveled, so that we can verify the path consistency of the SFC. The 145 mechanism for the SFP consistency verification is outside the scope 146 of this document. 148 3.1. COAM packet 150 Consistency OAM introduces two new types of messages to the SFC Echo 151 request/reply operation [I-D.ietf-sfc-multi-layer-oam] with the 152 following values detailed in Section 5.1: 154 o TBA1 - COAM Request 156 o TBA2 - COAM Reply 158 Upon receiving the COAM Request, the SFF MUST respond with the COAM 159 Reply. The SFF MUST include the SFs information, as described in 160 Section 3.3 and Section 3.2. 162 The COAM packet is displayed in Figure 1. 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Message Type | Reply mode | Return Code | Return S.code | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Sender's Handle | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Sequence Number | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type | Length | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 ~ Value ~ 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 1: COAM Packet Header 179 3.2. SFF Information Record TLV 181 For COAM Request, the SFF MUST include the Information of SFs into 182 the SF Information Record TLV in the COAM Reply message. Every SFF 183 send back one COAM Reply Message with all the SFs that are attaching 184 to the SFF along the SFP indicated by the COAM Request. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | SFF Record TLV Type | Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Service Path Identifier(SPI) | Reserved | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | 194 | SF Information Sub-TLV | 195 ~ ~ 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 2: SFF Information Record TLV 201 Service Path Identifier(SPI): The identifier of SFP to which all the 202 SFs in this TLV belong. 204 SF Information Sub-TLV: The Sub-TLV as defined in Figure 3. 206 3.3. SF Information Sub-TLV 208 Every SFF receiving COAM Request packet MUST include the SF 209 characteristic data into the COAM Reply packet. The data format of 210 each SF includes in a COAM Reply packet as SF Information sub-TLV 211 that is displayed in Figure 3. 213 After the COAM traversed the SFP, all the information of the SFs on 214 the SFP are collected from the TLVs with COAM Reply. 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | SF sub-TLV Type | Length | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 |Service Index | SF Type | SF ID Type | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | SF Identifiers | 224 ~ ~ 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Figure 3: Service Function information sub-TLV 230 SF sub-TLV Type: Two octets long field. It indicates that the TLV is 231 a SF TLV which contains the information of one SF. 233 Length: Two octets long field. The value of the field is the length 234 of the data following the Length field counted in octets. 236 Service Index: Indicates the SF's position on the SFP. 238 SF Type: Two octets long field. It is defined in 239 [I-D.ietf-bess-nsh-bgp-control-plane] and indicates the type of SF, 240 e.g., Firewall, Deep Packet Inspection, WAN optimization controller, 241 etc. 243 Reserved: For future use. MUST be zeroed on transmission and MUST be 244 ignored on receipt. 246 SF ID Type: One octet long field with values defined as Section 5.4. 248 SF Identifier: An identifier of the SF. The length of the SF 249 Identifier depends on the type of the SF ID Type. For example, if 250 the SF Identifier is its IPv4 address, the SF Identifier should be 32 251 bits. SF ID Type and SF Identifier may be a list, indicating the 252 list of the SFs are which are included in a load balance group. 254 3.4. SF Information Sub-TLV Construction 256 Each SFF in the SFP MUST send one and only one COAM Reply 257 corresponding to the COAM Request. If there is only one SF attached 258 to the SFF in such SFP, only one SF information sub-TLV is included 259 in the on COAM Reply. If there are several SFs attached to the SFF 260 in the SFP, SF Information Sub-TLV MUST be constructed as described 261 below in either Section 3.4.1 and Section 3.4.2. 263 3.4.1. Multiple SFs as hops of SFP 265 Multiple SFs attached to one SFF are the hops of the SFP, the service 266 indexes of these SFs are different. Service function types of these 267 SFs could be different or be the same. Information about all SFs MAY 268 be included in the COAM Reply message. Information about each SF 269 MUST be listed as separate SF Information Sub-TLVs in the COAM Reply 270 message. 272 An example of the COAM procedure for this case is shown in Figure 4. 273 The Service Function Path(SPI=x) is SF1->SF2->SF4->SF3. The SF1,SF2 274 and SF3 are attached to SFF1, and SF4 is attached to SFF2. The COAM 275 Request message is sent to the SFFs in the sequence of the 276 SFP(SFF1->SFF2->SFF1). Every SFF(SFF1,SFF2) replies with the 277 information of SFs belonging to the SFP. The SF information Sub-TLV 278 in Figure 3 contains information for each SF(SF1, SF2,SF3 and SF4). 280 SF1 SF2 SF4 SF3 281 +------+------+ | | 282 COAM Req ......> SFF1 ......> SFF2 ......> SFF1 283 (SPI=x) . . . 284 <............ <.......... <........... 285 COAM Reply1(SF1,SF2) COAM Reply2(SF4) COAM Reply3(SF3) 287 Figure 4: Example 1 for COAM Reply with multiple SFs 289 3.4.2. Multiple SFs for load balance 291 Multiple SFs may be attached to one SFF to balance the load, in other 292 words, that means that the particular traffic flow will transmit only 293 one of these SFs . These SFs have the same Service Function Type and 294 Service Index. For this case, the SF identifiers and SF ID Type of 295 all these SFs will be listed in the SF Identifiers field and SF ID 296 Type in a single SF information sub-TLV of COAM Reply message. The 297 number of these SFs can be calculated according to SF ID Type and the 298 value of Length field of the sub-TLV. 300 An example of the COAM procedure for this case is shown in Figure 4. 301 The Service Function Path(SPI=x) is SF1a/SF1b->SF2a/SF2b. The 302 Service Functions SF1a and SF1b are attached to SFF1 which are load 303 balance for each other, and the Service Functions SF2a and SF2b are 304 attached to SFF2 which are load balance for each other as well. The 305 COAM Request message is sent to the SFFs in the sequence of the SFP 306 (i.e. SFF1->SFF2). Every SFF(SFF1,SFF2) replies with the 307 information of SFs belonging to the SFP. The SF information Sub-TLV 308 in Figure 3 contains information for all SFs at that hop. 310 /SF1a /SF2a 311 \SF1b \SF2b 312 | | 313 SFF1 SFF2 314 COAM Req .........> . .........> . 315 (SPI=x) . . 316 <............ <............... 317 COAM Reply1({SF1a,SF1b}) COAM Reply2({SF2a,SF2b}) 319 Figure 5: Example 2 for COAM Reply with multiple SFs 321 4. Security Considerations 323 Security considerations discussed in [RFC8300] and 324 [I-D.ietf-sfc-multi-layer-oam] apply to this document. 326 Also, since Service Function sub-TLV discloses information about the 327 SFP the spoofed COAM Request packet may be used to obtain network 328 information, it is RECOMMENDED that implementations provide a means 329 of checking the source addresses of COAM Request messages, specified 330 in SFC Source TLV [I-D.ietf-sfc-multi-layer-oam], against an access 331 list before accepting the message. 333 5. IANA Considerations 335 5.1. COAM Message Types 337 IANA is requested to assign values from its Message Types sub- 338 registry in SFC Echo Request/Echo Reply Message Types registry as 339 follows: 341 +-------+------------------------------+---------------+ 342 | Value | Description | Reference | 343 +-------+------------------------------+---------------+ 344 | TBA1 | SFP Consistency Echo Request | This document | 345 | TBA2 | SFP Consistency Echo Reply | This document | 346 +-------+------------------------------+---------------+ 348 Table 1: SFP Consistency Echo Request/Echo Reply Message Types 350 5.2. SFF Information Record TLV Type 352 IANA is requested to assign new type value from SFC OAM TLV Type 353 registry as follows: 355 +-------+-----------------------------+---------------+ 356 | Value | Description | Reference | 357 +-------+-----------------------------+---------------+ 358 | TBA3 | SFF Information Record Type | This document | 359 +-------+-----------------------------+---------------+ 361 Table 2: SFF-Information Record 363 5.3. SF Information Sub-TLV Type 365 IANA is requested to assign new type value from SFC OAM TLV Type 366 registry as follows: 368 +-------+----------------+---------------+ 369 | Value | Description | Reference | 370 +-------+----------------+---------------+ 371 | TBA4 | SF Information | This document | 372 +-------+----------------+---------------+ 374 Table 3: SF-Information Sub-TLV Type 376 5.4. SF Identifier Types 378 IANA is requested to create in the registry SF Types the new sub- 379 registry SF Identifier Types. All code points in the range 1 through 380 191 in this registry shall be allocated according to the "IETF 381 Review" procedure as specified in [RFC8126] and assign values as 382 follows: 384 +------------+-------------+-------------------------+ 385 | Value | Description | Reference | 386 +------------+-------------+-------------------------+ 387 | 0 | Reserved | This document | 388 | TBA6 | IPv4 | This document | 389 | TBA7 | IPv6 | This document | 390 | TBA8 | MAC | This document | 391 | TBA8+1-191 | Unassigned | IETF Review | 392 | 192-251 | Unassigned | First Come First Served | 393 | 252-254 | Unassigned | Private Use | 394 | 255 | Reserved | This document | 395 +------------+-------------+-------------------------+ 397 Table 4: SF Identifier Type 399 6. Acknowledgements 401 Thanks to John Drake for his review and the reference to the work on 402 BGP Control Plane for NSH SFC. 404 Thanks to Joel M. Halpern for his suggestion about the load balance 405 scenario. 407 Thansk to Dirk von Hugo for his useful comments. 409 7. References 411 7.1. Normative References 413 [I-D.ietf-bess-nsh-bgp-control-plane] 414 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 415 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 416 nsh-bgp-control-plane-11 (work in progress), May 2019. 418 [I-D.ietf-sfc-multi-layer-oam] 419 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active 420 OAM for Service Function Chains in Networks", draft-ietf- 421 sfc-multi-layer-oam-03 (work in progress), May 2019. 423 [I-D.ietf-sfc-nsh-tlv] 424 Quinn, P., Elzur, U., and S. Majee, "Network Service 425 Header TLVs", draft-ietf-sfc-nsh-tlv-00 (work in 426 progress), January 2018. 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, 430 DOI 10.17487/RFC2119, March 1997, 431 . 433 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 434 Writing an IANA Considerations Section in RFCs", BCP 26, 435 RFC 8126, DOI 10.17487/RFC8126, June 2017, 436 . 438 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 439 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 440 May 2017, . 442 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 443 "Network Service Header (NSH)", RFC 8300, 444 DOI 10.17487/RFC8300, January 2018, 445 . 447 7.2. Informational References 449 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 450 Chaining (SFC) Architecture", RFC 7665, 451 DOI 10.17487/RFC7665, October 2015, 452 . 454 Authors' Addresses 455 Ting Ao 456 Individual 457 No.889, BiBo Road 458 Shanghai 201203 459 China 461 Phone: +86 17721209283 462 Email: 18555817@qq.com 464 Greg Mirsky 465 ZTE Corp. 466 1900 McCarthy Blvd. #205 467 Milpitas, CA 95035 468 USA 470 Email: gregimirsky@gmail.com 472 Zhonghua Chen 473 China Telecom 474 No.1835, South PuDong Road 475 Shanghai 201203 476 China 478 Phone: +86 18918588897 479 Email: 18918588897@189.cn 481 Kent Leung 482 Cisco System 483 170 West Tasman Drive 484 San Jose, CA 95134 485 USA 487 Email: kleung@cisco.com