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