idnits 2.17.1 draft-sarikaya-sfc-metadatat1t2-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 : ---------------------------------------------------------------------------- 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 (January 12, 2017) is 2661 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 326, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-sfc-use-cases' is defined on line 362, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-10 == Outdated reference: A later version (-07) exists of draft-browne-sfc-nsh-kpi-stamp-00 == Outdated reference: A later version (-07) exists of draft-guichard-sfc-nsh-dc-allocation-05 == Outdated reference: A later version (-06) exists of draft-ietf-sfc-dc-use-cases-05 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-07 == Outdated reference: A later version (-04) exists of draft-napper-sfc-nsh-broadband-allocation-01 == Outdated reference: A later version (-04) exists of draft-quinn-sfc-nsh-tlv-02 == Outdated reference: A later version (-07) exists of draft-sarikaya-sfc-hostid-serviceheader-03 == Outdated reference: A later version (-03) exists of draft-wang-sfc-ns-use-cases-02 == Outdated reference: A later version (-03) exists of draft-wang-sfc-nsh-ns-allocation-02 Summary: 0 errors (**), 0 flaws (~~), 13 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: July 16, 2017 Orange 6 D. von Hugo 7 Telekom Innovation Laboratories 8 January 12, 2017 10 Service Function Chaining Metadata Type 1 and Type 2 11 draft-sarikaya-sfc-metadatat1t2-02.txt 13 Abstract 15 With the definition of service function chain data plane protocol 16 there comes the need to define the context data needed in the service 17 function chain use cases. This document gives an account of all 18 context data defined so far as Network Service Header metadata Type 1 19 and Type 2 context headers. Next, the document discusses the various 20 options that can be taken in standardizing service function chain 21 metadata. 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 July 16, 2017. 40 Copyright Notice 42 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . 3 59 3. Processing Metadata Type 1 and Type 2 . . . . . . . . . . . . 6 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 7.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 1 is composed of a 4-byte base header, 76 4-byte service path header. It contains four mandatory Context 77 Headers, 4-byte each which can be combined into one context header of 78 16 octets in the latest version. For additional metadata that needs 79 to be carried, NSH metadata type 2 is defined. Type 2 metadata is 80 composed of a 4-byte base header carrying Type value of 0x02, 4-byte 81 service path header followed by variable length context headers in 82 the form of metadata class type-length-value or TLV. 84 Optional variable length metadata definition includes 16-bit metadata 85 class and 7-bit type fields. It is an issue if such a long metadata 86 class field is needed and whether the type field length should be 87 increased. 89 Many context headers were proposed by many documents. In this 90 document we survey existing drafts that propose new context metadata 91 and then discuss different options that can be taken to standardize 92 this work. 94 The reader should be familiar with the terms defined in [RFC7665] and 95 [I-D.ietf-sfc-nsh]. 97 2. Context Metadata Definitions 99 [I-D.guichard-sfc-nsh-dc-allocation] addresses metadata allocation 100 that seems to be relevant when NSH is used for SFC within a data 101 center. The use cases that demonstrate the applicability of SFC 102 within a data center environment are described in 103 [I-D.ietf-sfc-dc-use-cases]. 105 This document defines meta data Type 1 for several IDs of Source 106 Node, Source Interface and Tenant. It defines destination and source 107 class to classify the destination and source of the traffic for the 108 purposes of applying policy. It defines Opaque Service Class in the 109 4th word. 111 [I-D.napper-sfc-nsh-broadband-allocation] supports use cases in 112 [I-D.ietf-sfc-use-case-mobility]. 114 This document defines meta data Type 1 with endpoint ID, e.g. for 115 IMSI or MSISDN or wireline subscriber ID with 64-bit length. It also 116 defines ServiceTag to identify that the Service Information field 117 contains information related to the Access Network (AN) for the 118 subscriber. Service information could contain IP-CAN type, QoS 119 class, congestion level, etc. for a 3GPP Radio Access Network (RAN). 120 Context ID field allows the subscriber/endpoint ID field to be 121 scoped. Context ID contains the incoming VRF, VxLAN VNID, VLAN, or 122 policy identifier within which the Subscriber/Endpoint ID field is 123 defined. 125 In addition, the document defines a meta data Type 2 TLV to be 126 associated with 3GPP registry. The intent here is to offer this TLV 127 for the use of 3GPP to extend the meta data to meet the needs of 3GPP 128 use cases. However, it was not stated if 3GPP requested such an 129 allocation. 131 [I-D.wang-sfc-nsh-ns-allocation] addresses the use cases for network 132 security defined in [I-D.wang-sfc-ns-use-cases]. 134 It defines a recommended security context allocation as a meta data 135 Type 1 TLV. It is intended to define session ID, tenant ID, 136 destination/ source class for the logical classification of the 137 destination/ source of the traffic, destination/ source score which 138 contains security classification results for communicating immediate 139 actions and accumulated verdicts to downstream Service Functions. 141 [I-D.wang-sfc-nsh-ns-allocation] also mentions that the security 142 context allocation, although defined as Type 1, it may also form a 143 MD-Type 2 metadata TLV, possibly implying that the sizes of data such 144 as session/ tenant ID, etc. may need to become longer. As a result, 145 they may need to become variable length data as in Type 2 meta data 146 TLVs. This document defines network security allocation specifics, 147 basically explaining the semantics of the metadata they define in the 148 document. 150 [I-D.meng-sfc-nsh-broadband-allocation] defines Type 1 metadata 151 called Broadband Context Allocation support service function chaining 152 in a broadband service provider network. It defines Source Node, 153 Source Interface, User and VLAN IDs. 155 [I-D.sarikaya-sfc-hostid-serviceheader] addresses use cases that 156 require revealing host and/ or subscriber related information to 157 upstream SFs as well as extreme low latency service and ultra-high 158 reliability applications use cases. 160 From the analysed use cases, there comes the need to come up with 161 definition of host, subscriber, slice identifier and service 162 identifier SFC meta data Type 2 TLVs. Apart from defining these 163 TLVs, the document gives details of post processing in various nodes 164 such as ingress/egress border nodes, SFC-aware Service Functions and 165 Proxies. Such post processing is defined as normative behavior. 166 Since host and subscriber identifiers may reveal private information 167 about the host and/or the subscriber, the document also defines 168 normative behavior needed to protect the privacy of the hosts and 169 subscribers in an operator network. 171 [I-D.sarikaya-sfc-hostid-serviceheader] is unique among the documents 172 discussed in this document because it defines the post processing 173 normative behavior related to the host and subscriber identifier meta 174 data Type 2 TLVs. Also the use cases are defined in the same 175 document not as a separate document as in the other cases. 177 [I-D.browne-sfc-nsh-kpi-stamp] addresses monitoring and debugging 178 service chains in terms of application latency and QoS configuration 179 of the flows within a service chain. For that purpose, it introduces 180 key performance indicator (KPI) stamping architecture and several 181 metadata Type 2 meta data. 183 Different from other documents maybe except [I-D.quinn-sfc-nsh-tlv], 184 this document makes full use of metadata Type 2 with Metadata Class 185 and Type fields as in [I-D.ietf-sfc-nsh]. One new MD Class called 186 KPI General Monitoring, stamping types and QoS types, in short KPI is 187 introduced. With this, the document introduces many new Types such 188 as KPI stamping detection, or TSD mode, generic KPI encapsulation or 189 KPI mode, timestamping encapsulation or TS mode, Quality of Service 190 configuration encapsulation or QoS mode. QoS mode encapsulation 191 enables definition of one or more QoS stamps containing QoS Type (QT) 192 and QoS value fields and an E bit to indicate the last egress QoS 193 stamp for a given SF. 195 The new MD Class is used in defining several new metadata Type 2 in 196 the document: Generic NSH KPI Encapsulation (Detection Mode), Generic 197 KPI Encapsulation (Extended Mode), NSH Timestamp Encapsulation 198 (Extended Mode), NSH QoS Configuration Encapsulation (Extended Mode). 199 TSD is proposed to use for KPI anomaly detection. KPI is proposed to 200 use for performance monitoring of service chain issues with respect 201 to QoS configuration and latency. The type TS is proposed for 202 timestamping. The type QoS is proposed for QoS stamping. 204 [I-D.penno-sfc-packet] addresses the problem of sending packets in 205 the reverse direction to the source of the current in-process packet/ 206 flow. It defines SF Reverse Packet Request as Type 1 metadata. This 207 is defined as Version 1 (as opposed to Version 0 of NSH MD-type 1 in 208 [I-D.ietf-sfc-nsh]) with OAM Protocol replacing the next protocol 209 field and with Reverse Packet Request added to the end of mandatory 210 context header octets for SFC as an additional 4-octet for OAM. 212 This document also proposes 5 new metadata on service-path 213 invariants, service-path default, bidirectional clonable, 214 unidirectional clonable and service-function-mastered metadata. 215 Their structure specifics are not specified. 217 [I-D.penno-sfc-packet] gives a detailed explaination of the use of 218 the metadata defined, all the semantic information, pre and post 219 processing details at various nodes. 221 [I-D.quinn-sfc-nsh-tlv] defines NSH metadata Type 2 TLVs such as 222 forwarding context, subscriber/user info, tenant, application ID, 223 content type, ingress network information, flow ID, source and/or 224 destination groups, universal resource identifier (URI). This 225 document defines Metadata Class value of 0x0. Also each TLV defined 226 is given a Type value starting with 0x1. 228 Some of these TLVs are defined in other documents, like App ID, 229 Context ID in [I-D.napper-sfc-nsh-broadband-allocation]. Also for 230 Application ID, even though the document references 231 [I-D.penno-sfc-appid], [I-D.penno-sfc-appid] seems to mean 232 Classification Engine ID and Selector ID for the Application ID. 234 The purpose of [I-D.quinn-sfc-nsh-tlv] is to document syntactic 235 structure of the TLVs for the purpose of setting up a registry of 236 Type 2 metadata. No other additional information about the metadata 237 processing is within the scope of this document. The document 238 mentions no use cases in which the TLVs defined are needed. An 239 implementer will need to refer to other documents to understand the 240 exact behavior for handling those contexts. This document does not 241 define the normative behavior for processing the defined TLVs. This 242 is key for interoperability. 244 [I-D.vallamkonda-sfc-metadata-model] does not define any Type 1 or 245 Type 2 meta data TLVs, viewing such meta data as conveying 246 preprocessing information about the packet, this document attempts to 247 formally define the post processing information. To that end, it 248 defines a vocabulary and information model for metadata. The 249 document gives metadata information model example definitions for 250 routing domain, IP endpoint, flow and traffic policy indication. 252 3. Processing Metadata Type 1 and Type 2 254 Some options are discussed below for processing NSH meta data: 256 1. List the structure of meta data in one single document as a 257 registry. The document is not supposed to contain any post 258 processing information. [I-D.quinn-sfc-nsh-tlv] attempts this 259 choice for some Type 2 meta data. Currently there is no such 260 document for Type 1 meta data. Note that in the case of keeping 261 a registry document, it is not clear how the post processing 262 behavior (normative or optional) will be specified for the meta 263 data. One option is to keep such information in separate 264 document(s). If such a strategy is adopted then the advantages 265 obtained from documenting all TLVs in one document disappear 266 because the implementers would need to consult many documents 267 instead of only one. 269 2. All documents defining new meta data Type 1 and Type 2 meta data 270 are treated individually for standardization. This approach has 271 the advantage of keeping all meta data Type 1 and Type 2 meta 272 data in separate and dedicated documents together with all the 273 information that the implementers may need. This could be a 274 strong positive especially if we consider the fact that the meta 275 data are being defined for very many use cases and scenarios. It 276 is unlikely that one implementer would need to implement a large 277 number of these TLVs, thereby defeating the need for combining 278 them in a single document. 280 3. Together with choice 1 above, while combining all meta data in 281 one document, it could be possible to keep post processing 282 information related to the meta data in separate documents which 283 can be considered individually for standardization. 285 4. Together with choice 2 above, Type 1 meta data can be combined in 286 one document but all Type 2 meta data can be considered 287 individually in separate dedicated documents. 289 A document intended to keep a registry of all meta data can be an 290 informational document. Companion documents defining semantics of 291 Type 1 and Type 2 metadata needs to be standard track in order to 292 take the recommendations on processing the data into effect. 294 Another issue is the importance of Type 1 metadata and Type 2 295 metadata. It seems to be difficult to argue that Type 1 metadata is 296 more important. The metadata defined in 297 [I-D.wang-sfc-nsh-ns-allocation] is a good example as it can be 298 defined either as Type 1 or Type 2. The same considerations could 299 possibly be made for other documents. 301 It is recommended that the metadata defined be given serious 302 consideration as to the merit of the use case that needs the metadata 303 to the Service Function Chaining rather than syntactic considerations 304 of Type 1 or Type 2. 306 4. IANA Considerations 308 None. 310 5. Security Considerations 312 This document does not introduce any security issues. 314 6. Acknowledgements 316 TBD. 318 7. References 320 7.1. Normative References 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 332 Chaining (SFC) Architecture", RFC 7665, 333 DOI 10.17487/RFC7665, October 2015, 334 . 336 7.2. Informative References 338 [I-D.browne-sfc-nsh-kpi-stamp] 339 Browne, R., Chilikin, A., and T. Mizrahi, "Network Service 340 Header KPI Stamping", draft-browne-sfc-nsh-kpi-stamp-00 341 (work in progress), October 2016. 343 [I-D.guichard-sfc-nsh-dc-allocation] 344 Guichard, J., Smith, M., Surendra, S., Majee, S., Agarwal, 345 P., Glavin, K., and Y. Laribi, "Network Service Header 346 (NSH) Context Header Allocation (Data Center)", draft- 347 guichard-sfc-nsh-dc-allocation-05 (work in progress), 348 August 2016. 350 [I-D.ietf-sfc-dc-use-cases] 351 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 352 Homma, "Service Function Chaining Use Cases In Data 353 Centers", draft-ietf-sfc-dc-use-cases-05 (work in 354 progress), August 2016. 356 [I-D.ietf-sfc-use-case-mobility] 357 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 358 J. Uttaro, "Service Function Chaining Use Cases in Mobile 359 Networks", draft-ietf-sfc-use-case-mobility-07 (work in 360 progress), October 2016. 362 [I-D.liu-sfc-use-cases] 363 Will, W., Li, H., Huang, O., Boucadair, M., Leymann, N., 364 Qiao, F., Qiong, Q., Pham, C., Huang, C., Zhu, J., and P. 365 He, "Service Function Chaining (SFC) General Use Cases", 366 draft-liu-sfc-use-cases-08 (work in progress), September 367 2014. 369 [I-D.meng-sfc-nsh-broadband-allocation] 370 Meng, W. and C. Wang, "NSH Context Header - Broadband", 371 draft-meng-sfc-nsh-broadband-allocation-01 (work in 372 progress), May 2016. 374 [I-D.napper-sfc-nsh-broadband-allocation] 375 Napper, J., Surendra, S., Muley, P., and W. Henderickx, 376 "NSH Context Header Allocation -- Broadband", draft- 377 napper-sfc-nsh-broadband-allocation-01 (work in progress), 378 October 2016. 380 [I-D.penno-sfc-appid] 381 Penno, R., Claise, B., Pignataro, C., and C. Fontaine, 382 "Using Application Identification in Services Function 383 Chaining Metadata", draft-penno-sfc-appid-05 (work in 384 progress), August 2016. 386 [I-D.penno-sfc-packet] 387 Penno, R., Pignataro, C., Yen, C., Wang, E., Leung, K., 388 and D. Dolson, "Packet Generation in Service Function 389 Chains", draft-penno-sfc-packet-03 (work in progress), 390 April 2016. 392 [I-D.quinn-sfc-nsh-tlv] 393 Quinn, P., Elzur, U., Majee, S., and J. Halpern, "Network 394 Service Header TLVs", draft-quinn-sfc-nsh-tlv-02 (work in 395 progress), October 2016. 397 [I-D.sarikaya-sfc-hostid-serviceheader] 398 Boucadair, M., Hugo, D., and B. Sarikaya, "Service 399 Function Chaining Service, Subscriber and Host 400 Identification Use Cases and Metadata", draft-sarikaya- 401 sfc-hostid-serviceheader-03 (work in progress), July 2016. 403 [I-D.vallamkonda-sfc-metadata-model] 404 sunilvk@f5.com, s., Dunbar, L., and D. Dolson, "A 405 Framework for SFC Metadata", draft-vallamkonda-sfc- 406 metadata-model-01 (work in progress), July 2016. 408 [I-D.wang-sfc-ns-use-cases] 409 Wang, E., Leung, K., Felix, J., and J. Iyer, "Service 410 Function Chaining Use Cases for Network Security", draft- 411 wang-sfc-ns-use-cases-02 (work in progress), October 2016. 413 [I-D.wang-sfc-nsh-ns-allocation] 414 Wang, E., Leung, K., and A. Ossipov, "Network Service 415 Header (NSH) Context Header Allocation (Network 416 Security)", draft-wang-sfc-nsh-ns-allocation-02 (work in 417 progress), November 2016. 419 Authors' Addresses 421 Behcet Sarikaya 422 Huawei 423 5340 Legacy Dr. 424 Plano, TX 75024 426 Email: sarikaya@ieee.org 427 Mohamed Boucadair 428 Orange 429 Rennes 3500, France 431 Email: mohamed.boucadair@orange.com 433 Dirk von Hugo 434 Telekom Innovation Laboratories 435 Deutsche-Telekom-Allee 7 436 D-64295 Darmstadt 437 Germany 439 Email: Dirk.von-Hugo@telekom.de