idnits 2.17.1 draft-ao-sfc-oam-return-path-specified-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 3, 2020) is 1422 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 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 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 June 3, 2020 10 Controlled Return Path for Service Function Chain (SFC) OAM 11 draft-ao-sfc-oam-return-path-specified-06 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 December 5, 2020. 39 Copyright Notice 41 Copyright (c) 2020 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). Such extension is based on the analysis of SFC 84 OAM, active OAM protocols in particular, provided in 85 [I-D.ietf-sfc-oam-framework]. This document defines a new Type- 86 Length-Value (TLV), Reply Service Function Path TLV, for Reply via 87 Specified Path mode of SFC Echo Reply (Section 4). 89 The Reply Service Function Path TLV can provide an efficient 90 mechanism to test SFCs, such as bidirectional and hybrid SFC, as 91 defined in Section 2.2 [RFC7665]. For example, it allows an operator 92 to test both directions of the bidirectional or hybrid SFP with a 93 single SFC Echo Request/Echo Reply operation. 95 2. Conventions used in this document 97 2.1. Terminology 99 SF - Service Function 101 SFF - Service Function Forwarder 103 SFC - Service Function Chain, an ordered set of some abstract SFs. 105 SFP - Service Function Path 107 SPI - Service Path Index 109 OAM - Operation, Administration, and Maintenance 111 2.2. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 3. Extension 121 The following reply modes had been defined in 122 [I-D.ietf-sfc-multi-layer-oam]: 124 o Do Not Reply 126 o Reply via an IPv4/IPv6 UDP Packet 128 o Reply via Application Level Control Channel 130 o Reply via Specified Path 132 The Reply via Specified Path mode is intended to enforce the use of 133 the particular return path specified in the included TLV. This mode 134 may help verify bidirectional continuity or increase SFC monitoring's 135 robustness by selecting a more stable path. In the case of SFC, the 136 sender of Echo Request instructs the destination SFF to send Echo 137 Reply message along the SFP specified in the SFC Reply Path TLV, as 138 described in Section 4. 140 4. SFC Reply Path TLV 142 The SFC Reply Path TLV carries the information that sufficiently 143 identifies the return SFP that the SFC Echo Reply message is expected 144 to follow. The format of SFC Reply Path TLV is shown in Figure 1. 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | SFC Reply Path Type | Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Reply Service Function Path | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Figure 1: SFC Reply TLV Format 156 where: 158 o Reply Path TLV Type: is two octets long, indicates the TLV that 159 contains information about the SFC Reply path. 161 o Length: is two octets long, MUST be equal to 4 163 o Reply Service Function Path is used to describe the return path 164 that an SFC Echo Reply is requested to follow. 166 The format of the Reply Service Function Path field displayed in 167 Figure 2 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Reply Service Function Path Identifier | Service Index | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 2: Reply Service Function Path Field Format 177 where: 179 o Reply Service Function Path Identifier: SFP identifier for the 180 path that the SFC Echo Reply message is requested to be sent over. 182 o Service Index: the value for the Service Index field in the NSH of 183 the SFC Echo Reply message. 185 5. Theory of Operation 187 [RFC7110] defined mechanism to control return path for MPLS LSP Echo 188 Reply. In case of SFC, the return path is an SFP along which SFC 189 Echo Reply message MUST be transmitted. Hence, the SFC Reply Path 190 TLV included in the SFC Echo Request message MUST sufficiently 191 identify the SFP that the sender of the Echo Request message expects 192 the receiver to use for the corresponding SFC Echo Reply. 194 When sending an Echo Request, the sender MUST set the value of Reply 195 Mode field to "Reply via Specified Path", defined in 196 [I-D.ietf-sfc-multi-layer-oam], and if the specified path is SFC 197 path, the Request MUST include SFC Reply Path TLV. The SFC Reply 198 Path TLV includes the identifier of the reverse SFP and an 199 appropriate Service Index. 201 Echo Reply is expected to be sent by the destination SFF of the SFP 202 being tested or by the SFF at which SFC TTL expires as defined 203 [RFC8300]. The processing described below equally applies to both 204 cases and referred to as responding SFF. 206 If the Echo Request message with SFC Reply Path TLV, received by the 207 responding SFF, has Reply Mode value of "Reply via Specified Path" 208 but no SFC Reply Path TLV is present, then the responding SFF MUST 209 send Echo Reply with Return Code set to "Reply Path TLV is missing" 210 value (TBA2). If the responding SFF cannot find requested SFP it 211 MUST send Echo Reply with Return Code set to "Reply SFP was not 212 found" and include the SFC Reply Path TLV from the Echo Request 213 message. 215 5.1. Bi-directional SFC Case 217 The ability to specify the return path for an Echo Reply might be 218 used in the case of bi-directional SFC. The egress SFF of the 219 forward SFP may be not co-located with a classifier of the reverse 220 SFP, and thus the egress SFF has no information about the reverse 221 path of an SFC. Because of that, even for bi-directional SFC, a 222 reverse SFP needs to be indicated in a Reply Path TLV in the Echo 223 Request message. 225 6. Security Considerations 227 Security considerations discussed in [RFC8300] apply to this 228 document. 230 The SFC Return Path extension, defined in this document, can be used 231 for potential "proxying" attacks. For example, an initiator of the 232 Echo Request may specify a return path that has a destination 233 different from that of the initiator. But usually, such attacks will 234 not happen in an SFC domain where the initiators and receivers belong 235 to the same domain, as specified in [RFC7665]. Even if the attack 236 occurs, to prevent using the SFC Return Path extension for proxying 237 any possible attacks, the return path SFP SHOULD have a path to reach 238 the sender of the Echo Request, identified in SFC Source TLV 239 [I-D.ietf-sfc-multi-layer-oam]. The receiver MAY drop the Echo 240 Request when it cannot determine whether the return path SFP has the 241 route to the initiator. That means, when sending Echo Request, the 242 sender SHOULD choose a proper source address according to specified 243 return path SFP to help the receiver to make the decision. 245 7. IANA Considerations 247 7.1. SFC Return Path Type 249 IANA is requested to assign from its SFC Echo Request/Echo Reply TLV 250 registry new type as follows: 252 +-------+----------------------+---------------+ 253 | Value | Description | Reference | 254 +-------+----------------------+---------------+ 255 | TBA1 | SFC Reply Path Type | This document | 256 +-------+----------------------+---------------+ 258 Table 1: SFC Return Path Type 260 7.2. New Return Codes 262 IANA is requested to assign new return codes from the SFC Echo 263 Request/Echo Reply Return Codes registry as following: 265 +-------+----------------------------+---------------+ 266 | Value | Description | Reference | 267 +-------+----------------------------+---------------+ 268 | TBA2 | Reply Path TLV is missing | This document | 269 | TBA3 | Reply SFP was not found | This document | 270 +-------+----------------------------+---------------+ 272 Table 2: SFC Echo Reply Return Codes 274 8. References 276 8.1. Normative References 278 [I-D.ietf-sfc-multi-layer-oam] 279 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active 280 OAM for Service Function Chains in Networks", draft-ietf- 281 sfc-multi-layer-oam-06 (work in progress), June 2020. 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, 285 DOI 10.17487/RFC2119, March 1997, 286 . 288 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 289 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 290 May 2017, . 292 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 293 "Network Service Header (NSH)", RFC 8300, 294 DOI 10.17487/RFC8300, January 2018, 295 . 297 8.2. Informative References 299 [I-D.ietf-sfc-oam-framework] 300 Aldrin, S., Pignataro, C., Nainar, N., Krishnan, R., and 301 A. Ghanwani, "Service Function Chaining (SFC) Operations, 302 Administration and Maintenance (OAM) Framework", draft- 303 ietf-sfc-oam-framework-15 (work in progress), May 2020. 305 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, 306 "Return Path Specified Label Switched Path (LSP) Ping", 307 RFC 7110, DOI 10.17487/RFC7110, January 2014, 308 . 310 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 311 Chaining (SFC) Architecture", RFC 7665, 312 DOI 10.17487/RFC7665, October 2015, 313 . 315 Authors' Addresses 317 Greg Mirsky 318 ZTE Corp. 319 1900 McCarthy Blvd. #205 320 Milpitas, CA 95035 321 USA 323 Email: gregimirsky@gmail.com 324 Ting Ao 325 Individual contributor 326 No.889, BiBo Road 327 Shanghai 201203 328 China 330 Phone: +86 17721209283 331 Email: 18555817@qq.com 333 Zhonghua Chen 334 China Telecom 335 No.1835, South PuDong Road 336 Shanghai 201203 337 China 339 Phone: +86 18918588897 340 Email: 18918588897@189.cn