idnits 2.17.1 draft-ietf-sfc-nsh-tlv-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 97: '... Context Headers MAY be added, immedia...' RFC 2119 keyword, line 101: '... Context Headers MUST be of an integer...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 29, 2018) is 2272 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'NSH' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Quinn 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track U. Elzur 5 Expires: August 2, 2018 Intel 6 S. Majee 7 F5 8 January 29, 2018 10 Network Service Header TLVs 11 draft-ietf-sfc-nsh-tlv-00.txt 13 Abstract 15 This draft describes Network Service Header (NSH) MD-Type 2 metadata 16 TLVs that can be used within a service function path. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 2, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. NSH Type 2 Format . . . . . . . . . . . . . . . . . . . . . . 2 54 3. NSH Type 2 TLVs . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 56 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 60 7.2. Informative References . . . . . . . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 Network Service Header [NSH] is the SFC encapsulation protocol used 66 to create Service Function Chains. As such, NSH provides two key 67 elements: 69 1. Service Function Path identification 71 2. Metadata 73 NSH further defines two metadata formats (MD Types): 1 and 2. MD 74 Type 1 defines fixed length, 16 byte metadata, whereas MD Type 2 75 defines a variable-length TLV format for metadata. This draft 76 defines some common TLVs for use with NSH MD Type 2. 78 This draft does not address metadata usage, updating/chaining of 79 metadata or other SFP functions. Those topics are described in NSH. 81 2. NSH Type 2 Format 83 A NSH is composed of a 4-byte Base Header, a 4-byte Service Path 84 Header and Context Headers. The Base Header identifies the MD-Type 85 in use: 87 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 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 |Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next Protocol | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 Figure 1: NSH Base Header 94 Please refer to NSH [NSH] for a detailed header description. 96 When the base header specifies MD Type= 0x2, zero or more Variable 97 Length Context Headers MAY be added, immediately following the 98 Service Path Header. Therefore, Length = 0x2, indicates that only 99 the Base Header followed by the Service Path Header are present. The 100 number, indicated in the length field, of optional Variable Length 101 Context Headers MUST be of an integer indicating length in 4-bytes 102 words Figure 3 below depicts the format the context header. 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | TLV Class |C| Type |R|R|R| Len | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Variable Metadata | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 Figure 2: NSH TLV Format 114 3. NSH Type 2 TLVs 116 As per NSH, TLV Class 0-7 are reserved for standards use. In this 117 draft we use TLV Class 0 for the following Types: 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | TLV Class = 0x0 |C| Type |R|R|R| Len | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Variable Metadata | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Figure 3: NSH TLV Class=0x0 127 1. Forwarding Context 129 This TLV carries network-centric forwarding context, used for 130 segregation and forwarding scope. Forwarding context can take 131 several forms depending on the network environment. Commonly 132 used data includes VXLAN/VXLAN- GPE VNID, VRF identification or 133 VLAN. 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | TLV Class = 0x0 |C| Type=0x1 |R|R|R| L=0x2 | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |CT (4)| Reserved | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Tentant ID | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Context Type (CT), 4 bits: 144 0x0: 24 bit VXLAN/LISP virtual network identifier (VNI) 145 0x1: 32 bit MPLS VPN label 146 0x2: VLAN 148 Figure 4: Forwarding Context 150 2. Tenant 152 Tenant identification is often used for segregation within a 153 multi-tenant environment. Orchestration system generated tenant 154 IDs are an example of such data. 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | TLV Class = 0x0 |C| Type=0x4 |R|R|R| L=0x3 | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 |TT (4)| Reserved | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Tenant ID | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Tenant ID | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Tenant Type (TT), 4 bits: 167 0x0: 32 bit 168 0x1: 64 bit 170 Figure 5: Tenant Identifier 172 3. Content Type 174 Provides explicit information about the content being carried, 175 for example, type of video or content value for billing purposes 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | TLV Class = 0x0 |C| Type=0x6 |R|R|R| L=0x1 | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Content Type | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Figure 6: Content Type 185 4. Ingress Network Information 187 This data identifies ingress network node, and, if required, 188 ingress interface. 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | TLV Class = 0x0 |C| Type=0x7 |R|R|R| L=0x2 | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Node ID | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Source Interface/Port | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 7: Ingress Network Info 200 5. Flow ID 202 Flow ID provides a representation of flow. Akin, but not 203 identical to the usage described in [RFC6437] 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | TLV Class = 0x0 |C| Type=0x8 |R|R|R| L=0x1 | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Flow ID | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Figure 8: Flow ID 213 6. Source and/or Destination Groups 215 Intent-based systems can use this data to express the logical 216 grouping of source and/or destination objects. 217 [GROUPBASEDPOLICY] and [GROUPPOLICY] provide examples of such a 218 system. 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | TLV Class = 0x0 |C| Type=0x9 |R|R|R| L=0x3 | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |GT(4) | Reserved | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Source Group | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Dest Group | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Group type (4): 231 0x1: Group Based Policy (GBP) end point group (EPG) 233 Figure 9: End Point Group 235 7. Universal Resource Identifier (URI) 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | TLV Class = 0x0 |C| Type=0xA |R|R|R| L=var | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 |UT(4) | URI | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 ~ URI ~ 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 URI type (4): 246 0x1: URI in standard string format as defined in RFC 3986 247 0x2: URI represented in a compacted hash format 249 Figure 10: URI 251 8. Policy Identifier (POLICY_ID) 253 Policy is often referred by a system generated identifier which 254 is then used by the devices to lookup the content of the policy 255 locally. For example this identifier could be an index to an 256 array, a lookup key, a database Id. The identifier allows 257 enforcement agents or services to lookup up the content of their 258 part of the policy quite efficiently. 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | TLV Class = 0x0 |C| Type=0xB |R|R|R| L=0x2 | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | POLICY_ID | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 ~ POLICY_ID ~ 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 11: POLICY_ID 270 4. Security Considerations 272 NSH describes the requisite security considerations for protecting 273 NSH metadata. 275 5. Acknowledgments 277 The authors would like to thank Behcet Sarikaya, Dirk von Hugo and 278 Mohamed Boucadair for their work regarding usage of subscriber and 279 host information TLVs. 281 6. IANA Considerations 283 IANA is requested to create a new "Network Service Header (NSH) TLV 284 Type" registry. TLV types 0-127 are specified in this document. New 285 values are assigned via Standards Action [RFC5226]. 287 7. References 289 7.1. Normative References 291 [NSH] Quinn, P., Ed. and U. Elzur, Ed., "Network Service 292 Header", 2016, . 295 7.2. Informative References 297 [GROUPBASEDPOLICY] 298 OpenStack, "Group Based Policy", 2014, 299 . 301 [GROUPPOLICY] 302 OpenDaylight, "Group Policy", 2014, 303 . 305 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 306 IANA Considerations Section in RFCs", RFC 5226, 307 DOI 10.17487/RFC5226, May 2008, . 310 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 311 "IPv6 Flow Label Specification", RFC 6437, 312 DOI 10.17487/RFC6437, November 2011, . 315 Authors' Addresses 317 Paul Quinn 318 Cisco Systems, Inc. 320 Email: paulq@cisco.com 322 Uri Elzur 323 Intel 325 Email: uri.elzur@intel.com 327 Sumandra Majee 328 F5 330 Email: S.Majee@F5.com