idnits 2.17.1 draft-ietf-idr-flowspec-nvo3-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 16, 2017) is 2353 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) == Unused Reference: 'EVPN-Overlays' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'Inter-Overlays' is defined on line 322, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Intended Status: Proposed Standard Weiguo Hao 3 Shunwan Zhuang 4 Zhenbin Li 5 Huawei Technologies 6 Rong Gu 7 China Mobil 8 Expires: May 15, 2018 November 16, 2017 10 Dissemination of NVO3 Flow Specification Rules 11 13 Abstract 14 This draft proposes a new subset of component types to support the 15 NVO3 flow-spec application. 17 Status of This Document 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Distribution of this document is unlimited. Comments should be sent 23 to the authors or the TRILL Working Group mailing list 24 . 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 38 Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Table of Contents 43 1. Introduction............................................3 44 1.1 Terminology............................................5 46 2. NVO3 Flow Specification Encoding........................6 48 3. NVO3 Flow Specification Traffic Actions.................8 50 4. Security Considerations.................................8 52 5. IANA Considerations.....................................9 54 Normative References......................................10 55 Informative References....................................11 57 Acknowledgments...........................................12 58 Authors' Addresses........................................12 60 1. Introduction 62 BGP Flow-spec is an extension to BGP that supports the dissemination 63 of traffic flow specification rules. It uses the BGP Control Plane 64 to simplify the distribution of ACLs and allows new filter rules to 65 be injected to all BGP peers simultaneously without changing router 66 configuration. A typical application of BGP Flow-spec is to automate 67 the distribution of traffic filter lists to routers for DDOS 68 mitigation. 70 [RFC5575] defines a new BGP Network Layer Reachability Information 71 (NLRI) format used to distribute traffic flow specification rules. 72 NLRI (AFI=1, SAFI=133) is for IPv4 unicast filtering. NLRI (AFI=1, 73 SAFI=134) is for BGP/MPLS VPN filtering. [IPv6-FlowSpec] and [Layer2- 74 FlowSpec] extend the flow-spec rules for IPv6 and layer 2 Ethernet 75 packets respectively. All these previous flow specifications match 76 only single layer IP/Ethernet information like source/destination 77 MAC, source/destination IP prefix, protocol type, ports, and the 78 like. 80 In the cloud computing era, multi-tenancy has become a core 81 requirement for data centers. Since NVO3 can satisfy multi-tenancy 82 key requirements, this technology is being deployed in an increasing 83 number of cloud data center networks. NVO3 is an overlay technology, 84 VXLAN [RFC7348] and NVGRE [RFC7367] are two typical NVO3 85 encapsulations. GENEVE [GENEVE], GUE [GUE] and GPE [GPE] are three 86 emerging NVO3 encapsulations. Because it is an overlay technology, 87 flow specification matching on an inner header as well as the outer 88 header, as specifified below, is needed. 90 +--+ 91 |CE| 92 +--+ 93 | 94 +----+ 95 +----| PE |----+ 96 +---------+ | +----+ | +---------+ 97 +----+ | +---+ +---+ | +----+ 98 |NVE1|--| | | | | |--|NVE3| 99 +----+ | |GW1| |GW3| | +----+ 100 | +---+ +---+ | 101 | NVO-1 | MPLS | NVO-2 | 102 | +---+ +---+ | 103 | | | | | | 104 +----+ | |GW2| |GW4| | +----+ 105 |NVE2|--| +---+ +---+ |--|NVE4| 106 +----+ +---------+ | | +---------+ +----+ 107 +--------------+ 109 Figure 1. NVO3 Data Center Interconnection 111 The MPLS L2/L3 VPN in the WAN network can be used for NVO3 based data 112 center network interconnection. When the DC and the WAN are operated 113 by the same administrative entity, the Service Provider can decide to 114 integrate the GW and WAN Edge PE functions in the same router for 115 obvious capital and operational cost saving reasons. This is 116 illustrated in Figure 1. There are two interconnection solutions as 117 follows: 119 1. End-to-end NVO3 tunnel across different data centers: NVE1 perform 120 NVO3 encapsulation for DC interconnection with NVE3, the 121 destination VTEP IP is NVE3's IP. The GW doesn't perform NVO3 122 tunnel termination. The DC interconnect WAN is pure an underlay 123 network. 125 2. Segmented NVO3 tunnels across different data centers: NVE1 doesn't 126 perform end-to-end NVO3 encapsulation to NVE3 for DC 127 interconnection. The GW performs NVO3 tunnel encapsulation 128 termination, and then transmits the inner original traffic through 129 MPLS network to the peer data center GW. The peer data center GW 130 terminates MPLS encapsulation, and then performs NVO3 131 encapsulation to transmit the traffic to the local NVE3. 133 In the first solution, to differentiate bandwidth and QOS among 134 different tenants or applications, different TE tunnels in the WAN 135 network will be used to carry the end-to-end NVO3 encapsulation 136 traffic using VN ID, NVO3 outer header DSCP and etc as traffic 137 classification match part. BGP Flow-spec protocol can be used to set 138 the traffic classification on all GWs simultaneously. 140 In the second solution, a centralized BGP speaker can be deployed for 141 DDOS mitigation in the WAN network. When the analyzer detects 142 abnormal traffic, it will automatically generate Flow-spec rules and 143 distribute them to each GW through BGP Flow-spec protocol, the match 144 part should include matching on inner or outer L2/L3 layer or NVO3 145 headers. 147 In summary, the Flow specification match part on the GW/PE should 148 include inner layer 2 Ethernet header, inner layer 3 IP header, outer 149 layer 2 Ethernet header, outer layer 3 IP header, and/or NVO3 header 150 information. Because the current flow-spec matching facilities lack a 151 layer indicator and NVO3 header information, they can't be used 152 directly for the traffic filtering based on NVO3 header or on a 153 specified layer header directly. This draft specifies a new subset of 154 component types to support the NVO3 flow-spec application. 156 1.1 Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 The reader is assumed to be familiar with BGP and NVO3 terminology. 163 The following terms and acronyms are used in this document with the 164 meaning indicated: 166 DC - Data Center 168 DDOS - Distributed Denial of Service (Attack). 170 GW - gateway 172 VN - virtual network 174 WAN - wide area network 176 2. NVO3 Flow Specification Encoding 178 The current Flow-spec rules can only recognize flows based on the 179 outer layer header of NVO3 encapsulation data packets. To enable 180 traffic filtering based on an NVO3 header and inner header of NVO3 181 packets, a new component type acting as a delimiter is introduced. 182 The delimiter type is used to specify the boundary between the inner 183 or outer layer component types for NVO3 data packets. All the 184 component types defined in [RFC5575], [IPv6-FlowSpec], 185 [Layer2-FlowSpec], and the like can be used between two delimiters. 187 Because the NVO3 outer layer address normally belongs to a public 188 network, the "Flow Specification" NLRI for the outer layer header 189 doesn't need to include a Route Distinguisher field (8 bytes). If the 190 outer layer address belongs to a VPN, the NLRI format for the outer 191 header should consist of a fixed-length Route Distinguisher field (8 192 bytes) corresponding to the VPN. This Route Distinguisher is followed 193 by the detail flow specifications for the outer layer. 195 The VN ID is the identification for each tenant network. The "Flow 196 Specification" NLRI for an NVO3 header part should always include VN 197 ID field but a Route Distinguisher field doesn't need to be included. 199 The inner layer MAC/IP address is always associated with a VN ID. 200 Thus the NLRI format for the inner header should consist of a fixed- 201 length VN ID field (4 bytes). The VN ID is followed by the detailed 202 flow specifications for the inner layer. The NLRI length field shall 203 include both the 4 bytes of the VN ID as well as the subsequent flow 204 specification. In the NVO3 terminating into a VPN scenario, if 205 multiple access VN IDs map to one VPN instance, one shared VN ID can 206 be carried in the Flow-Spec rule to enforce the rule to the entire 207 VPN instance and the share VN ID and VPN correspondence should be 208 configured on each VPN PE beforehand. In this case, the function of 209 the layer3 VN ID is the same as a Route Distinguisher: it acts as the 210 identification of the VPN instance. 212 This document specifies the following Flow-Spec Component Types for 213 use with NVO3 flows: 215 Type TBD1 - Delimiter type 216 Encoding: . 218 When this delimiter type is present, it indicates the component 219 types for the next layer of NVO3 header fields immediately 220 follow. At the same time, it indicates the end of the component 221 types belonging to the previous layer of header fields. 223 The value field defines encapsulation type and is encoded as: 225 | 0 1 2 3 4 5 6 7 | 226 +---+---+---+---+---+---+---+---+ 227 | Encap Type | 228 +---+---+---+---+---+---+---+---+ 229 | I | O | Resv | 230 +---+---+---+---+---+---+---+---+ 232 This document defines the following Encap types: 234 - VXLAN: Tunnel Type = 0 236 - NVGRE: Tunnel Type = 1 238 I: If I is set to one, it indicates the component types for the 239 inner layer of NVO3 headers immediately follow. 241 O: If O is set to one, it indicates the component types for the 242 outer layer of NVO3 headers immediately follow. 244 For NVO3 header part, the following additional component types are 245 introduced. 247 Type TBD2 - VN ID 249 Encoding: . 251 Defines a list of {operation, value} pairs used to match 24-bit VN 252 ID which is used as tenant identification in NVO3 network. For 253 NVGRE encapsulation, the VN ID is equivalent to VSID. Values are 254 encoded as 1- to 3-byte quantities. 256 Type TBD3 - Flow ID 258 Encoding: 260 Defines a list of {operation, value} pairs used to match 8-bit 261 Flow ID fields which are only useful for NVGRE encapsulation. 262 Values are encoded as 1-byte quantity. 264 3. NVO3 Flow Specification Traffic Actions 266 The current traffic filtering actions are used for NVO3 encapsulation 267 traffic. For Traffic Marking, only the DSCP in the outer header can 268 be modified. 270 4. Security Considerations 272 No new security issues are introduced to the BGP protocol by this 273 specification. 275 5. IANA Considerations 277 IANA is requested to assign three new Flow Spec Component Types as 278 follows: 280 Type Name Reference 281 ---- -------------- --------- 282 TBD1 Delimiter type [this document] 283 TBD2 VN ID [this document] 284 TBD3 Flow ID [this document] 286 Normative References 288 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 290 March 1997, . 292 [RFC5575] - Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, 293 J., and D. McPherson, "Dissemination of Flow Specification 294 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 295 . 297 [GENEVE] - J. Gross, T. Sridhar, etc, "Geneve: Generic Network 298 Virtualization Encapsulation", draft-ietf-nvo3-geneve, work in 299 progress. 301 [GUE] - T. Herbert, L. Yong, O. Zia, "Generic UDP Encapsulation", 302 draft-ietf-nvo3-gue, work in progress. 304 Informative References 306 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 307 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 308 eXtensible Local Area Network (VXLAN): A Framework for 309 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 310 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 313 [RFC7367] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network 314 Virtualization Using Generic Routing Encapsulation", RFC 7637, 315 DOI 10.17487/RFC7637, September 2015, . 318 [EVPN-Overlays] - A. Sajassi,etc, "A Network Virtualization Overlay 319 Solution using EVPN", draft-ietf-bess-evpn-overlay, work in 320 progress, February. 322 [Inter-Overlays] - J. Rabadan,etc, "Interconnect Solution for EVPN 323 Overlay networks", draft-ietf-bess-dci-evpn-overlay, work in 324 progress. 326 [IPv6-FlowSpec] - R. Raszuk, etc, "Dissemination of Flow 327 Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6, 328 work in progress. 330 [Layer2-FlowSpec] - W. Hao, etc, "Dissemination of Flow Specification 331 Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in 332 progress. 334 [GPE] - P. Quinn,etc, "Generic Protocol Extension for VXLAN", draft- 335 ietf-nvo3-vxlan-gpe, work in progress. 337 Acknowledgments 339 The authors wish to acknowledge the important contributions of Jeff 340 Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, and Lucy Yong. 342 Authors' Addresses 344 Donald Eastlake 345 Huawei Technologies 346 155 Beaver Street 347 Milford, MA 01757 USA 349 Tel: +1-508-333-2270 350 Email: d3e3e3@gmail.com 352 Weiguo Hao 353 Huawei Technologies 354 101 Software Avenue, 355 Nanjing 210012 China 357 Email: haoweiguo@huawei.com 359 Shunwan Zhuang 360 Huawei Technologies 361 Huawei Bld., No.156 Beiqing Rd. 362 Beijing 100095 China 364 Email: zhuangshunwan@huawei.com 366 Zhenbin Li 367 Huawei Technologies 368 Huawei Bld., No.156 Beiqing Rd. 369 Beijing 100095 China 371 Email: lizhenbin@huawei.com 373 Rong Gu 374 China Mobile 376 Email: gurong_cmcc@outlook.com 378 Copyright, Disclaimer, and Additional IPR Provisions 380 Copyright (c) 2017 IETF Trust and the persons identified as the 381 document authors. All rights reserved. 383 This document is subject to BCP 78 and the IETF Trust's Legal 384 Provisions Relating to IETF Documents 385 (http://trustee.ietf.org/license-info) in effect on the date of 386 publication of this document. Please review these documents 387 carefully, as they describe your rights and restrictions with respect 388 to this document. Code Components extracted from this document must 389 include Simplified BSD License text as described in Section 4.e of 390 the Trust Legal Provisions and are provided without warranty as 391 described in the Simplified BSD License.