idnits 2.17.1 draft-wang-sfc-multi-layer-oam-06.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 12 instances of too long lines in the document, the longest one being 13 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 9, 2017) is 2633 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) == Missing Reference: 'SFC-arch' is mentioned on line 67, but not defined == Unused Reference: 'RFC7498' is defined on line 231, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7498 ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-15) exists of draft-ietf-sfc-oam-framework-01 Summary: 3 errors (**), 0 flaws (~~), 5 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: August 13, 2017 B. Khasnabish 6 ZTE TX, Inc. 7 February 9, 2017 9 Multi-Layering OAM for Service function Chaining 10 draft-wang-sfc-multi-layer-oam-06 12 Abstract 14 This document tries to discuss some problems in SFC OAM framework 15 document and proposes the SFC OAM multi-layering requirements in SFC 16 domain to improve the troubleshooting efficiency. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 13, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Convention and Terminology . . . . . . . . . . . . . . . . . 3 54 3. SFC Layering model . . . . . . . . . . . . . . . . . . . . . 3 55 4. Requirements for SFC OAM multi-layering model . . . . . . . . 3 56 5. SFC OAM multi-layering model . . . . . . . . . . . . . . . . 4 57 6. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . 5 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 9.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 In [SFC-arch], it defines several requisite components to implement 68 SFC, including classifier, which performs classification for incoming 69 packets, and Service Function Forwarder/SFF, which is responsible for 70 forwarding traffic to one or more connected service functions 71 according to the information carried in the SFC encapsulation, as 72 well as handling traffic coming back from the SF and transporting 73 traffic to another SFF and terminating the SFP. And what!_s more, 74 another significant component is Service Function/SF, which is 75 responsible for specific treatment of received packets. 77 Based on these SFC components, there are different notions for 78 differentiated level of service chains, such as fully abstract notion 79 named SFC, which defines an ordered set of service functions that 80 must be applied to packets selected as a result of classification. 81 But, SFC doesn!_t define the exactly SFFs/SFs. And another notion is 82 half-fully abstraction notion named SFP, which is the instantiation 83 of a SFC in the network and provides a level of indirection between 84 the fully abstract SFC and a fully specified RSP. The mean is that 85 SFP defines some SFFs/SFs, not every SFFs/SFs. As well, there is a 86 fully specific notion named RSP, which defines exactly which SFFs/SFs 87 the packet will visit when it actually traverses the network. The 88 main difference between SFP and RSP is that whether delegate the SFF/ 89 SF selection authority to the network or not. 91 This document tries to discuss some problems in basic SFC OAM 92 framework document and proposes the SFC OAM multi-layering 93 requirements to improve the troubleshooting efficiency. 95 2. Convention and Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 The terms are all defined in [RFC7665]. 103 3. SFC Layering model 105 As described in [I-D.ietf-sfc-oam-framework], multiple layers come 106 into play for implementing the SFC, including the Service layer at 107 SFC layer and the underlying Network layer, Transport layer, as well 108 as Link layer, which are depicted in Figure 1. 110 As for the Service layer in Figure 1, it consists of classifiers and/ 111 or service functions/SFs. 113 Concerning Network layer and Transport Layer in Figure 1, it 114 leverages various overlay network technologies interconnecting 115 service functions and allows establishing of service function paths. 117 As for the Link layer in Figure 1, it is dependent on the physical 118 technology used. Such as, Ethernet, POS etc..) 120 +-----------+ +---+ +---+ +---+ +---+ +---+ 121 |Classifier |---|SF1|---|SF2|---|SF3|---|SF4|---|SF5| 122 +-----------+ +---+ +---+ +---+ +---+ +---+ 123 0------------SFC Service layer OAM------------0 124 0----------------0--------------0-------------0 Network layer 125 0-------------0-------0-------0--------0------0 Link Layer 127 Figure 1: SFC Layering model 129 4. Requirements for SFC OAM multi-layering model 131 As for the SFC service layer OAM, except the service layer defined in 132 Figure 1 which focuses on the SFC OAM between classifier and/or SFs, 133 here tries to propose the SFC OAM between classifier and SFFs or SFFs 134 which go through the path along the SFP/RSP, to improve the 135 efficiency when diagnosing. 137 With regard to how to use this proposal and diagnose efficiently, 138 here is an example illustrated as follow. 140 Currently, according to the latest SFC architecture, we know that 141 there are several components defined in the SFC architecture, such as 142 Classifier, SFF, SF, etc, and the relationship between them like 143 this: several SFs may share the same SFF. In some circumstances, one 144 SFP1(one service) includes two RSPs(two differentiated services), 145 such as RSP1(SF1--SF3--SF5) and RSP2(SF2--SF4--SF6) in Figure 2. As 146 illustrated, SFFs make the decision whether forwarding the traffic to 147 RSP1 or RSP2. 149 +---+ +---+ +---+ +---+ +---+ +---+ 150 |SF1| |SF2| |SF3| |SF4| |SF5| |SF6| 151 +---+ +---+ +---+ +---+ +---+ +---+ 152 \ / \ / \ / 153 +-----------+ +----+ +----+ +----+ 154 |Classifier |---|SFF1|-----------|SFF2|-----------|SFF3| 155 +-----------+ +----+ +----+ +----+ 157 Figure 2: different RSPs share the same SFFs path 159 As for customers who want to diagnose, troubleshoot a set of RSPs 160 which share the same SFP, here can diagnose or troubleshoot the SFFs 161 path along the SFP first without forwarding the traffic to the SFs. 162 Once the connectivity between the SFFs are all OK, then diagnose or 163 troubleshoot the separated RSP one by one. Otherwise, we know 164 clearly that the connectivity of two RSPs are failure. 166 And also, for example, if users are willing to or have to diagnose 167 and troubleshoot every one, once the connectivity between different 168 SFs is not OK, users can detect the connectivity between different 169 SFFs along the SFP where the SFs connecting to narrow the failure 170 coverage. In other words, if the connectivity between the detected 171 SFFs is not OK, then the connectivity problem is located. If the 172 connectivity between the detected SFFs is OK, then the connectivity 173 problem should be between the detected SFs and the detected SFFs, 174 which can help to improve the efficiency remarkably of target failure 175 location. 177 5. SFC OAM multi-layering model 179 Figure 3 is a possible architecture for SFC OAM multi-layering model. 180 In this figure, it tries to figure out two possible layers 181 information. The layer 1 outlines the SFFs path along the SFP. The 182 layer 2 outlines the SFs path along the RSP. When trying to do SFC 183 OAM, classifier or service nodes select and confirm which SFC OAM 184 layering they plan to do, then encapsulate the layering information 185 in the SFC OAM packets, and send the SFC OAM packets along the 186 service function paths to the destination. When receiving the SFC 187 OAM packets, service nodes analyze the layering information and then 188 decide whether sending these packets to next SFFs directly without 189 being processed by SFs for layer 1 process or sending to SFs for 190 layer 2 process. 192 +---+ +---+ +----+ +----+ +-----+ +-----+ +------+ +------+ 193 |SF1|..|SFn| |SF1'|..|SFn'| |SF1''|..|SFn''| |SF1'''|..|SFn'''| 194 +---+ +---+ +----+ +----+ +-----+ +-----+ +------+ +------+ 195 \ / \ / | \ / \ / | 196 +-----------+ +----+ +----+ | +-----+ +-----+ | 197 |Classifier |---|SFF1| ... |SFFn| | |SFF1'| ... |SFFn'| | 198 +-----------+ +----+ +----+ | +-----+ +-----+ | 199 | | | | 200 | | | | 201 |------|---------Layer 1--------------------| | 202 | | 203 |-----------------Layer 2-------------------| 205 Figure 3: SFC OAM multi-layering model 207 6. Gap analysis 209 This document tries to complement the SFC OAM framework and all the 210 SFC OAM functions are accordance with the SFC OAM framework. But 211 this proposal may be more applicable for connectivity chech and 212 continuity check. 214 7. Security Considerations 216 It will be considered in a future revision. 218 8. IANA Considerations 220 It will be considered in a future revision. 222 9. References 224 9.1. Normative References 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 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 232 Service Function Chaining", RFC 7498, 233 DOI 10.17487/RFC7498, April 2015, 234 . 236 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 237 Chaining (SFC) Architecture", RFC 7665, 238 DOI 10.17487/RFC7665, October 2015, 239 . 241 9.2. Informative References 243 [I-D.ietf-sfc-oam-framework] 244 Aldrin, S., Krishnan, R., Akiya, N., Pignataro, C., and A. 245 Ghanwani, "Service Function Chaining Operation, 246 Administration and Maintenance Framework", draft-ietf-sfc- 247 oam-framework-01 (work in progress), February 2016. 249 Authors' Addresses 251 Cui Wang 252 ZTE Corporation 253 No.50 Software Avenue, Yuhuatai District 254 Nanjing 255 China 257 Email: wang.cui1@zte.com.cn, lindawangjoy@gmail.com 259 Wei Meng 260 ZTE Corporation 261 No.50 Software Avenue, Yuhuatai District 262 Nanjing 263 China 265 Email: meng.wei2@zte.com.cn,vally.meng@gmail.com 267 Bhumip Khasnabish 268 ZTE TX, Inc. 269 55 Madison Avenue, Suite 160 270 Morristown, New Jersey 07960 271 USA 273 Email: bhumip.khasnabish@ztetx.com