idnits 2.17.1 draft-ao-sfc-oam-return-path-specified-02.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 (October 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 October 16, 2018 10 Controlled Return Path for Service Function Chain (SFC) OAM 11 draft-ao-sfc-oam-return-path-specified-02 13 Abstract 15 This document defines extensions to the Service Function Chain (SFC) 16 Operation, Administration and Maintenance (OAM) that enable control 17 of the Echo Reply return path by specifying it as Reverse Service 18 Function Path. Enforcing the specific return path can be used to 19 verify bidirectional connectivity of SFC and increase the robustness 20 of SFC OAM. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 19, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 3 58 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 3. Extension . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. SFC Reply Path TLV . . . . . . . . . . . . . . . . . . . . . 4 62 5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. Bi-directional SFC Case . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 7.1. SFC Return Path Type . . . . . . . . . . . . . . . . . . 6 67 7.2. New Return Codes . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 While Service Function Chain (SFC) Echo Request, defined in 76 [I-D.wang-sfc-multi-layer-oam], always traverses the SFC it directed 77 to, the corresponding Echo Reply is sent over IP network 78 [I-D.wang-sfc-multi-layer-oam]. There are scenarios when it is 79 beneficial to direct the responder to use a path other than the IP 80 network. This document defines extensions to the Service Function 81 Chain (SFC) Operation, Administration and Maintenance (OAM) that 82 enable control of the Echo Reply return path by specifying it as 83 Reply Service Function Path. This document defines a new Type- 84 Length-Value (TLV), Reply Service Function Path TLV, for Reply via 85 Specified Path mode of SFC Echo Reply (Section 4). 87 The Reply Service Function Path TLV can provide an efficient 88 mechanism to test SFCs,such as bidirectional and hybrid SFC, as these 89 were defined in Section 2.2 [RFC7665], For example, it allows an 90 operator to test both directions of the bidirectional or hybrid SFP 91 with a single SFC Echo Request/Echo Reply operation. 93 2. Conventions used in this document 95 2.1. Terminology 97 SF - Service Function 99 SFF - Service Function Forwarder 101 SFC - Service Function Chain, an ordered set of some abstract SFs. 103 SFP - Service Function Path 105 SPI - Service Path Index 107 OAM - Operation, Administration, and Maintenance 109 2.2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 3. Extension 119 Following reply modes had been defined in 120 [I-D.wang-sfc-multi-layer-oam]: 122 o Do Not Reply 124 o Reply via an IPv4/IPv6 UDP Packet 126 o Reply via Application Level Control Channel 128 o Reply via Specified Path 130 The Reply via Specified Path mode is intended to enforce the use of 131 the particular return path specified in the included TLV. This mode 132 may help to verify bidirectional continuity or increase the 133 robustness of the monitoring of the SFC by selecting a more stable 134 path. In the case of SFC, the sender of Echo Request instructs the 135 destination SFF to send Echo Reply message along the SFP specified in 136 the SFC Reply Path TLV Section 4. 138 4. SFC Reply Path TLV 140 The SFC Reply Path TLV carries the information that sufficiently 141 identifies the return SFP that the SFC Echo Reply message is expected 142 to follow. The format of SFC Reply Path TLV is shown in Figure 1. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | SFC Reply Path Type | Length | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Reply Service Function Path | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1: SFC Reply TLV Format 154 where: 156 o Reply Path TLV Type: is two octets long, indicates the TLV that 157 contains information about the SFC Reply path. 159 o Length: is two octets long, MUST be equal to 4 161 o Reply Service Function Path is used to describe the return path 162 that an SFC Echo Reply is requested to follow. 164 The format of the Reply Service Function Path field displayed in 165 Figure 2 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Reply Service Function Path Identifier | Service Index | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 2: Reply Service Function Path Field Format 175 where: 177 o Reply Service Function Path Identifier: SFP identifier for the 178 path that the SFC Echo Reply message is requested to be sent over. 180 o Service Index: used for forwarding in the reply SFP. 182 5. Theory of Operation 184 [RFC7110] defined mechanism to control return path for MPLS LSP Echo 185 Reply. In case of SFC, the return path is a SFP along which SFC Echo 186 Reply message MUST be transmitted. Hence, the SFC Reply Path TLV 187 included in the SFC Echo Request message MUST sufficiently identify 188 the SFP that the sender of the Echo Request message expects the 189 receiver to use for the corresponding SFC Echo Reply. 191 When sending an Echo Request, the sender MUST set the value of Reply 192 Mode field to "Reply via Specified Path", defined in 193 [I-D.wang-sfc-multi-layer-oam], and if the specified path is SFC 194 path, the Request MUST include SFC Reply Path TLV. The SFC Reply 195 Path TLV includes identifier of the reverse SFP and an appropriate 196 Service Index. 198 Echo Reply is expected to be sent by the destination SFF of the SFP 199 being tested or by the SFF at which SFC TTL expires as defined 200 [I-D.ietf-sfc-nsh]. The processing described below equally applies 201 in both cases and referred to as responding SFF. 203 If the Echo Request message with SFC Reply Path TLV, received by the 204 responding SFF, has Reply Mode value of "Reply via Specified Path" 205 but no SFC Reply Path TLV is present, then the responding SFF MUST 206 send Echo Reply with Return Code set to "Reply Path TLV is missing" 207 value (TBA2). If the responding SFF cannot find requested SFP it 208 MUST send Echo Reply with Return Code set to "Reply SFP was not 209 found" and include the SFC Reply Path TLV from the Echo Request 210 message. 212 5.1. Bi-directional SFC Case 214 Ability to specify the return path to be used for Echo Reply is handy 215 in bi-directional SFC. For bi-directional SFC, since the last SFF of 216 the forward SFP may not co-locate with a classifier of the reverse 217 SFP,it is assumed that the last SFF doesn't know the reply path of a 218 SFC. So even for bi-directional SFC, a reverse SFP also need to be 219 indicated in reply path TLV in echo request message. 221 6. Security Considerations 223 Security considerations discussed in [I-D.ietf-sfc-nsh] apply to this 224 document. 226 In addition, the SFC Return Path extension, defined in this document, 227 can be used for potential "proxying" attacks. For example, an echo 228 request initiator may specify a return path that has a destination 229 different from that of the initiator. But usually, such attacks will 230 not happen in an SFC domain where the initiators and receivers belong 231 to the same domain, as specified in [RFC7665]. Even if the attack 232 occurs, in order to prevent using the SFC Return Path extension for 233 proxying any possible attacks, the return path SFP SHOULD have a path 234 to reach the sender of the echo request, identified in SFC Source TLV 235 [I-D.wang-sfc-multi-layer-oam]. The receiver MAY drop the echo 236 request when it cannot determine whether the return path SFP has the 237 route to the initiator. That means, when sending echo request, the 238 sender SHOULD choose a proper source address according to specified 239 return path SFP to help the receiver to make the decision. 241 7. IANA Considerations 243 7.1. SFC Return Path Type 245 IANA is requested to assign from its SFC Echo Request/Echo Reply TLV 246 registry new type as follows: 248 +-------+----------------------+---------------+ 249 | Value | Description | Reference | 250 +-------+----------------------+---------------+ 251 | TBA1 | SFC Reply Path Type | This document | 252 +-------+----------------------+---------------+ 254 Table 1: SFC Return Path Type 256 7.2. New Return Codes 258 IANA is requested to assign new return codes from the SFC Echo 259 Request/Echo Reply Return Codes registry as following: 261 +-------+----------------------------+---------------+ 262 | Value | Description | Reference | 263 +-------+----------------------------+---------------+ 264 | TBA2 | Reply Path TLV is missing | This document | 265 | TBA3 | Reply SFP was not found | This document | 266 +-------+----------------------------+---------------+ 268 Table 2: SFC Echo Reply Return Codes 270 8. References 272 8.1. Normative References 274 [I-D.ietf-sfc-nsh] 275 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 276 Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress), 277 November 2017. 279 [I-D.wang-sfc-multi-layer-oam] 280 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active 281 OAM for Service Function Chains in Networks", draft-wang- 282 sfc-multi-layer-oam-12 (work in progress), October 2018. 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, 286 DOI 10.17487/RFC2119, March 1997, 287 . 289 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 290 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 291 May 2017, . 293 8.2. Informative References 295 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, 296 "Return Path Specified Label Switched Path (LSP) Ping", 297 RFC 7110, DOI 10.17487/RFC7110, January 2014, 298 . 300 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 301 Chaining (SFC) Architecture", RFC 7665, 302 DOI 10.17487/RFC7665, October 2015, 303 . 305 Authors' Addresses 307 Ting Ao 308 ZTE Corporation 309 No.889, BiBo Road 310 Shanghai 201203 311 China 313 Phone: +86 21 68897642 314 Email: ao.ting@zte.com.cn 316 Greg Mirsky 317 ZTE Corp. 318 1900 McCarthy Blvd. #205 319 Milpitas, CA 95035 320 USA 322 Email: gregimirsky@gmail.com 323 Zhonghua Chen 324 China Telecom 325 No.1835, South PuDong Road 326 Shanghai 201203 327 China 329 Phone: +86 18918588897 330 Email: 18918588897@189.cn