Network Working Group B. Sarikaya Internet-Draft Huawei Intended status: Informational M. Boucadair Expires: January 8, 2017 Orange D. von Hugo Telekom Innovation Laboratories July 7, 2016 Road to the Standardization for Service Function Chaining Metadata Type 1 and Type 2 draft-sarikaya-sfc-sfctlvs-00.txt Abstract With the definition of service function chain data plane protocol there comes the need to define the context data needed in the service function chain use cases. This document gives an account of all context data defined so far as Network Service Header metadata Type 1 and Type 2 context headers. Next, the document discusses the various options that can be made in standardizing these TLVs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 8, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Sarikaya, et al. Expires January 8, 2017 [Page 1] Internet-Draft TLVs in SFC July 2016 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Context Metadata Definitions . . . . . . . . . . . . . . . . 2 3. The Road to Standardization . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Network Service Header (NSH) [I-D.ietf-sfc-nsh] is the Service Function Chaining (SFC) data plane protocol. The SFC architecture is defined in [RFC7665]. NSH has the function of carrying context data in the form of context header. NSH metadata type 2 carries the optional variable length context header. Many context headers were proposed by many documents. In this document we survey existing drafts that propose new context metadata and then discuss different options that can be taken to standardize this work. The reader should be familiar with the terms defined in [RFC7665] and [I-D.ietf-sfc-nsh]. 2. Context Metadata Definitions [I-D.quinn-sfc-nsh-tlv] defines NSH metadata Type 2 TLVs such as forwarding context, subscriber/user info, tenant, application ID, content type, ingress network information, flow ID, source and/or destination groups, universal resource identifier (URI). Some of these TLVs are defined in other documents, like App ID, Context ID in [I-D.napper-sfc-nsh-broadband-allocation]. Also for Application ID, even though the document references Sarikaya, et al. Expires January 8, 2017 [Page 2] Internet-Draft TLVs in SFC July 2016 [I-D.penno-sfc-appid], [I-D.penno-sfc-appid] seems to mean Classification Engine ID and Selector ID for the Application ID. The purpose of [I-D.quinn-sfc-nsh-tlv] is to document syntactic structure of the TLVs. No other additional information about the metadata processing is within the scope of this document. The document mentions no use cases in which the TLVs defined are needed. An implementer will need to refer to other documents to understand the exact behavior for handling those contexts. [I-D.napper-sfc-nsh-mobility-allocation] addresses the use cases defined in [I-D.ietf-sfc-use-case-mobility]. For this purpose a single TLV is defined called NSH mobility context allocation TLV. This TLV is meta data Type 1 and defines endpoint ID, e.g. for IMSI or MSISDN with 64-bit length and ServiceTag, a 64-bit field containing flow or subscriber identified by the endpoint ID field identifying IP-CAN type, QoS class, congestion level, etc. This document does not define any meta data Type 2. [I-D.napper-sfc-nsh-broadband-allocation] also supports use cases in [I-D.ietf-sfc-use-case-mobility] but seems to address the needs of fixed network as well as mobile networks. This document updates the meta data Type 1 TLV defined in [I-D.napper-sfc-nsh-mobility-allocation] for the wireline subscriber. In addition, it defines a meta data Type 2 TLV to be associated with 3GPP registry. The intent here is to offer this TLV for the use of 3GPP to extend the meta data to meet the needs of 3GPP use cases. However, it was not stated if 3GPP requested such an allocation. [I-D.wang-sfc-nsh-ns-allocation] addresses the use cases for network security defined in [I-D.wang-sfc-ns-use-cases]. It defines a recommended security context allocation as a meta data Type 1 TLV. It is intended to define session ID, tenant ID, destination/ source class for the logical classification of the destination/ source of the traffic, destination/ source score which contains security classification results for communicating immediate actions and accumulated verdicts to downstream Service Functions. [I-D.wang-sfc-nsh-ns-allocation] also mentions that the security context allocation, although defined as Type 1, it may also form a MD-Type 2 metadata TLV, possibly implying that the sizes of data such as session/ tenant ID, etc. may need to become longer. As a result, they may need to become variable length data as in Type 2 meta data TLVs. Sarikaya, et al. Expires January 8, 2017 [Page 3] Internet-Draft TLVs in SFC July 2016 [I-D.sarikaya-sfc-hostid-serviceheader] addresses use cases that require revealing host and/ or subscriber related information to upstream SFs as well as extreme low latency service and ultra-high reliability applications use cases. From the analysed use cases, there comes the need to come up with definition of host, subscriber, slice identifier and service identifier SFC meta data Type 2 TLVs. Apart from defining these TLVs, the document gives details of post processing in various nodes such as ingress/egress border nodes, SFC-aware Service Functions and Proxies. Such post processing is defined as normative behavior. Since host and subscriber identifiers may reveal private information about the host and/or the subscriber, the document also defines normative behavior needed to protect the privacy of the hosts and subscribers in an operator network. [I-D.sarikaya-sfc-hostid-serviceheader] is unique among the documents discussed in this document because it defines the post processing normative behavior related to the host and subscriber identifier meta data Type 2 TLVs. Also the use cases are defined in the same document not as a separate document as in the other cases. [I-D.penno-sfc-packet] addresses the problem of sending packets in the reverse direction to the source of the current in-process packet/ flow. It defines SF Reverse Packet Request as Type 1 metadata TLV. This is defined as Version 1 (as opposed to Version 0 of NSH MD-type 1 in [I-D.ietf-sfc-nsh]) with OAM Protocol replacing the next protocol field and with Reverse Packet Request added to the end of mandatory context header octets for SFC as an additional 4-octet for OAM. This document also proposes 5 new metadata on service-path invariants, service-path default, bidirectional clonable, unidirectional clonable and service-function-mastered metadata. Their structure specifics are not specified. [I-D.penno-sfc-packet] gives a detailed explaination of the use of the metadata defined, all the semantic information, pre and post processing details at various nodes. [I-D.vallamkonda-sfc-metadata-model] does not define any Type 1 or Type 2 meta data TLVs, viewing such meta data as conveying preprocessing information about the packet, this document attempts to formally defines the post processing information. To that end, it defines a vocabulary and information model for metadata. The document gives metadata information model example definitions for routing domain, IP endpoint, flow and traffic policy indication. Sarikaya, et al. Expires January 8, 2017 [Page 4] Internet-Draft TLVs in SFC July 2016 3. The Road to Standardization Some options are discussed below for progressing NSH TLVs: 1. List the structure of meta data in one single document. The document is not supposed to contain any post processing information. [I-D.quinn-sfc-nsh-tlv] attempts this choice for Type 2 TLVs. Currently there is no such document for Type 1 TLVs. Note that in this case it is not clear how the post processing normative behavior will be specified for the TLVs. One option is to keep such information in separate document. If such a strategy is adopted then the advantages obtained from documenting all TLVs in one document disappears because the implementers would need to consult many documents instead of only one. 2. Specify an exhaustive list of TLVs in one single document: this approach allows avoiding dependency on other document. 3. All documents defining new meta data Type 1 and Type 2 TLVs are treated individually for standardization. This approach has the advantage of keeping all meta data Type 1 and Type 2 TLVs in separate and dedicated documents together with all the information that the implementers may need. This could be a strong positive especially if we consider the fact that the meta data are being defined for very many use cases and scenarios. It is unlikely that one implementer would need to implement a large number of these TLVs, thereby defeating the need for combining them in a single document. 4. Together with choice 1 above, while combining all TLVs in one document, it could be possible to keep post processing information related to the meta data can be considered individually for standardization. 5. Together with choice 2 above, Type 1 TLVs can combined in one document but all Type 2 TLVs can be considered individually in separate dedicated documents. 4. IANA Considerations None. 5. Security Considerations This document does not introduce any security issues. Sarikaya, et al. Expires January 8, 2017 [Page 5] Internet-Draft TLVs in SFC July 2016 6. Acknowledgements TBD. 7. References 7.1. Normative References [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft- ietf-sfc-nsh-05 (work in progress), May 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . 7.2. Informative References [I-D.ietf-sfc-use-case-mobility] Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and J. Uttaro, "Service Function Chaining Use Cases in Mobile Networks", draft-ietf-sfc-use-case-mobility-06 (work in progress), April 2016. [I-D.liu-sfc-use-cases] Will, W., Li, H., Huang, O., Boucadair, M., Leymann, N., Qiao, F., Qiong, Q., Pham, C., Huang, C., Zhu, J., and P. He, "Service Function Chaining (SFC) General Use Cases", draft-liu-sfc-use-cases-08 (work in progress), September 2014. [I-D.napper-sfc-nsh-broadband-allocation] Napper, J., Surendra, S., Muley, P., and W. Henderickx, "NSH Context Header Allocation -- Broadband", draft- napper-sfc-nsh-broadband-allocation-00 (work in progress), March 2016. [I-D.napper-sfc-nsh-mobility-allocation] Napper, J., Surendra, S., Muley, P., and W. Henderickx, "NSH Context Header Allocation -- Mobility", draft-napper- sfc-nsh-mobility-allocation-02 (work in progress), November 2015. Sarikaya, et al. Expires January 8, 2017 [Page 6] Internet-Draft TLVs in SFC July 2016 [I-D.penno-sfc-appid] Penno, R., Claise, B., Pignataro, C., and C. Fontaine, "Using Application Identification in Services Function Chaining Metadata", draft-penno-sfc-appid-04 (work in progress), June 2016. [I-D.penno-sfc-packet] Penno, R., Pignataro, C., Yen, C., Wang, E., Leung, K., and D. Dolson, "Packet Generation in Service Function Chains", draft-penno-sfc-packet-03 (work in progress), April 2016. [I-D.quinn-sfc-nsh-tlv] Quinn, P., Elzur, U., Majee, S., and J. Halpern, "Network Service Header TLVs", draft-quinn-sfc-nsh-tlv-01 (work in progress), April 2016. [I-D.sarikaya-sfc-hostid-serviceheader] Boucadair, M., Hugo, D., and B. Sarikaya, "Service Function Chaining Service, Subscriber and Host Identification Use Cases and Metadata", draft-sarikaya- sfc-hostid-serviceheader-03 (work in progress), July 2016. [I-D.vallamkonda-sfc-metadata-model] sunilvk@f5.com, s. and D. Dolson, "Information Model for SFC Metadata", draft-vallamkonda-sfc-metadata-model-00 (work in progress), January 2016. [I-D.wang-sfc-ns-use-cases] Wang, E., Leung, K., Felix, J., and J. Iyer, "Service Function Chaining Use Cases for Network Security", draft- wang-sfc-ns-use-cases-01 (work in progress), March 2016. [I-D.wang-sfc-nsh-ns-allocation] Wang, E. and K. Leung, "Network Service Header (NSH) Context Header Allocation (Network Security)", draft-wang- sfc-nsh-ns-allocation-00 (work in progress), May 2016. Authors' Addresses Behcet Sarikaya Huawei 5340 Legacy Dr. Plano, TX 75024 Email: sarikaya@ieee.org Sarikaya, et al. Expires January 8, 2017 [Page 7] Internet-Draft TLVs in SFC July 2016 Mohamed Boucadair Orange Rennes 3500, France Email: mohamed.boucadair@orange.com Dirk von Hugo Telekom Innovation Laboratories Deutsche-Telekom-Allee 7 D-64295 Darmstadt Germany Email: Dirk.von-Hugo@telekom.de Sarikaya, et al. Expires January 8, 2017 [Page 8]