idnits 2.17.00 (12 Aug 2021) /tmp/idnits65024/draft-sarikaya-sfc-sfctlvs-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 date (July 7, 2016) is 2137 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-sfc-use-cases' is defined on line 269, but no explicit reference was found in the text == Outdated reference: draft-ietf-sfc-nsh has been published as RFC 8300 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-06 == Outdated reference: A later version (-04) exists of draft-napper-sfc-nsh-broadband-allocation-00 == Outdated reference: A later version (-05) exists of draft-penno-sfc-appid-04 == Outdated reference: A later version (-04) exists of draft-quinn-sfc-nsh-tlv-01 == Outdated reference: A later version (-07) exists of draft-sarikaya-sfc-hostid-serviceheader-03 == Outdated reference: A later version (-01) exists of draft-vallamkonda-sfc-metadata-model-00 == Outdated reference: A later version (-03) exists of draft-wang-sfc-ns-use-cases-01 == Outdated reference: A later version (-03) exists of draft-wang-sfc-nsh-ns-allocation-00 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei 4 Intended status: Informational M. Boucadair 5 Expires: January 8, 2017 Orange 6 D. von Hugo 7 Telekom Innovation Laboratories 8 July 7, 2016 10 Road to the Standardization for Service Function Chaining Metadata Type 11 1 and Type 2 12 draft-sarikaya-sfc-sfctlvs-00.txt 14 Abstract 16 With the definition of service function chain data plane protocol 17 there comes the need to define the context data needed in the service 18 function chain use cases. This document gives an account of all 19 context data defined so far as Network Service Header metadata Type 1 20 and Type 2 context headers. Next, the document discusses the various 21 options that can be made in standardizing these TLVs. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 8, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Context Metadata Definitions . . . . . . . . . . . . . . . . 2 59 3. The Road to Standardization . . . . . . . . . . . . . . . . . 5 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 7.2. Informative References . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 Network Service Header (NSH) [I-D.ietf-sfc-nsh] is the Service 71 Function Chaining (SFC) data plane protocol. The SFC architecture is 72 defined in [RFC7665]. 74 NSH has the function of carrying context data in the form of context 75 header. NSH metadata type 2 carries the optional variable length 76 context header. 78 Many context headers were proposed by many documents. In this 79 document we survey existing drafts that propose new context metadata 80 and then discuss different options that can be taken to standardize 81 this work. 83 The reader should be familiar with the terms defined in [RFC7665] and 84 [I-D.ietf-sfc-nsh]. 86 2. Context Metadata Definitions 88 [I-D.quinn-sfc-nsh-tlv] defines NSH metadata Type 2 TLVs such as 89 forwarding context, subscriber/user info, tenant, application ID, 90 content type, ingress network information, flow ID, source and/or 91 destination groups, universal resource identifier (URI). 93 Some of these TLVs are defined in other documents, like App ID, 94 Context ID in [I-D.napper-sfc-nsh-broadband-allocation]. Also for 95 Application ID, even though the document references 97 [I-D.penno-sfc-appid], [I-D.penno-sfc-appid] seems to mean 98 Classification Engine ID and Selector ID for the Application ID. 100 The purpose of [I-D.quinn-sfc-nsh-tlv] is to document syntactic 101 structure of the TLVs. No other additional information about the 102 metadata processing is within the scope of this document. The 103 document mentions no use cases in which the TLVs defined are needed. 104 An implementer will need to refer to other documents to understand 105 the exact behavior for handling those contexts. 107 [I-D.napper-sfc-nsh-mobility-allocation] addresses the use cases 108 defined in [I-D.ietf-sfc-use-case-mobility]. For this purpose a 109 single TLV is defined called NSH mobility context allocation TLV. 110 This TLV is meta data Type 1 and defines endpoint ID, e.g. for IMSI 111 or MSISDN with 64-bit length and ServiceTag, a 64-bit field 112 containing flow or subscriber identified by the endpoint ID field 113 identifying IP-CAN type, QoS class, congestion level, etc. This 114 document does not define any meta data Type 2. 116 [I-D.napper-sfc-nsh-broadband-allocation] also supports use cases in 117 [I-D.ietf-sfc-use-case-mobility] but seems to address the needs of 118 fixed network as well as mobile networks. 120 This document updates the meta data Type 1 TLV defined in 121 [I-D.napper-sfc-nsh-mobility-allocation] for the wireline subscriber. 122 In addition, it defines a meta data Type 2 TLV to be associated with 123 3GPP registry. The intent here is to offer this TLV for the use of 124 3GPP to extend the meta data to meet the needs of 3GPP use cases. 125 However, it was not stated if 3GPP requested such an allocation. 127 [I-D.wang-sfc-nsh-ns-allocation] addresses the use cases for network 128 security defined in [I-D.wang-sfc-ns-use-cases]. 130 It defines a recommended security context allocation as a meta data 131 Type 1 TLV. It is intended to define session ID, tenant ID, 132 destination/ source class for the logical classification of the 133 destination/ source of the traffic, destination/ source score which 134 contains security classification results for communicating immediate 135 actions and accumulated verdicts to downstream Service Functions. 137 [I-D.wang-sfc-nsh-ns-allocation] also mentions that the security 138 context allocation, although defined as Type 1, it may also form a 139 MD-Type 2 metadata TLV, possibly implying that the sizes of data such 140 as session/ tenant ID, etc. may need to become longer. As a result, 141 they may need to become variable length data as in Type 2 meta data 142 TLVs. 144 [I-D.sarikaya-sfc-hostid-serviceheader] addresses use cases that 145 require revealing host and/ or subscriber related information to 146 upstream SFs as well as extreme low latency service and ultra-high 147 reliability applications use cases. 149 From the analysed use cases, there comes the need to come up with 150 definition of host, subscriber, slice identifier and service 151 identifier SFC meta data Type 2 TLVs. Apart from defining these 152 TLVs, the document gives details of post processing in various nodes 153 such as ingress/egress border nodes, SFC-aware Service Functions and 154 Proxies. Such post processing is defined as normative behavior. 155 Since host and subscriber identifiers may reveal private information 156 about the host and/or the subscriber, the document also defines 157 normative behavior needed to protect the privacy of the hosts and 158 subscribers in an operator network. 160 [I-D.sarikaya-sfc-hostid-serviceheader] is unique among the documents 161 discussed in this document because it defines the post processing 162 normative behavior related to the host and subscriber identifier meta 163 data Type 2 TLVs. Also the use cases are defined in the same 164 document not as a separate document as in the other cases. 166 [I-D.penno-sfc-packet] addresses the problem of sending packets in 167 the reverse direction to the source of the current in-process packet/ 168 flow. It defines SF Reverse Packet Request as Type 1 metadata TLV. 169 This is defined as Version 1 (as opposed to Version 0 of NSH MD-type 170 1 in [I-D.ietf-sfc-nsh]) with OAM Protocol replacing the next 171 protocol field and with Reverse Packet Request added to the end of 172 mandatory context header octets for SFC as an additional 4-octet for 173 OAM. 175 This document also proposes 5 new metadata on service-path 176 invariants, service-path default, bidirectional clonable, 177 unidirectional clonable and service-function-mastered metadata. 178 Their structure specifics are not specified. 180 [I-D.penno-sfc-packet] gives a detailed explaination of the use of 181 the metadata defined, all the semantic information, pre and post 182 processing details at various nodes. 184 [I-D.vallamkonda-sfc-metadata-model] does not define any Type 1 or 185 Type 2 meta data TLVs, viewing such meta data as conveying 186 preprocessing information about the packet, this document attempts to 187 formally defines the post processing information. To that end, it 188 defines a vocabulary and information model for metadata. The 189 document gives metadata information model example definitions for 190 routing domain, IP endpoint, flow and traffic policy indication. 192 3. The Road to Standardization 194 Some options are discussed below for progressing NSH TLVs: 196 1. List the structure of meta data in one single document. The 197 document is not supposed to contain any post processing 198 information. [I-D.quinn-sfc-nsh-tlv] attempts this choice for 199 Type 2 TLVs. Currently there is no such document for Type 1 200 TLVs. Note that in this case it is not clear how the post 201 processing normative behavior will be specified for the TLVs. 202 One option is to keep such information in separate document. If 203 such a strategy is adopted then the advantages obtained from 204 documenting all TLVs in one document disappears because the 205 implementers would need to consult many documents instead of only 206 one. 208 2. Specify an exhaustive list of TLVs in one single document: this 209 approach allows avoiding dependency on other document. 211 3. All documents defining new meta data Type 1 and Type 2 TLVs are 212 treated individually for standardization. This approach has the 213 advantage of keeping all meta data Type 1 and Type 2 TLVs in 214 separate and dedicated documents together with all the 215 information that the implementers may need. This could be a 216 strong positive especially if we consider the fact that the meta 217 data are being defined for very many use cases and scenarios. It 218 is unlikely that one implementer would need to implement a large 219 number of these TLVs, thereby defeating the need for combining 220 them in a single document. 222 4. Together with choice 1 above, while combining all TLVs in one 223 document, it could be possible to keep post processing 224 information related to the meta data can be considered 225 individually for standardization. 227 5. Together with choice 2 above, Type 1 TLVs can combined in one 228 document but all Type 2 TLVs can be considered individually in 229 separate dedicated documents. 231 4. IANA Considerations 233 None. 235 5. Security Considerations 237 This document does not introduce any security issues. 239 6. Acknowledgements 241 TBD. 243 7. References 245 7.1. Normative References 247 [I-D.ietf-sfc-nsh] 248 Quinn, P. and U. Elzur, "Network Service Header", draft- 249 ietf-sfc-nsh-05 (work in progress), May 2016. 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, 253 DOI 10.17487/RFC2119, March 1997, 254 . 256 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 257 Chaining (SFC) Architecture", RFC 7665, 258 DOI 10.17487/RFC7665, October 2015, 259 . 261 7.2. Informative References 263 [I-D.ietf-sfc-use-case-mobility] 264 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 265 J. Uttaro, "Service Function Chaining Use Cases in Mobile 266 Networks", draft-ietf-sfc-use-case-mobility-06 (work in 267 progress), April 2016. 269 [I-D.liu-sfc-use-cases] 270 Will, W., Li, H., Huang, O., Boucadair, M., Leymann, N., 271 Qiao, F., Qiong, Q., Pham, C., Huang, C., Zhu, J., and P. 272 He, "Service Function Chaining (SFC) General Use Cases", 273 draft-liu-sfc-use-cases-08 (work in progress), September 274 2014. 276 [I-D.napper-sfc-nsh-broadband-allocation] 277 Napper, J., Surendra, S., Muley, P., and W. Henderickx, 278 "NSH Context Header Allocation -- Broadband", draft- 279 napper-sfc-nsh-broadband-allocation-00 (work in progress), 280 March 2016. 282 [I-D.napper-sfc-nsh-mobility-allocation] 283 Napper, J., Surendra, S., Muley, P., and W. Henderickx, 284 "NSH Context Header Allocation -- Mobility", draft-napper- 285 sfc-nsh-mobility-allocation-02 (work in progress), 286 November 2015. 288 [I-D.penno-sfc-appid] 289 Penno, R., Claise, B., Pignataro, C., and C. Fontaine, 290 "Using Application Identification in Services Function 291 Chaining Metadata", draft-penno-sfc-appid-04 (work in 292 progress), June 2016. 294 [I-D.penno-sfc-packet] 295 Penno, R., Pignataro, C., Yen, C., Wang, E., Leung, K., 296 and D. Dolson, "Packet Generation in Service Function 297 Chains", draft-penno-sfc-packet-03 (work in progress), 298 April 2016. 300 [I-D.quinn-sfc-nsh-tlv] 301 Quinn, P., Elzur, U., Majee, S., and J. Halpern, "Network 302 Service Header TLVs", draft-quinn-sfc-nsh-tlv-01 (work in 303 progress), April 2016. 305 [I-D.sarikaya-sfc-hostid-serviceheader] 306 Boucadair, M., Hugo, D., and B. Sarikaya, "Service 307 Function Chaining Service, Subscriber and Host 308 Identification Use Cases and Metadata", draft-sarikaya- 309 sfc-hostid-serviceheader-03 (work in progress), July 2016. 311 [I-D.vallamkonda-sfc-metadata-model] 312 sunilvk@f5.com, s. and D. Dolson, "Information Model for 313 SFC Metadata", draft-vallamkonda-sfc-metadata-model-00 314 (work in progress), January 2016. 316 [I-D.wang-sfc-ns-use-cases] 317 Wang, E., Leung, K., Felix, J., and J. Iyer, "Service 318 Function Chaining Use Cases for Network Security", draft- 319 wang-sfc-ns-use-cases-01 (work in progress), March 2016. 321 [I-D.wang-sfc-nsh-ns-allocation] 322 Wang, E. and K. Leung, "Network Service Header (NSH) 323 Context Header Allocation (Network Security)", draft-wang- 324 sfc-nsh-ns-allocation-00 (work in progress), May 2016. 326 Authors' Addresses 328 Behcet Sarikaya 329 Huawei 330 5340 Legacy Dr. 331 Plano, TX 75024 333 Email: sarikaya@ieee.org 334 Mohamed Boucadair 335 Orange 336 Rennes 3500, France 338 Email: mohamed.boucadair@orange.com 340 Dirk von Hugo 341 Telekom Innovation Laboratories 342 Deutsche-Telekom-Allee 7 343 D-64295 Darmstadt 344 Germany 346 Email: Dirk.von-Hugo@telekom.de