idnits 2.17.1 draft-ao-sfc-oam-return-path-specified-05.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 (December 1, 2019) is 1605 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-04 Summary: 0 errors (**), 0 flaws (~~), 2 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 contributor 4 Intended status: Standards Track G. Mirsky 5 Expires: June 3, 2020 ZTE Corp. 6 Z. Chen 7 China Telecom 8 December 1, 2019 10 Controlled Return Path for Service Function Chain (SFC) OAM 11 draft-ao-sfc-oam-return-path-specified-05 13 Abstract 15 This document defines an extension to the Service Function Chain 16 (SFC) Operation, Administration and Maintenance (OAM) that enables 17 control of the Echo Reply return path directing it over a Reverse 18 Service Function Path. Enforcing the specific return path can be 19 used to verify the bidirectional connectivity of SFC and increase the 20 robustness 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 June 3, 2020. 39 Copyright Notice 41 Copyright (c) 2019 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.ietf-sfc-multi-layer-oam], always traverses the SFC it directed 77 to, the corresponding Echo Reply is sent over IP network 78 [I-D.ietf-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 extends Service Function Chain (SFC) 81 Operation, Administration and Maintenance (OAM) by enabling control 82 of the Echo Reply return path to be directed over a Reply Service 83 Function Path (SFP). This document defines a new Type-Length-Value 84 (TLV), Reply Service Function Path TLV, for Reply via Specified Path 85 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 89 defined in Section 2.2 [RFC7665]. For example, it allows an operator 90 to test both directions of the bidirectional or hybrid SFP with a 91 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.ietf-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 as described in 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: the value for the Service Index field.in the NSH of 181 the SFC Echo Reply message. 183 5. Theory of Operation 185 [RFC7110] defined mechanism to control return path for MPLS LSP Echo 186 Reply. In case of SFC, the return path is an SFP along which SFC 187 Echo Reply message MUST be transmitted. Hence, the SFC Reply Path 188 TLV included in the SFC Echo Request message MUST sufficiently 189 identify the SFP that the sender of the Echo Request message expects 190 the receiver to use for the corresponding SFC Echo Reply. 192 When sending an Echo Request, the sender MUST set the value of Reply 193 Mode field to "Reply via Specified Path", defined in 194 [I-D.ietf-sfc-multi-layer-oam], and if the specified path is SFC 195 path, the Request MUST include SFC Reply Path TLV. The SFC Reply 196 Path TLV includes the identifier of the reverse SFP and an 197 appropriate Service Index. 199 Echo Reply is expected to be sent by the destination SFF of the SFP 200 being tested or by the SFF at which SFC TTL expires as defined 201 [RFC8300]. The processing described below equally applies to both 202 cases and referred to as responding SFF. 204 If the Echo Request message with SFC Reply Path TLV, received by the 205 responding SFF, has Reply Mode value of "Reply via Specified Path" 206 but no SFC Reply Path TLV is present, then the responding SFF MUST 207 send Echo Reply with Return Code set to "Reply Path TLV is missing" 208 value (TBA2). If the responding SFF cannot find requested SFP it 209 MUST send Echo Reply with Return Code set to "Reply SFP was not 210 found" and include the SFC Reply Path TLV from the Echo Request 211 message. 213 5.1. Bi-directional SFC Case 215 The ability to specify the return path for an Echo Reply might be 216 used in case of bi-directional SFC. The egress SFF of the forward 217 SFP may be not co-located with a classifier of the reverse SFP, and 218 thus the egress SFF has no infrmation about the reverse path of an 219 SFC. Because of that, even for bi-directional SFC, a reverse SFP 220 needs to be indicated in a Reply Path TLV in the Echo Request 221 message. 223 6. Security Considerations 225 Security considerations discussed in [RFC8300] apply to this 226 document. 228 The SFC Return Path extension, defined in this document, can be used 229 for potential "proxying" attacks. For example, an initiator of the 230 Echo Request may specify a return path that has a destination 231 different from that of the initiator. But usually, such attacks will 232 not happen in an SFC domain where the initiators and receivers belong 233 to the same domain, as specified in [RFC7665]. Even if the attack 234 occurs, in order to prevent using the SFC Return Path extension for 235 proxying any possible attacks, the return path SFP SHOULD have a path 236 to reach the sender of the Echo Request, identified in SFC Source TLV 237 [I-D.ietf-sfc-multi-layer-oam]. The receiver MAY drop the Echo 238 Request when it cannot determine whether the return path SFP has the 239 route to the initiator. That means, when sending Echo Request, the 240 sender SHOULD choose a proper source address according to specified 241 return path SFP to help the receiver to make the decision. 243 7. IANA Considerations 245 7.1. SFC Return Path Type 247 IANA is requested to assign from its SFC Echo Request/Echo Reply TLV 248 registry new type as follows: 250 +-------+----------------------+---------------+ 251 | Value | Description | Reference | 252 +-------+----------------------+---------------+ 253 | TBA1 | SFC Reply Path Type | This document | 254 +-------+----------------------+---------------+ 256 Table 1: SFC Return Path Type 258 7.2. New Return Codes 260 IANA is requested to assign new return codes from the SFC Echo 261 Request/Echo Reply Return Codes registry as following: 263 +-------+----------------------------+---------------+ 264 | Value | Description | Reference | 265 +-------+----------------------------+---------------+ 266 | TBA2 | Reply Path TLV is missing | This document | 267 | TBA3 | Reply SFP was not found | This document | 268 +-------+----------------------------+---------------+ 270 Table 2: SFC Echo Reply Return Codes 272 8. References 274 8.1. Normative References 276 [I-D.ietf-sfc-multi-layer-oam] 277 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active 278 OAM for Service Function Chains in Networks", draft-ietf- 279 sfc-multi-layer-oam-04 (work in progress), November 2019. 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, 283 DOI 10.17487/RFC2119, March 1997, 284 . 286 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 287 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 288 May 2017, . 290 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 291 "Network Service Header (NSH)", RFC 8300, 292 DOI 10.17487/RFC8300, January 2018, 293 . 295 8.2. Informative References 297 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, 298 "Return Path Specified Label Switched Path (LSP) Ping", 299 RFC 7110, DOI 10.17487/RFC7110, January 2014, 300 . 302 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 303 Chaining (SFC) Architecture", RFC 7665, 304 DOI 10.17487/RFC7665, October 2015, 305 . 307 Authors' Addresses 309 Ting Ao 310 Individual contributor 311 No.889, BiBo Road 312 Shanghai 201203 313 China 315 Phone: +86 17721209283 316 Email: 18555817@qq.com 317 Greg Mirsky 318 ZTE Corp. 319 1900 McCarthy Blvd. #205 320 Milpitas, CA 95035 321 USA 323 Email: gregimirsky@gmail.com 325 Zhonghua Chen 326 China Telecom 327 No.1835, South PuDong Road 328 Shanghai 201203 329 China 331 Phone: +86 18918588897 332 Email: 18918588897@189.cn