idnits 2.17.1 draft-wang-sfc-md-type-issues-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 : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 23 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2016) is 2741 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) ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-07) exists of draft-guichard-sfc-nsh-dc-allocation-05 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-10 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG C. Wang 3 Internet-Draft W. Meng 4 Intended status: Standards Track ZTE Corporation 5 Expires: April 27, 2017 October 24, 2016 7 Metadata Type Issues 8 draft-wang-sfc-md-type-issues-02 10 Abstract 12 Service function chain is the definition of an ordered set of service 13 functions. After instantiated, the service function path is created 14 and the classified traffic is steered through the corresponding 15 service function path and then forwarded to the final destination. 16 Metadata (MD) is conveyed in SFC data plane which provides the 17 ability to exchange context information between classifiers and SFs, 18 among SFs, and between external systems and SFs. This document is 19 motivated to state an issue when MD Type = 0x1. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 27, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Convention and Terminology . . . . . . . . . . . . . . . . . 3 57 3. An issue in MD-Type = 0x1 . . . . . . . . . . . . . . . . . . 4 58 4. An analysis on how to solve above issue . . . . . . . . . . . 6 59 4.1. Method 1 . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Method 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 8.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 Service function chain is the definition of an ordered set of service 72 functions. After instantiated, the service function path is created 73 and the classified traffic is steered through the corresponding 74 service function path and then forwarded to the final destination. 76 Metadata is conveyed in the Context Headers in SFC data plane which 77 provides the ability to exchange context information between 78 classifiers and SFs, among SFs, and between external systems and SFs. 79 In [I-D.ietf-sfc-nsh], it defines two mandate parts including Base 80 Header and Service Path Header in NSH header. Besides these two 81 parts, there are Contexts Headers immediately following the Service 82 Path Header as well. As for what kinds of Contexts Headers is 83 according to the MD Type specified in the Base Header. In fact, it 84 defines two MD types: 86 When the Base Header specifies MD Type = 0x1, four Mandatory Context 87 Headers must be added immediately following the Service Path Header, 88 as per Figure 1. 90 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 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | Service Path ID | Service Index | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | Mandatory Context Header | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | Mandatory Context Header | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Mandatory Context Header | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Mandatory Context Header | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 Figure 1: NSH Format when MD Type = 0x1 107 When the Base Header specifies MD Type = 0x2, zero or more Variable 108 Length Context Headers MAY be added immediately following the Service 109 Path Header, as per Figure 2. 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x2 | Next Protocol | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Service Path ID | Service Index | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | | 118 ~ Variable Length Context Headers (opt.) ~ 119 | | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 Figure 2: NSH Format when MD Type = 0x2 124 From the perspective in [I-D.ietf-sfc-nsh] and its companion drafts, 125 it seems to be apt to support MD Type = 0x1 to be mandate. 127 This document is motivated to state an issue when MD Type = 0x1 is 128 mandate and discuss which Metadata Type in more appropriate in what 129 circumstances in SFC data plane. 131 2. Convention and Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 The terms are all defined in [RFC7665] and [I-D.ietf-sfc-nsh]. 139 3. An issue in MD-Type = 0x1 141 In [I-D.guichard-sfc-nsh-dc-allocation], it provides the allocation 142 scheme when Network Service Header (NSH) is used under data center 143 scenario and defines a recommended default allocation for the 144 Mandatory Context Headers while MD-Type = 0x1 (See Figure 3 below). 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Service Path ID | Service Index | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 |D|F|Res| Source Node ID | Source Interface ID | Context Header 1 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Reserved | Tenant ID | Context Header 2 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Destination Class / Reserved | Source Class | Context Header 3 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | ServiceTag / Opaque Service Class | Context Header 4 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 3: NSH DC Context Allocation 163 What's more, in [I-D.napper-sfc-nsh-mobility-allocation] , it 164 provides the allocation scheme when Network Service Header (NSH) is 165 used under mobility scenario and defines a recommended default 166 allocation for the Mandatory Context Headers while MD-Type = 0x1 (See 167 Figure 4 below). 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Service Path ID | Service Index | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Flow Cookie | Context Header 1 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Reserv |TenTy| Tenant ID | Context Header 2 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Sub/App ID ~ Context Header 3 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 ~ Sub/App ID (cont.) | Context Header 4 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 4: NSH Mobility Context Header 186 There is no issue while the data center scenario and mobility 187 scenario are deployed separately. For example, SFs in data centers 188 can identify the exactly meaning in the Mandatory Context Headers 189 according to the definition in [I-D.guichard-sfc-nsh-dc-allocation], 190 while SFs in mobility service provider can understand the exactly 191 meaning in the Mandatory Context Headers according to the definition 192 in [I-D.napper-sfc-nsh-mobility-allocation]. 194 But it is possible that there is a mixed need, such as Data Centers 195 providing both wireless and classic DC services. Under this mixed 196 scenario, there seems to be some difficulty when SFs tries to analyze 197 the Mandatory Context Headers while MD Type = 0x1. 199 For example, in Figure 5, it illustrates the mixed scenario where a 200 data center provides both wireless and classic DC services. And in 201 this data center, a service function (such as SF3) serves both 202 wireless and classic DC services. 204 .--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--. 205 ( DC serving both wireless and classic DC services ) 206 ( ) 207 Claasic DC incoming traffic( +-----+ +-----+ +-----+ ) 208 ------->-------------> ---(---> | SF1 |----->| SF2 |------>\ /--->-- | SF4 |----->----)-----> 209 ( +-----+ +-----+ \ / +-----+ ) 210 ( +--|--+ ) 211 ( | SF3 | ) 212 ( +--|--+ ) 213 Wireless incoming traffic( +-----+ +-----+ / \ +-----+ ) 214 -------> ------------> ---(---->| SF5 |----->| SF6 |------>/ \--->-- | SF7 |----->----)-----> 215 ( +-----+ +-----+ +-----+ ) 216 ( ) 217 .--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--. 219 Figure 5: DC serving both wireless and classic DC services 221 When traffic is steered to SF3, how SF3 to correctly analyze the 222 Mandatory Context Headers in NSH within the arriving traffic? In 223 other words, how SF3 in this mixed environments to know the receiving 224 Mandatory Context Headers in the NSH are used for wireless service or 225 classic DC services? 227 4. An analysis on how to solve above issue 229 There may be several methods to address the above issue. Here just 230 tries to list two feasible methods. 232 4.1. Method 1 234 Still using the recommended definition in draft-dc and draft-mobility 235 while MD Type = 0x1, but tries to add some bits in NSH to identify 236 what type of Mandatory Context Headers is conveyed within NSH. For 237 example, as per Figure 6, here occupies the lowest two bits in MD 238 Type field to identify the exact type of Mandatory Context Headers. 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |Ver|O|C|R|R|R|R|R|R| Length |MD-type=0x1| T | Next Protocol | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Service Path ID | Service Index | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Mandatory Context Header | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Mandatory Context Header | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Mandatory Context Header | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Mandatory Context Header | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 6: Two bits in MD Type field 257 In fact, this issue only exists while MD Type = 0x1. While MD Type = 258 0x2, there is no such issue. So these added two bits have no meaning 259 while MD Type = 0x2. 261 When traffic is steered to SF3, SF3 finds the MD Type = 0x1 and then 262 analyze these added two bits to know what kind of Mandatory Context 263 Headers is contained. After that, correctly analyze the following 264 Mandatory Context Headers according to the type. 266 4.2. Method 2 268 It also may be a feasible method to use MD Type = 0x2 to identify the 269 Context Headers. According to MD Type = 0x2, the exact format for 270 Variable Length Context Headers is illustrated in Figure 7, which 271 states the TLV Class field or Type field already. Then, no matter in 272 separated scenarios or mixed scenarios, there is no confusion when 273 traffic arrives at SFs. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | TLV Class |C| Type |R|R|R| Len | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Variable Metadata | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 7: Variable Length Context Headers when MD Type = 0x2 285 5. Gap analysis 287 This document tries to raise one issue when using MD Type = 0x1 as 288 mandatory type. As for which MD Type need to be mandatory there 289 still need much more attentions and discussions. 291 6. Security Considerations 293 TBD 295 7. IANA Considerations 297 TBD 299 8. References 301 8.1. Normative References 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, 305 DOI 10.17487/RFC2119, March 1997, 306 . 308 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 309 Chaining (SFC) Architecture", RFC 7665, 310 DOI 10.17487/RFC7665, October 2015, 311 . 313 8.2. Informative References 315 [I-D.guichard-sfc-nsh-dc-allocation] 316 Guichard, J., Smith, M., Surendra, S., Majee, S., Agarwal, 317 P., Glavin, K., and Y. Laribi, "Network Service Header 318 (NSH) Context Header Allocation (Data Center)", draft- 319 guichard-sfc-nsh-dc-allocation-05 (work in progress), 320 August 2016. 322 [I-D.ietf-sfc-nsh] 323 Quinn, P. and U. Elzur, "Network Service Header", draft- 324 ietf-sfc-nsh-10 (work in progress), September 2016. 326 [I-D.napper-sfc-nsh-mobility-allocation] 327 Napper, J., Surendra, S., Muley, P., and W. Henderickx, 328 "NSH Context Header Allocation -- Mobility", draft-napper- 329 sfc-nsh-mobility-allocation-02 (work in progress), 330 November 2015. 332 Authors' Addresses 334 Cui Wang 335 ZTE Corporation 336 No.50 Software Avenue, Yuhuatai District 337 Nanjing 338 China 340 Email: wang.cui1@zte.com.cn 342 Wei Meng 343 ZTE Corporation 344 No.50 Software Avenue, Yuhuatai District 345 Nanjing 346 China 348 Email: meng.wei2@zte.com.cn,vally.meng@gmail.com