idnits 2.17.1 draft-vu-sfc-md-scheme-interoperation-01.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 (March 11, 2017) is 2596 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-sfc-dc-use-cases-05 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-hierarchical-01 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-10 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining Vu Anh Vu 3 Internet-Draft Younghan Kim 4 Intended status: Informational Kyoungjae Sun 5 Expires: September 12, 2017 Soongsil University 6 March 11, 2017 8 Interoperation of multiple Metadata schemes in SFC 9 draft-vu-sfc-md-scheme-interoperation-01 11 Abstract 13 Metadata carries SFC information shared amongst SFC components. Each 14 service function requires different metadata, therefore a common 15 metadata scheme for all SFs in SFC domain is redundant and sometime 16 unsecured. 18 This document describes use cases for using multiple NSH Metadata 19 schemes in single and multiple SFC domains and proposes a general 20 architecture and method for coordinating heterogenous Metadata 21 schemes in SFC. 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 September 12, 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 59 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 2 60 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Heterogenous SFs compatibility . . . . . . . . . . . . . 3 62 2.2. Reduce MD size . . . . . . . . . . . . . . . . . . . . . 3 63 2.3. Multi-domain SFC . . . . . . . . . . . . . . . . . . . . 3 64 3. MD scheme Conversion . . . . . . . . . . . . . . . . . . . . 4 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 1.1. Requirements Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 1.2. Problem Statement 81 SFC Architecture document [RFC7665] has defined the purposes of 82 shared Metadata in SFC. Network Service Header (NSH) document 83 [I-D.ietf-sfc-nsh] defines NSH structures, including 2 type of 84 Metadata (MD), and is not repeated here. 86 The NSH document [I-D.ietf-sfc-nsh] defines two types of Metadata in 87 NSH: MD-type 1, which has fixed 4x4 byte length, and MD-type 2 having 88 variable lengths. Every SFs in an SFC-enabled domain MUST support 89 MD-type 1 and SHOULD support MD-type 2. However, the semantics of 90 each byte in MD is up to operators to define. Each operator has its 91 own SFC configuration, hence the SFC MD is different from operator to 92 operator. Operators define MD with their SFC configuration, but 93 their SFs use it, and most of the time SFs are not developed by their 94 operator. Certainly, SF developers always try to make their products 95 compatible with as many environments as possible. Letting operator 96 defining MD give them the flexibility, but sacrifice the 97 compatibility of SFs. More or less, operator and SF developer should 98 have some agreements, or standards, about the semantic of MD. 100 There are attempts to create standards for MD-type 1 for some 101 environment such as datacenters and mobile networks. However, each 102 of them is too specific for a particular use case, and it is 103 difficult to generalize them for all environments. MD-type 2 with is 104 variable length is proposed to provide more flexibility for operator/ 105 vendor-specific SFC and not likely to be standardized. In 106 conclusion, there is a lack of strong reasons to have standards for 107 MD. 109 Therefore, instead of standardizing MD, this document focuses on 110 making multiple MD schemes working seamlessly together in an SFC 111 domain. In detail, this document lists some use cases which require 112 the coexistence of multiple MD schemes and propose an architecture to 113 solve the issue. 115 2. Use cases 117 2.1. Heterogenous SFs compatibility 119 As mentioned, each SF needs different SFC information to process 120 packets, update MD, or select service paths. And each SF gathers 121 that information with its format/scheme, depends on its vendor. An 122 example this use case is third-party SFs, which are controlled by 123 external entities, and proprietary black-boxed SF. To ensure the 124 compatibility of a heterogeneous SF collection in SFC domains, 125 conversions between MD scheme are required. SFs should register 126 their MD scheme to the SFC control plane. 128 2.2. Reduce MD size 130 There are only 4x4 bytes for MD in MD-type 1, which MUST be supported 131 by all NSH-aware SFs, but there might be more information need to be 132 carried throughout an SFC domain. Even though MD-type 2 can be used 133 to carry a large amount of SFC metadata, it is not necessary for all 134 SFs. An SF only needs a part of the data in that MD, hence providing 135 them more information is redundant and in some situation, might cause 136 information leaking. Using multiple MD schemes reduces the size of 137 MD by using all bytes in MD-type 1 effectively and providing 138 sufficient metadata for each SF. 140 2.3. Multi-domain SFC 142 An SFC can be established throughout multiple SFC domains, as 143 described in SFC use cases in data center [I-D.ietf-sfc-dc-use-cases] 144 and Hierarchical SFC [I-D.ietf-sfc-hierarchical]. Occasionally, each 145 SFC domain has a different MD scheme, and as a result, the MD-type 146 translation is required when the traffic traverses between domains. 147 Figure 1 illustrates a scenario where a SFC includes two domains with 148 different MD schemes. When a packet exits a domain and enters 149 another, the MD converter in the second domain will translate MD 150 scheme 1 to MD scheme 2. Surely, control planes of the domains have 151 to coordinate with each other to have the correct translation. 153 +--------------------+ +-------------------+ 154 |SFC domain 1 | |SFC domain 2 | 155 | +---------------+ | | +---------------+ | 156 | | Control plane +<------>+ Control plane | | 157 | +---------------+ | | +----+----------+ | 158 | | | | | 159 Service Path | | | +----v----+ | 160 +---------------------------+---->+ MD +---------------> 161 | +---------+ | | |Converter| | 162 | | MD | | | +---------+ | 163 <---------------+Converter+<--------------------------------+ 164 | +---------+ | | | Reversed 165 +--------------------+ +-------------------+ Path 167 Figure 1: A Multiple MD in Multi-domain SFC scenario 169 3. MD scheme Conversion 171 An SFC domain with multiple MD schemes can be logically divided into 172 multiple MD scheme domains, each of them contains SFs and SFFs that 173 have the same MD scheme. Between MD scheme domain, there are MD 174 scheme converters to translate and alter MD in packets when they 175 travel across domains. Figure 2 show the architecture where 176 Subsequent CFs, which are the most suitable components to be MD 177 scheme converters due to their ability to update MD in packets, are 178 placed between MD scheme domains and responsible for MD translation. 180 +..................+ +.........+ 181 . MD scheme . .MD scheme. 182 . domain 1 . .domain 2 . 183 . . . . 184 +------+ . . +-------+ . . +-------+ 185 | | . +-----+ +-----+ . | Sub- | . +-----+ . | Sub- | 186 | CF +---+ SFF +--+ SFF +---+sequent+---+ SFF +--+ ... -+sequent+- ... 187 | | . +--+--+ +--+--+ . | CF | . +--+--+ . | CF | 188 +------+ . | | . +-------+ . | . +-------+ 189 . +-+-+ +-+-+ . . +-+-+ . 190 . |SF | |SF | . . |SF | . 191 . +---+ +---+ . . +---+ . 192 +..................+ +.........+ 194 Figure 2: MD scheme Conversion with Subsequent CF 196 4. Acknowledgements 198 TBD 200 5. IANA Considerations 202 This document does not require any IANA actions. 204 6. Security Considerations 206 TBD 208 7. Normative References 210 [I-D.ietf-sfc-dc-use-cases] 211 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 212 Homma, "Service Function Chaining Use Cases In Data 213 Centers", draft-ietf-sfc-dc-use-cases-05 (work in 214 progress), August 2016. 216 [I-D.ietf-sfc-hierarchical] 217 Dolson, D., Homma, S., Lopez, D., Boucadair, M., Liu, D., 218 Ao, T., and V. Vu, "Hierarchical Service Function Chaining 219 (hSFC)", draft-ietf-sfc-hierarchical-01 (work in 220 progress), September 2016. 222 [I-D.ietf-sfc-nsh] 223 Quinn, P. and U. Elzur, "Network Service Header", draft- 224 ietf-sfc-nsh-10 (work in progress), September 2016. 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, 228 DOI 10.17487/RFC2119, March 1997, 229 . 231 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 232 Chaining (SFC) Architecture", RFC 7665, 233 DOI 10.17487/RFC7665, October 2015, 234 . 236 Authors' Addresses 238 Vu Anh Vu 239 Soongsil University 240 369 Sangdo-ro 241 Dongjak-gu, Seoul 06978 242 South Korea 244 Email: vuva@dcn.ssu.ac.kr 246 Younghan Kim 247 Soongsil University 248 369 Sangdo-ro 249 Dongjak-gu, Seoul 06978 250 South Korea 252 Email: younghak@ssu.ac.kr 254 Kyoungjae Sun 255 Soongsil University 256 369 Sangdo-ro 257 Dongjak-gu, Seoul 06978 258 South Korea 260 Email: gomjae@ssu.ac.kr