idnits 2.17.1 draft-ao-sfc-overlay-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 : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 6 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 (March 12, 2017) is 2603 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: 'RFC2119' is mentioned on line 116, but not defined == Unused Reference: 'RFC7498' is defined on line 246, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-nsh' is defined on line 258, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7365 ** Downref: Normative reference to an Informational RFC: RFC 7498 ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-12 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG T. Ao 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track G. Mirsky 5 Expires: September 13, 2017 ZTE Corp. 6 March 12, 2017 8 Interworking SFC network and Overlay network 9 draft-ao-sfc-overlay-01 11 Abstract 13 For SFC, it's generally transmitted over an overlay network.A Service 14 Function Chain is an overlay carried over by an underlay network.This 15 document defines necessary interworking stand-alone Network Virtual 16 Edge and Service Forwarding Function entities to ensure proper 17 handling of SFC traffic by the underlay network. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 13, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 4. Interworking action . . . . . . . . . . . . . . . . . . . . . 3 57 4.1. Co-located NVE-SFF . . . . . . . . . . . . . . . . . . . 4 58 4.2. NVE-SFF split . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2.1. Classifier action . . . . . . . . . . . . . . . . . . 4 60 4.2.2. SFF action . . . . . . . . . . . . . . . . . . . . . 5 61 4.2.3. NVE action . . . . . . . . . . . . . . . . . . . . . 5 62 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 8.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 Service Function Chaining (SFC) is a technique for prescribing 73 differentiated traffic forwarding policies within the SFC domain. 74 SFC is described in detail in the SFC architecture document. 75 [RFC7665] . 77 SFC traffic is transferred in overlay network, which is described in 78 SFC architecture document [RFC7665]. In an underlay network, Network 79 Virtualization Edge (NVE) maps the traffic to a tunnel according to 80 the inner destination address of the traffic, then encapsulates the 81 packet into outer. In this document, we assume that the NVEs in 82 overlay network have already obtained the mapping information between 83 NVE and Service Functions(SFs) which is described in NVO3 network 84 framework [RFC7365]. 86 But the destination address of SFC traffic is the final destination 87 of the traffic, not the next hop of the SFC, so that NVE will not 88 tunnel the traffic to the next SF, but encapsulate the SFC traffic 89 with the NVE address connected to the destination station. So it's 90 important to coordinate SFC domain and corresponding underlay 91 network. Underlay network edge device NVE needs to know how to 92 forward SFC traffic, that is NVE should only encapsulate the SFC 93 traffic into the tunnel to the next hop of the SFC. This document 94 analyses how SFC domain can be coordinated with underlay network to 95 ensure that SFC traffic can be forwarded properly. 97 2. Terminology 99 The terminology reuse the terminology in SFC architecture document 100 [RFC7665] and NVO3 network framework. [RFC7365] 102 NVE : Network Virtualization Edge 104 SFC : Service Function Chain 106 SFF : Service Function Forwarder 108 SF : Service Function 110 3. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in 115 [RFC2119]. 117 4. Interworking action 119 +--------------------------------------------------------------------+ 120 | | 121 | Overlay Network | 122 | | 123 | +---------+ +---------+ +---------+ +---------+ | 124 +---| NVE4 |-----| NVE1 +-------+ NVE2 +-------+ NVE3 +--+ 125 +---+-----+ +----+----+ +----+----+ +----+----+ 126 | |/ \ | |/ \ | |/ \ | | 127 \ /| | \ /| | \ /| | \ /| 128 +-----+----+ ===> +----+----+ ====> +----+----+ ===> +----+---+ 129 |Classifier+------+ SFF1 +-------+ SFF2 +-------+ D | 130 +----------+ +----+----+ +----+----+ +----+---+ 131 | | 132 +----+----+ ====> +----+----+ 133 + SF1 +-------+ SF2 + 134 +----+----+ +----+----+ 136 Figure 1 Interworking of SFC domain and Overlay Network 138 As depicted in the Figure 1, all the SFC traffic is transported 139 through an underlay network. The SFC path is Classifier->SF1-SF2->D. 140 NVE1 to NVE4 are to encapsulate the SFC traffic with underlay header, 141 such as VxLAN, GENEVE, etc. So according to the path of the SFC, SFC 142 traffic should be encapsulated at NVE4 and then be forwarded to NVE1 143 over the tunnel. NVE1 will decapsulate and forward the SFC payload 144 to SF1. After being processed at the SF1, the SFC traffic should be 145 encapsulated by NVE1 and forwarded to the NVE2 over the tunnel. NVE2 146 will decapsulate and forward the SFC traffic to SF2, and so on. SFC 147 traffic from SFF1 to SFF2 should be tunneled between NVE1 and NVE2, 148 and traffic from SFF2 to node D should be tunneled between NVE2 and 149 NVE3. This is the behavior we expect. To differentiate these two 150 traffic, in Figure 1, data flow in the SFC overlay using "==>" arrows 151 and data flow between the overlay using "-->" arrows. 153 But before NVEs forward the traffic to underlay network, they have to 154 know how to encapsulate the traffic and which tunnel should be used, 155 that is the NVE need to know what's the next hop of the SFC traffic. 156 Still take the Figure 1 as an example, the NVE1 need to know that the 157 traffic should be forwarded to SF2 which is the next hop of the SFC 158 traffic in SFF1. As we know that the SFC traffic from Classifier has 159 the destination address of D. So here is a question, if the underlay 160 network and SFC domain are independent, NVE1 will tunnel the traffic 161 to NVE3 according to the destination of the SFC traffic , here is D, 162 and then NVE3 will forward the traffic to D, which is a wrong path 163 for the SFC, as it avoids the processing at the SF2. So there must 164 be a way to coordinate between overlay network and SFC domain, to 165 make sure the transport path along the SFC is correct. 167 4.1. Co-located NVE-SFF 169 In this scenario NVE and SFF are co-located. NVE and SFF can 170 coordinate between each other through API. Control Plane needs to 171 signal to NVE and SFF: SFF should notify the NVE what the next hop, 172 and NVE should encapsulate the traffic to the next hop NVE according 173 to the address of the next hop once it finds that the next protocol 174 is Network Service Header (NSH). 176 4.2. NVE-SFF split 178 In this scenario, NVE and SFF are physically separate. Hence the 179 coordination between NVE and SFF should be considered. Two possible 180 solutions are presented, one is from data plane aspect, and another 181 is from control plane aspect. 183 4.2.1. Classifier action 185 Classifier receives traffic from a Source device and classifies the 186 traffic, then encapsulates into NSH. When the Classifier forwards 187 the packet to SFF1 according to SFPID in the SFC header, it should 188 identify the next hop of the SFC (SF1 for example), and before it 189 forwards the traffic to NVE4, the Classifier should change the 190 destination of the packet to be the next hop (SF1) and store the 191 actual destination address in the SFC header as a metadata. 193 4.2.2. SFF action 195 Once SFF gets SFC packet from SF, before it forwards the SFC traffic 196 to NVE that the SFF is connected to, the SFF should find the next hop 197 with the SFPID in the SFC header of the packet, then replace the 198 destination address to next hop, and store the actual destination 199 address in the metadata of the SFC header. 201 Once SFF receives SFC traffic from NVE, before it forwards the SFC 202 packet to SF according to SFPID, the SFF should restore the 203 destination address back to the actual address that is stored in the 204 metadata of the SFC header. 206 The last SFF receives the SFC packet from SF, and finds that it is 207 the last hop of the SFC, and the next hop is the actual destination 208 address in the metadata, so it just restores the destination address 209 to the actual destination address. 211 4.2.3. NVE action 213 NVE receives SFC packet from the Classifier and encapsulates it with 214 appropriate underlay network encapsulation, e.g.,VxLAN Header, 215 according to the destination address of the next hop. According to 216 the outer address header, the traffic is transmitted to the next NVE 217 where it is decapsulated so that it can be forwarded to the 218 corresponding SF. The NVE's action is the same as described inNVO3 219 network framework. [RFC7365]. 221 5. Summary 223 As described above, we suggest before the forwarding of the SFC, the 224 forwarder of the SFC should get next hop of the SFC and replace the 225 destination address with the next hop. With this method, the SFC 226 packets can be transmitted correctly along the correspond SFC path in 227 the underlay network. 229 6. Security Considerations 231 To be added later 233 7. IANA Considerations 235 TBD 237 8. References 239 8.1. Normative References 241 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 242 Rekhter, "Framework for Data Center (DC) Network 243 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 244 2014, . 246 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 247 Service Function Chaining", RFC 7498, 248 DOI 10.17487/RFC7498, April 2015, 249 . 251 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 252 Chaining (SFC) Architecture", RFC 7665, 253 DOI 10.17487/RFC7665, October 2015, 254 . 256 8.2. Informative References 258 [I-D.ietf-sfc-nsh] 259 Quinn, P. and U. Elzur, "Network Service Header", draft- 260 ietf-sfc-nsh-12 (work in progress), February 2017. 262 Authors' Addresses 264 Ting Ao 265 ZTE Corporation 266 No.889, BiBo Road 267 Shanghai 201203 268 China 270 Phone: +86 21 68897642 271 Email: ao.ting@zte.com.cn 273 Greg Mirsky 274 ZTE Corp. 275 1900 McCarthy Blvd. #205 276 Milpitas, CA 95035 277 USA 279 Email: gregimirsky@gmail.com