idnits 2.17.00 (12 Aug 2021) /tmp/idnits18850/draft-ietf-sfc-nsh-dc-allocation-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 25, 2018) is 1327 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 274, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining J. Guichard, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Informational M. Smith 5 Expires: March 29, 2019 S. Kumar 6 Cisco Systems, Inc. 7 S. Majee 8 F5 Networks 9 T. Mizrahi 10 Marvell 11 September 25, 2018 13 Network Service Header (NSH) MD Type 1: Context Header Allocation (Data 14 Center) 15 draft-ietf-sfc-nsh-dc-allocation-02 17 Abstract 19 This document provides a recommended default allocation for the 20 Network Service Header (NSH) MD Type 1 fixed length context header 21 when NSH is used for Service Function Chaining within a data center. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 29, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 2 59 3. Recommended Data Center MD Type 1 Fixed Length Context 60 Allocation . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Data Center Allocation Specifics . . . . . . . . . . . . 3 62 4. Context Allocation and Control Plane Considerations . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 9.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 Network Service Header (NSH) [RFC8300] provides a mechanism to carry 75 shared metadata between network devices and service functions, and 76 between service functions. When MD Type 1 is used, such metadata is 77 carried within a fixed length (16-bytes) context header. 79 This document provides a recommended default allocation of the MD 80 Type 1 context header for Service Function Chaining [RFC7665] within 81 a data center. The context header may be used to support use cases 82 such as those described in [I-D.ietf-sfc-dc-use-cases]. 84 The goal of this document is to provide a reference allocation that 85 may be used with or without a control plane. It also serves as a 86 guide to implementers and network operators. 88 2. Definition Of Terms 90 This document uses the terms as defined in [RFC7498], [RFC7665], and 91 [RFC8300]. 93 3. Recommended Data Center MD Type 1 Fixed Length Context Allocation 95 The following context header allocation provides information used to 96 support SFC operation within a generic data center environment. 97 [I-D.ietf-sfc-dc-use-cases] provides an overview of data center use 98 cases to support the allocation. 100 The 16 bytes of Fixed Length Context Header is delivered to service 101 functions that may then use the metadata it carries for local policy 102 enforcement and other functionality. 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 |D| F |R| Source Node ID | Source Interface ID | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Reserved | Tenant ID | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Destination Class / Reserved | Source Class | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Opaque Service Class | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 Figure 1: NSH DC Context Allocation 117 3.1. Data Center Allocation Specifics 119 The specific 16 byte allocation of the Fixed Length Context Header is 120 as follows: 122 Flag bits: Bits 0-3 are flag bits. Bits 0-2 are defined in this 123 document and the remaining bit is reserved. 125 D bit: The D-bit is used to indicate whether the Destination Class 126 field in the 3rd word is used. If D-bit is not set then the field 127 is reserved. 129 F bits: Two-bit value that indicates the format of the Opaque 130 Service Class in the 4th word. 132 Source Node ID: An identifier indicating the source device where the 133 original traffic initially entered the Service Function Chain. This 134 identifier is unique within an SFC-enabled domain. 136 Source Interface ID: An identifier indicating the source interface 137 where the original traffic initially entered the Service Function 138 Chain. This identifier is scoped within the context of the Source 139 Node ID. 141 Tenant ID: The tenant identifier is used to represent the tenant that 142 the Service Function Chain is being applied to. The Tenant ID is a 143 unique value assigned by a control plane. The distribution of Tenant 144 ID's is outside the scope of this document. As an example 145 application of this field, hardware may insert a VRF ID, VLAN number 146 or VXLAN VNI. 148 Destination Class: The destination class represents the logical 149 classification of the destination of the traffic. This field is 150 optional and/or the Destination Class may not be known. The D-bit is 151 used to indicate that this field contains a valid Destination Class. 153 Source Class: represents the logical classification of the source of 154 the traffic. For example, this might represent a source application, 155 a group of like endpoints, or a set of users originating the traffic. 156 This grouping is done for the purposes of applying policy. Policy is 157 applied to groups rather than individual endpoints. 159 Opaque Service Class: A unique identifier that can carry metadata 160 specific to a Rendered Service Path, the format of which is specified 161 by the value of the F-bits as follows: 163 00: If the F-bits are not set, then the Opaque Service Class field 164 is not specified and can be used as determined by the control 165 plane. 167 01 (ServiceTag): a ServiceTag is used to identify a particular 168 flow, transaction or an application message unit. The ServiceTag 169 may be used to augment the source and/or destination class. A 170 ServiceTag is a unique identifier that can be used to enable 171 functionality such as classification bypass, slow path skipping 172 and flow programming. As part of the ServiceTag word, bit 0 is 173 the A bit and is used, when needed, to indicate acknowledgement of 174 a ServiceTag by a Service Function. 176 02 (Application ID): contains an application identification as 177 described in [RFC6759] 179 03 (Timestamp): indicates the time at which the packet was 180 received by the Classifier. 182 The Timestamp has two possible formats: 184 * A 32-bit nanosecond field (Figure 2), which uses the 32 least 185 significant bits of the IEEE 1588 [IEEE1588] timestamp format. 187 * The NTP [RFC5905] 32-bit Timestamp format (Figure 3), which is 188 one of the recommended timestamp formats in 189 [I-D.mizrahi-intarea-packet-timestamps]. 191 It is assumed that in a given administrative domain only one of 192 the formats will be used, and that the control plane determines 193 which timestamp format is used. 195 The two timestamp formats are illustrated in the following 196 figures. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Nanoseconds | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 2: 32-bit Timestamp Format based on PTP [IEEE1588] 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Seconds | Fraction | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 3: NTP [RFC5905] 32-bit Timestamp Format 214 4. Context Allocation and Control Plane Considerations 216 The context header allocations specified in this document are one of 217 many possible allocation schemes and should be used as a guideline 218 only; that is to say these allocations may vary based upon deployment 219 specifics and use cases. The suggested allocation is valid with or 220 without a control plane but the semantics of context values MUST be 221 shared amongst participating nodes via some mechanism. The actual 222 method of defining and distributing the allocation scheme is outside 223 of the scope of this document. 225 5. Security Considerations 227 This document describes an allocation scheme for the metadata carried 228 within the NSH Fixed Length Context Header. This allocation includes 229 a number of identifiers that must be distributed to participating 230 network elements. While the control plane protocols for distributing 231 these identifiers is outside the scope of this document, any control 232 plane protocol should ensure that these identifiers are securely 233 distributed to the network elements participating in the SFC. 235 Additionally, many of the fields such as Source and Destination Class 236 described in the metadata directly impact the network policy applied 237 to the traffic flowing through the SFC. There is a risk that these 238 identifiers may be spoofed and proper precautions should be put in 239 place to ensure that these fields can only be updated by trusted 240 entities. Due to the importance of these fields, confidentiality may 241 also be required to ensure that traffic cannot be targeted for attack 242 based on the policy identifiers. This document does not directly 243 address these threats but provides input to the NSH specification as 244 requirements to be considered in securing the contents of the 245 metadata. 247 6. Contributors 249 This WG document originated as draft-guichard-sfc-nsh-dc-allocation; 250 the following are its coauthors and contributors along with their 251 respective affiliations at the time of WG adoption. These coauthors 252 and contributors provided invaluable content for this document's 253 creation. 255 Kevin Glavin, Riverbed Technology, Inc. 257 Youcef Laribi, Citrix 259 Puneet Agarwal, Broadcom 261 7. Acknowledgments 263 The authors would like to thank Mohamed Boucadair for his helpful 264 review and comments. 266 8. IANA Considerations 268 This document includes no request to IANA. 270 9. References 272 9.1. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 [RFC6759] Claise, B., Aitken, P., and N. Ben-Dvora, "Cisco Systems 280 Export of Application Information in IP Flow Information 281 Export (IPFIX)", RFC 6759, DOI 10.17487/RFC6759, November 282 2012, . 284 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 285 Chaining (SFC) Architecture", RFC 7665, 286 DOI 10.17487/RFC7665, October 2015, 287 . 289 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 290 "Network Service Header (NSH)", RFC 8300, 291 DOI 10.17487/RFC8300, January 2018, 292 . 294 9.2. Informative References 296 [I-D.ietf-sfc-dc-use-cases] 297 Kumar, S., Tufail, M., Majee, S., Captari, C., and S. 298 Homma, "Service Function Chaining Use Cases In Data 299 Centers", draft-ietf-sfc-dc-use-cases-06 (work in 300 progress), February 2017. 302 [I-D.mizrahi-intarea-packet-timestamps] 303 Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 304 Defining Packet Timestamps", draft-mizrahi-intarea-packet- 305 timestamps-01 (work in progress), September 2017. 307 [IEEE1588] 308 IEEE, "IEEE 1588 Standard for a Precision Clock 309 Synchronization Protocol for Networked Measurement and 310 Control Systems Version 2", 2008. 312 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 313 "Network Time Protocol Version 4: Protocol and Algorithms 314 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 315 . 317 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 318 Service Function Chaining", RFC 7498, 319 DOI 10.17487/RFC7498, April 2015, 320 . 322 Authors' Addresses 323 Jim Guichard (editor) 324 Huawei Technologies 326 Email: james.n.guichard@huawei.com 328 Michael Smith 329 Cisco Systems, Inc. 331 Email: michsmit@cisco.com 333 Surendra Kumar 334 Cisco Systems, Inc. 336 Email: smkumar@cisco.com 338 Sumandra Majee 339 F5 Networks 340 90 Rio Robles 341 San Jose, CA 95134 343 Email: S.Majee@f5.com 345 Tal Mizrahi 346 Marvell 348 Email: tal.mizrahi.phd@gmail.com