idnits 2.17.1 draft-quinn-sfc-nsh-tlv-03.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 (April 24, 2017) is 2558 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: October 26, 2017 Intel 6 S. Majee 7 F5 8 April 24, 2017 10 Network Service Header TLVs 11 draft-quinn-sfc-nsh-tlv-03.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 October 26, 2017. 35 Copyright Notice 37 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . 6 56 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 60 7.2. Informative References . . . . . . . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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 4. Security Considerations 253 NSH describes the requisite security considerations for protecting 254 NSH metadata. 256 5. Acknowledgments 258 The authors would like to thank Behcet Sarikaya, Dirk von Hugo and 259 Mohamed Boucadair for their work regarding usage of subscriber and 260 host information TLVs. 262 6. IANA Considerations 264 IANA is requested to create a new "Network Service Header (NSH) TLV 265 Type" registry. TLV types 0-127 are specified in this document. New 266 values are assigned via Standards Action [RFC5226]. 268 7. References 270 7.1. Normative References 272 [NSH] Quinn, P., Ed. and U. Elzur, Ed., "Network Service 273 Header", 2016, . 276 7.2. Informative References 278 [GROUPBASEDPOLICY] 279 OpenStack, "Group Based Policy", 2014, 280 . 282 [GROUPPOLICY] 283 OpenDaylight, "Group Policy", 2014, 284 . 286 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 287 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 288 DOI 10.17487/RFC5226, May 2008, 289 . 291 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 292 "IPv6 Flow Label Specification", RFC 6437, 293 DOI 10.17487/RFC6437, November 2011, 294 . 296 Authors' Addresses 298 Paul Quinn 299 Cisco Systems, Inc. 301 Email: paulq@cisco.com 303 Uri Elzur 304 Intel 306 Email: uri.elzur@intel.com 307 Sumandra Majee 308 F5 310 Email: S.Majee@F5.com