idnits 2.17.1 draft-ao-sfc-oam-path-consistency-03.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 (Oct 16, 2018) is 2012 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 (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-04 == Outdated reference: A later version (-15) exists of draft-ietf-sfc-nsh-tlv-00 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 T. Ao 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track G. Mirsky 5 Expires: April 19, 2019 ZTE Corp. 6 Z. Chen 7 China Telecom 8 Oct 16, 2018 10 SFC OAM for path consistency 11 draft-ao-sfc-oam-path-consistency-03 13 Abstract 15 Service Function Chain (SFC) defines an ordered set of service 16 functions (SFs) to be applied to packets and/or frames and/or flows 17 selected as a result of classification. SFC Operation, 18 Administration and Maintenance can monitor the continuity of the SFC, 19 i.e., that all elements of the SFC are reachable to each other in the 20 downstream direction. But SFC OAM must support verification that the 21 order of traversing these SFs corresponds to the state defined by the 22 SFC control plane or orchestrator, the metric referred in this 23 document as the path consistency of the SFC. This document defines a 24 new SFC OAM method to support SFC consistency, i.e. verification that 25 all elements of the given SFC are being traversed in the expected 26 order. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 19, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions used in this document . . . . . . . . . . . . . . 3 64 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 3. Consistency OAM: Theory of Operation . . . . . . . . . . . . 3 67 3.1. COAM packet . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. SF information Sub-TLV . . . . . . . . . . . . . . . . . 4 69 3.3. SF information Sub-TLV construction . . . . . . . . . . . 5 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 72 5.1. COAM Message Types . . . . . . . . . . . . . . . . . . . 7 73 5.2. SFF Information Record TLV Type . . . . . . . . . . . . . 7 74 5.3. SF Information Sub-TLV Type . . . . . . . . . . . . . . . 7 75 5.4. SF Identifier Types . . . . . . . . . . . . . . . . . . . 7 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 7.2. Informational References . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 Service Function Chain (SFC) is a chain with a series of ordered 85 Service Functions (SFs). Service Function Path (SFP) is a path of a 86 SFC. SFC is described in detail in the SFC architecture document 87 [RFC7665]. The SFs in the SFC are ordered and only when traffic is 88 processed by one SF then it should be processed by the next SF, 89 otherwise errors may occur. Sometimes, a SF needs to use the 90 metadata from its upstream SF process. That's why it's very 91 important for the operator to make sure that the order of traversing 92 the SFs is exactly as defined by the control plane or the 93 orchestrator. This document refers to the correspondence between the 94 state of control plane and the SFP itself as the SFP consistency. 96 This document defines the method to check the path consistency of the 97 SFP. It is an extension of the SFC Echo-request/Echo-reply specified 98 in the [I-D.wang-sfc-multi-layer-oam]. 100 2. Conventions used in this document 102 2.1. Terminology 104 SFC(Service Function Chain): An ordered set of some abstract SFs. 106 SFF: Service Function Forwarder 108 SF: Service Function 110 OAM: Operation, Administration and Maintenance 112 SFP: Service Function Path 114 COAM(Consistency OAM): OAM that can be used to check path 115 consistency. 117 2.2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 3. Consistency OAM: Theory of Operation 127 Consistency OAM uses two functions: COAM Request and COAM Reply. The 128 SFF, that is ingress of the SFP, transmits COAM Request packet. 129 Every intermediate SFF that receives the COAM Request MUST perform 130 the following actions: 132 collect information of traversed by the COAM Request packet SFs 133 and send it to the ingress SFF as COAM Reply packet over IP 134 network [I-D.wang-sfc-multi-layer-oam]; 136 forward the COAM Request to next downstream SFF if the one exists. 138 As result, the ingress SFF collects information about all traversed 139 SFFs and SFs, information of the actual path the COAM packet has 140 traveled, so that we can verify the path consistency of the SFC. The 141 mechanism for the SFP consistency verification is outside the scope 142 of this document. 144 3.1. COAM packet 146 Consistency OAM introduces two new types of messages to the SFC Echo 147 request/reply operation [I-D.wang-sfc-multi-layer-oam] with the 148 following values Section 5.1: 150 o TBA1 - COAM Request 152 o TBA2 - COAM Reply 154 An SFF, upon receiving the Consistency OAM Request, MUST include the 155 corresponding SFs information, Section 3.2, into the Value field of 156 the COAM Reply packet. 158 The COAM packet is displayed in Figure 1. 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Message Type | Reply mode | Return Code | Return S.code | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Sender's Handle | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Sequence Number | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Type | Length | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 ~ Value ~ 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 1: COAM Packet Header 175 3.2. SF information Sub-TLV 177 Every SFF receiving COAM Request packet MUST include the SF 178 characteristic data into the COAM Reply packet. The per SF data 179 included in COAM Reply packet as SF Information sub-TLV that is 180 displayed in Figure 2. 182 After the COAM traversed the SFP, all the information of the SFs on 183 the SFP are collected in the TLVs with COAM Reply. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | SF sub-TLV Type | Length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Service Path Identifier(SPI) | Service Index | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | SF Type | Reserved | SF ID Type | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | SF Identifiers | 195 ~ ~ 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 2: Service Function information sub-TLV 201 Service Path Identifier(SPI): The identifier of SFP to which all the 202 SFs in this TLV belong. 204 Service Index: indicates the SF's position on the SFP. 206 SF sub-TLV Type: is two octets long field. It indicates that the TLV 207 is a SF TLV which contains the information of one SF. 209 Length: is two octets long field. The value of the field is the 210 length of the data following the Length field counted in octets. 212 SF Type: is two octets long field. It is defined in 213 [I-D.ietf-bess-nsh-bgp-control-plane] and indicates the type of SF, 214 e.g., Firewall, Deep Packet Inspection, WAN optimization controller, 215 etc. 217 Reserved: For future use. MUST be zeroed on transmission and MUST be 218 ignored on receipt. 220 SF ID Type: is one octet long field with values defined as 221 Section 5.4. 223 SF Identifier: An identifier of the SF. The length of the SF 224 Identifier depends on the type of the SF ID Type. For example, if 225 the SF Identifier is its IPv4 address, the SF Identifier should be 32 226 bits. 228 3.3. SF information Sub-TLV construction 230 For each SFF in the SFP, it should send one COAM Reply corresponding 231 to each one COAM Request. If there is only one SF attached to the 232 SFF in such SFP, only one SF information sub-TLV is included in the 233 on COAM Reply. If there are several SFs attached to the SFF in the 234 SFP, SF information sub-TLV is constructed as the following two 235 cases. 237 1. Multiple SFs as hops of SFP: 239 Multiple SFs attached to one SFF are the several hops of the SFP, the 240 service indexes of these SFs are different. Service function types 241 of these SFs could be different or be same. All these SFs 242 information are included in one COAM Reply message, every SF 243 information should be listed as separate SF information sub-TLVs in 244 COAM Reply message. 246 2. Multiple SFs for load balance: 248 Multiple SFs are attached to one SFF for load balance, that means 249 only one SF will be transmitted for one traffic flow. These SFs have 250 the same Service Function Type, Service Index. For this case, the SF 251 identifiers of all these SFs will be listed in the SF Identifiers 252 field in a single SF information sub-TLV of COAM Reply message. The 253 number of these SFs can be calculated according to SF ID Type and the 254 value of Length field of the sub-TLV. 256 In the draft [I-D.ietf-sfc-nsh-tlv], a Flow ID is introduced which 257 can be used for load balance. SFF will distribute the SFC traffic 258 flow to a given SF according to the Flow ID. So for a NSH COAM 259 message carrying a Flow ID TLV, the SFF along the SFC could detect 260 the COAM message and then send back the COAM Reply message with the 261 corresponding SF information according to the Flow ID in the COAM. 263 4. Security Considerations 265 Security considerations discussed in [RFC8300] apply to this 266 document. 268 In addition, since Service Function sub-TLV discloses information 269 about the RSP the spoofed COAM Request packet may be used to obtain 270 network information, it is RECOMMENDED that implementations provide a 271 means of checking the source addresses of COAM Request messages, 272 specified in SFC Source TLV [I-D.wang-sfc-multi-layer-oam], against 273 an access list before accepting the message. 275 5. IANA Considerations 276 5.1. COAM Message Types 278 IANA is requested to assign values from its Message Types sub- 279 registry in SFC Echo Request/Echo Reply Message Types registry as 280 follows: 282 +-------+------------------------------+---------------+ 283 | Value | Description | Reference | 284 +-------+------------------------------+---------------+ 285 | TBA1 | SFP Consistency Echo Request | This document | 286 | TBA2 | SFP Consistency Echo Reply | This document | 287 +-------+------------------------------+---------------+ 289 Table 1: SFP Consistency Echo Request/Echo Reply Message Types 291 5.2. SFF Information Record TLV Type 293 IANA is requested to assign new type value from SFC OAM TLV Type 294 registry as follows: 296 +-------+-----------------------------+---------------+ 297 | Value | Description | Reference | 298 +-------+-----------------------------+---------------+ 299 | TBA3 | SFF Information Record Type | This document | 300 +-------+-----------------------------+---------------+ 302 Table 2: SFF-Information Record 304 5.3. SF Information Sub-TLV Type 306 IANA is requested to assign new type value from SFC OAM TLV Type 307 registry as follows: 309 +-------+----------------+---------------+ 310 | Value | Description | Reference | 311 +-------+----------------+---------------+ 312 | TBA4 | SF Information | This document | 313 +-------+----------------+---------------+ 315 Table 3: SF-Information Sub-TLV Type 317 5.4. SF Identifier Types 319 IANA is requested create in the registry SF Types the new sub- 320 registry SF Identifier Types. All code points in the range 1 through 321 191 in this registry shall be allocated according to the "IETF 322 Review" procedure as specified in [RFC8126] and assign values as 323 follows: 325 +------------+-------------+-------------------------+ 326 | Value | Description | Reference | 327 +------------+-------------+-------------------------+ 328 | 0 | Reserved | This document | 329 | TBA6 | IPv4 | This document | 330 | TBA7 | IPv6 | This document | 331 | TBA8 | MAC | This document | 332 | TBA8+1-191 | Unassigned | IETF Review | 333 | 192-251 | Unassigned | First Come First Served | 334 | 252-254 | Unassigned | Private Use | 335 | 255 | Reserved | This document | 336 +------------+-------------+-------------------------+ 338 Table 4: SF Identifier Type 340 6. Acknowledgements 342 Thanks to John Drake for his review and the reference to the work on 343 BGP Control Plane for NSH SFC. 345 7. References 347 7.1. Normative References 349 [I-D.ietf-bess-nsh-bgp-control-plane] 350 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 351 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 352 nsh-bgp-control-plane-04 (work in progress), July 2018. 354 [I-D.ietf-sfc-nsh-tlv] 355 Quinn, P., Elzur, U., and S. Majee, "Network Service 356 Header TLVs", draft-ietf-sfc-nsh-tlv-00 (work in 357 progress), January 2018. 359 [I-D.wang-sfc-multi-layer-oam] 360 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active 361 OAM for Service Function Chains in Networks", draft-wang- 362 sfc-multi-layer-oam-12 (work in progress), October 2018. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, 366 DOI 10.17487/RFC2119, March 1997, 367 . 369 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 370 Writing an IANA Considerations Section in RFCs", BCP 26, 371 RFC 8126, DOI 10.17487/RFC8126, June 2017, 372 . 374 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 375 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 376 May 2017, . 378 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 379 "Network Service Header (NSH)", RFC 8300, 380 DOI 10.17487/RFC8300, January 2018, 381 . 383 7.2. Informational References 385 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 386 Chaining (SFC) Architecture", RFC 7665, 387 DOI 10.17487/RFC7665, October 2015, 388 . 390 Authors' Addresses 392 Ting Ao 393 ZTE Corporation 394 No.889, BiBo Road 395 Shanghai 201203 396 China 398 Phone: +86 21 68897642 399 Email: ao.ting@zte.com.cn 401 Greg Mirsky 402 ZTE Corp. 403 1900 McCarthy Blvd. #205 404 Milpitas, CA 95035 405 USA 407 Email: gregimirsky@gmail.com 409 Zhonghua Chen 410 China Telecom 411 No.1835, South PuDong Road 412 Shanghai 201203 413 China 415 Phone: +86 18918588897 416 Email: 18918588897@189.cn