idnits 2.17.00 (12 Aug 2021) /tmp/idnits60685/draft-ietf-sfc-oam-packet-01.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 document date (25 April 2022) is 19 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) == Missing Reference: 'SFC-OAM-FRAMEWORK' is mentioned on line 109, but not defined 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 M. Boucadair 3 Internet-Draft Orange 4 Updates: 8300 (if approved) 25 April 2022 5 Intended status: Standards Track 6 Expires: 27 October 2022 8 OAM Packet and Behavior in the Network Service Header (NSH) 9 draft-ietf-sfc-oam-packet-01 11 Abstract 13 This document clarifies an ambiguity in the Network Service Header 14 (NSH) specification related to the handling of O bit. In particular, 15 this document clarifies the meaning of "OAM packet". 17 This document updates RFC 8300. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 27 October 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. An Update to RFC8300 . . . . . . . . . . . . . . . . . . . . 3 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 7.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 This document clarifies an ambiguity related to the definition of 66 Operations, Administration, and Maintenance (OAM) packet discussed in 67 [RFC8300]. 69 The processing of the O bit in the Network Service Header (NSH) must 70 follow the updated behavior specified in Section 3. 72 2. Terminology 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 76 "OPTIONAL" in this document are to be interpreted as described in BCP 77 14 [RFC2119] [RFC8174] when, and only when, they appear in all 78 capitals, as shown here. 80 This document makes use of the terms defined in [RFC7665] and 81 [RFC8300]. 83 The document defines the following terms: 85 SFC data plane element: refers to SFC-aware SF, SFF, SFC Proxy, or 86 Classifier as defined in the SFC data plane architecture [RFC7665] 87 and further refined in [RFC8300]. 89 OAM control element: an NSH-aware element that is capable of 90 generating NSH OAM packets. An SFC data plane element may behave 91 as an OAM control element. 93 SFC OAM data: refers to an OAM request (e.g., Connectivity 94 Verification and Continuity Checks [RFC7276]), any data that 95 influences how to execute a companion OAM request (e.g., identity 96 of a terminating Service Function (SF)), the output data of an OAM 97 request, and any combination thereof. 99 User data: refers to user packets cited in Section 5.7 of [RFC7665]. 101 3. An Update to RFC8300 103 This document updates Section 2.2 of [RFC8300] as follows: 105 OLD: 107 O bit: Setting this bit indicates an OAM packet (see [RFC6291]). 108 The actual format and processing of SFC OAM packets is outside the 109 scope of this specification (for example, see [SFC-OAM-FRAMEWORK] 110 for one approach). 112 The O bit MUST be set for OAM packets and MUST NOT be set for 113 non-OAM packets. The O bit MUST NOT be modified along the SFP. 115 SF/SFF/SFC Proxy/Classifier implementations that do not support 116 SFC OAM procedures SHOULD discard packets with O bit set, but MAY 117 support a configurable parameter to enable forwarding received SFC 118 OAM packets unmodified to the next element in the chain. 119 Forwarding OAM packets unmodified by SFC elements that do not 120 support SFC OAM procedures may be acceptable for a subset of OAM 121 functions, but it can result in unexpected outcomes for others; 122 thus, it is recommended to analyze the impact of forwarding an OAM 123 packet for all OAM functions prior to enabling this behavior. The 124 configurable parameter MUST be disabled by default. 126 NEW: 128 O bit: Setting this bit indicates an NSH OAM packet. Such a packet 129 is any NSH-encapsulated packet that exclusively includes SFC OAM 130 data. SFC OAM data can be included in the Fixed-Length Context 131 Header, optional Context Headers, and/or the inner packet. 133 The O bit is typically set by an OAM controller or a final 134 destination of an NSH OAM packet that triggers a response (e.g., a 135 specific SFC-aware SF, the last SFF of an SFP). 137 The O bit MUST be set for NSH OAM packets and MUST NOT be set for 138 non-OAM packets. The O bit MUST NOT be modified along the SFP. 140 NSH-encapsulated packets that include user data are not considered 141 as NSH OAM packets even if some SFC OAM data (e.g., record route) 142 is also supplied in the packet. 144 When SFC OAM data is included in the inner packet, the Next 145 Protocol field is set to reflect the structure of that inner OAM 146 packet. The setting and processing of the O bit neither assumes 147 nor expects detailed analysis of the content of any inner IP 148 packet carried by the NSH. As such, SFFs, SFC-aware SFs, and SFC 149 Proxies SHOULD discard any NSH packets with the O bit set and Next 150 Protocol set to something that is not itself an OAM protocol. 151 This includes discarding the packet when the O bit is set and the 152 Next Protocol is set to 0x01 (IPv4), 0x02 (IPv6), 0x03 (MPLS), or 153 0x05 (Ethernet). 155 An NSH OAM packet MAY include optional Context Headers (e.g., a 156 subscriber identifier [RFC8979] or a flow identifier 157 [I-D.ietf-sfc-nsh-tlv]) that are used to influence the processing 158 of the packet by SFC data plane elements. 160 An NSH OAM packet MAY include SFC OAM data in both Context Headers 161 and the inner packet. The processing (including the order) of the 162 SFC OAM data SHOULD be specified in the relevant OAM or Context 163 Header specification. 165 SFC-aware SF/SFF/SFC Proxy/Classifier implementations that do not 166 support SFC OAM procedures SHOULD discard packets with O bit set, 167 but MAY support a configurable parameter to enable forwarding 168 received NSH OAM packets unmodified to the next element in the 169 chain. Forwarding NSH OAM packets unmodified by SFC data plane 170 elements that do not support SFC OAM procedures may be acceptable 171 for a subset of OAM functions, but it can result in unexpected 172 outcomes for others; thus, it is recommended to analyze the impact 173 of forwarding an NSH OAM packet for all OAM functions prior to 174 enabling this behavior. The configurable parameter MUST be 175 disabled by default. 177 The actual format and additional processing of NSH OAM packets is 178 outside the scope of this specification. 180 4. IANA Considerations 182 This document does not make any request to IANA. 184 5. Security Considerations 186 Data plane SFC-related security considerations, including privacy, 187 are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300]. 188 Additional security considerations related to SFC OAM are discussed 189 in Section 9 of [RFC8924]. 191 Any data included in an NSH OAM packet SHOULD be integrity-protected 192 [RFC9145]. 194 6. Acknowledgments 196 Thanks to Jim Guichard, Greg Mirsky, Joel Halpern, Christian 197 Jacquenet, Dirk von-Hugo, Carlos Pignataro, and Frank Brockners for 198 the comments. 200 7. References 202 7.1. Normative References 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, 206 DOI 10.17487/RFC2119, March 1997, 207 . 209 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 210 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 211 May 2017, . 213 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 214 "Network Service Header (NSH)", RFC 8300, 215 DOI 10.17487/RFC8300, January 2018, 216 . 218 [RFC9145] Boucadair, M., Reddy.K, T., and D. Wing, "Integrity 219 Protection for the Network Service Header (NSH) and 220 Encryption of Sensitive Context Headers", RFC 9145, 221 DOI 10.17487/RFC9145, December 2021, 222 . 224 7.2. Informative References 226 [I-D.ietf-sfc-nsh-tlv] 227 Wei, Y., Elzur, U., Majee, S., Pignataro, C., and D. E. 228 Eastlake, "Network Service Header (NSH) Metadata Type 2 229 Variable-Length Context Headers", Work in Progress, 230 Internet-Draft, draft-ietf-sfc-nsh-tlv-15, 20 April 2022, 231 . 234 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 235 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 236 Acronym in the IETF", BCP 161, RFC 6291, 237 DOI 10.17487/RFC6291, June 2011, 238 . 240 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 241 Weingarten, "An Overview of Operations, Administration, 242 and Maintenance (OAM) Tools", RFC 7276, 243 DOI 10.17487/RFC7276, June 2014, 244 . 246 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 247 Chaining (SFC) Architecture", RFC 7665, 248 DOI 10.17487/RFC7665, October 2015, 249 . 251 [RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, 252 R., and A. Ghanwani, "Service Function Chaining (SFC) 253 Operations, Administration, and Maintenance (OAM) 254 Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020, 255 . 257 [RFC8979] Sarikaya, B., von Hugo, D., and M. Boucadair, "Subscriber 258 and Performance Policy Identifier Context Headers in the 259 Network Service Header (NSH)", RFC 8979, 260 DOI 10.17487/RFC8979, February 2021, 261 . 263 Author's Address 265 Mohamed Boucadair 266 Orange 267 35000 Rennes 268 France 269 Email: mohamed.boucadair@orange.com