idnits 2.17.1 draft-ietf-sfc-nsh-tlv-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 13, 2019) is 1568 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) No issues found here. 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 Y. Wei, Ed. 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track P. Quinn 5 Expires: June 15, 2020 Cisco Systems, Inc. 6 U. Elzur 7 Intel 8 S. Majee 9 F5 10 December 13, 2019 12 Network Service Header TLVs 13 draft-ietf-sfc-nsh-tlv-01 15 Abstract 17 This draft describes Network Service Header (NSH) MD-Type 2 metadata 18 TLVs that can be used within a service function path. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 15, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions used in this document . . . . . . . . . . . . . . 3 56 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 3. NSH Type 2 Format . . . . . . . . . . . . . . . . . . . . . . 3 58 4. NSH Type 2 TLVs . . . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. Forwarding Context . . . . . . . . . . . . . . . . . . . 4 60 4.2. Tenant . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.3. Content Type . . . . . . . . . . . . . . . . . . . . . . 5 62 4.4. Ingress Network Information . . . . . . . . . . . . . . . 5 63 4.5. Flow ID . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.6. Source and/or Destination Groups . . . . . . . . . . . . 6 65 4.7. Universal Resource Identifier (URI) . . . . . . . . . . . 6 66 4.8. Policy Identifier (POLICY_ID) . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 8.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Network Service Header [RFC8300] is the SFC encapsulation protocol 78 used to create Service Function Chains. As such, NSH provides two 79 key elements: 81 1. Service Function Path identification 83 2. Metadata 85 NSH further defines two metadata formats (MD Types): 1 and 2. MD 86 Type 1 defines fixed length, 16 byte metadata, whereas MD Type 2 87 defines a variable-length TLV format for metadata. This draft 88 defines some common TLVs for use with NSH MD Type 2. 90 This draft does not address metadata usage, updating/chaining of 91 metadata or other SFP functions. Those topics are described in NSH. 93 2. Conventions used in this document 95 2.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 3. NSH Type 2 Format 105 A NSH is composed of a 4-byte Base Header, a 4-byte Service Path 106 Header and Context Headers. The Base Header identifies the MD-Type 107 in use: 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 |Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next Protocol | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 Figure 1: NSH Base Header 116 Please refer to NSH [RFC8300] for a detailed header description. 118 When the base header specifies MD Type= 0x2, zero or more Variable 119 Length Context Headers MAY be added, immediately following the 120 Service Path Header. Therefore, Length = 0x2, indicates that only 121 the Base Header followed by the Service Path Header are present. The 122 number, indicated in the length field, of optional Variable Length 123 Context Headers MUST be of an integer indicating length in 4-bytes 124 words Figure 2 below depicts the format the context header. 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | TLV Class |C| Type |R|R|R| Len | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Variable Metadata | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 Figure 2: NSH TLV Format 136 4. NSH Type 2 TLVs 138 As per NSH, TLV Class 0-7 are reserved for standards use. In this 139 draft we use TLV Class 0 for the following Types: 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | TLV Class = 0x0 |C| Type |R|R|R| Len | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Variable Metadata | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Figure 3: NSH TLV Class=0x0 149 4.1. Forwarding Context 151 This TLV carries network-centric forwarding context, used for 152 segregation and forwarding scope. Forwarding context can take 153 several forms depending on the network environment. Commonly used 154 data includes VXLAN/VXLAN- GPE VNID, VRF identification or VLAN. 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | TLV Class = 0x0 |C| Type=0x1 |R|R|R| L=0x2 | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 |CT (4)| Reserved | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Tentant ID | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 4: Forwarding Context 166 Context Type (CT), 4 bits: 168 0x0: 24 bit VXLAN/LISP virtual network identifier (VNI) 170 0x1: 32 bit MPLS VPN label 172 0x2: VLAN 174 4.2. Tenant 176 Tenant identification is often used for segregation within a multi- 177 tenant environment. Orchestration system generated tenant IDs are an 178 example of such data. 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | TLV Class = 0x0 |C| Type=0x4 |R|R|R| L=0x3 | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 |TT (4)| Reserved | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Tenant ID | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Tenant ID | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 5: Tenant Identifier 192 Tenant Type (TT), 4 bits: 194 0x0: 32 bit 196 0x1: 64 bit 198 4.3. Content Type 200 Provides explicit information about the content being carried, for 201 example, type of video or content value for billing purposes. 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | TLV Class = 0x0 |C| Type=0x6 |R|R|R| L=0x1 | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Content Type | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 6: Content Type 211 4.4. Ingress Network Information 213 This data identifies ingress network node, and, if required, ingress 214 interface. 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | TLV Class = 0x0 |C| Type=0x7 |R|R|R| L=0x2 | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Node ID | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Source Interface/Port | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 7: Ingress Network Info 226 4.5. Flow ID 228 Flow ID provides a representation of flow. Akin, but not identical 229 to the usage described in [RFC6437]. 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | TLV Class = 0x0 |C| Type=0x8 |R|R|R| L=0x1 | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Flow ID | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 8: Flow ID 239 4.6. Source and/or Destination Groups 241 Intent-based systems can use this data to express the logical 242 grouping of source and/or destination objects. [GROUPBASEDPOLICY] 243 and [GROUPPOLICY] provide examples of such a system. 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | TLV Class = 0x0 |C| Type=0x9 |R|R|R| L=0x3 | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |GT(4) | Reserved | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Source Group | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Dest Group | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 9: End Point Group 257 Group type (4): 259 0x1: Group Based Policy (GBP) end point group (EPG) 261 4.7. Universal Resource Identifier (URI) 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | TLV Class = 0x0 |C| Type=0xA |R|R|R| L=var | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 |UT(4) | URI | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 ~ URI ~ 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 10: Universal Resource Identifier 273 URI type (4): 275 0x1: URI in standard string format as defined in [RFC3986]. 277 0x2: URI represented in a compacted hash format. 279 4.8. Policy Identifier (POLICY_ID) 281 Policy is often referred by a system generated identifier which is 282 then used by the devices to lookup the content of the policy locally. 283 For example this identifier could be an index to an array, a lookup 284 key, a database Id. The identifier allows enforcement agents or 285 services to lookup up the content of their part of the policy quite 286 efficiently. 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | TLV Class = 0x0 |C| Type=0xB |R|R|R| L=0x2 | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | POLICY_ID | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 ~ POLICY_ID ~ 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 11: POLICY_ID 298 5. Security Considerations 300 [RFC8300] describes the requisite security considerations for 301 protecting NSH metadata. 303 6. Acknowledgments 305 The authors would like to thank Behcet Sarikaya, Dirk von Hugo and 306 Mohamed Boucadair for their work regarding usage of subscriber and 307 host information TLVs. 309 7. IANA Considerations 311 IANA is requested to create a new "Network Service Header (NSH) TLV 312 Type" registry. TLV types 0-127 are specified in this document. New 313 values are assigned via Standards Action [RFC8126]. 315 8. References 316 8.1. Normative References 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, 320 DOI 10.17487/RFC2119, March 1997, 321 . 323 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 324 Resource Identifier (URI): Generic Syntax", STD 66, 325 RFC 3986, DOI 10.17487/RFC3986, January 2005, 326 . 328 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 329 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 330 May 2017, . 332 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 333 "Network Service Header (NSH)", RFC 8300, 334 DOI 10.17487/RFC8300, January 2018, 335 . 337 8.2. Informative References 339 [GROUPBASEDPOLICY] 340 OpenStack, "Group Based Policy", 2014. 342 [GROUPPOLICY] 343 OpenDaylight, "Group Policy", 2014. 345 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 346 "IPv6 Flow Label Specification", RFC 6437, 347 DOI 10.17487/RFC6437, November 2011, 348 . 350 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 351 Writing an IANA Considerations Section in RFCs", BCP 26, 352 RFC 8126, DOI 10.17487/RFC8126, June 2017, 353 . 355 Authors' Addresses 357 Yuehua (Corona) Wei (editor) 358 ZTE Corporation 359 No.50, Software Avenue 360 Nanjing 210012 361 P. R. China 363 Email: wei.yuehua@zte.com.cn 364 Paul Quinn 365 Cisco Systems, Inc. 367 Email: paulq@cisco.com 369 Uri Elzur 370 Intel 372 Email: uri.elzur@intel.com 374 Sumandra Majee 375 F5 377 Email: S.Majee@F5.com