idnits 2.17.1 draft-ietf-idr-flowspec-nvo3-02.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 (March 21, 2018) is 2228 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) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 2 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: September 20, 2018 March 21, 2018 10 BGP Dissemination of 11 Network Virtualization Overlays (NVO3) Flow Specification Rules 12 14 Abstract 15 This draft specifies a new subset of component types to support the 16 (Network Virtualization Overlays (NVO3) flow-spec application. 18 Status of This Document 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Distribution of this document is unlimited. Comments should be sent 24 to the authors or the TRILL Working Group mailing list 25 . 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 39 Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Table of Contents 44 1. Introduction............................................3 45 1.1 Terminology............................................5 47 2. NVO3 Flow Specification Encoding........................6 49 3. NVO3 Flow Specification Traffic Actions.................8 51 4. Security Considerations.................................8 52 5. IANA Considerations.....................................8 54 Normative References.......................................9 55 Informative References.....................................9 57 Acknowledgments...........................................10 58 Authors' Addresses........................................10 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 Distributed 68 Denial of Service (DDOS) 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 fields like 77 source/destination MAC, source/destination IP prefix, protocol type, 78 ports, and the like. 80 In the cloud computing era, multi-tenancy has become a core 81 requirement for data centers. Since Network Virtualization Overlays 82 (NVO3) can satisfy multi-tenancy key requirements, this technology is 83 being deployed in an increasing number of cloud data center networks. 84 NVO3 is an overlay technology and VXLAN [RFC7348] and NVGRE [RFC7367] 85 are two typical NVO3 encapsulations. GENEVE [GENEVE], GUE [GUE] and 86 GPE [GPE] are three emerging NVO3 encapsulations. Because it is an 87 overlay technology, flow specification matching on an inner header as 88 well as the outer header, as specified 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 Data Center (DC) and the WAN 113 are operated by the same administrative entity, the Service Provider 114 can decide to integrate the gateway (GW) and WAN Edge PE functions in 115 the same router for obvious capital and operational cost saving 116 reasons. This is illustrated in Figure 1. There are two 117 interconnection solutions as 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. The BGP Flow-spec protocol can be used to 138 set 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", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in BCP 161 14 [RFC2119] [RFC8174] when, and only when, they appear in all 162 capitals, as shown here. 164 The reader is assumed to be familiar with BGP and NVO3 terminology. 165 The following terms and acronyms are used in this document with the 166 meaning indicated: 168 DC - Data Center 170 DDOS - Distributed Denial of Service (Attack). 172 GW - gateway 174 VN - virtual network 176 WAN - wide area network 178 2. NVO3 Flow Specification Encoding 180 The current Flow-spec rules can only recognize flows based on the 181 outer layer header of NVO3 encapsulation data packets. To enable 182 traffic filtering based on an NVO3 header and inner header of NVO3 183 packets, a new component type acting as a delimiter is introduced. 184 The delimiter type is used to specify the boundary between the inner 185 and outer layer component types for NVO3 data packets. All the 186 component types defined in [RFC5575], [IPv6-FlowSpec], 187 [Layer2-FlowSpec], and the like can be used between two delimiters. 189 Because the NVO3 outer layer address normally belongs to a public 190 network, the "Flow Specification" NLRI for the outer layer header 191 doesn't need to include a Route Distinguisher field (8 bytes). If the 192 outer layer address belongs to a VPN, the NLRI format for the outer 193 header should consist of a fixed-length Route Distinguisher field (8 194 bytes) corresponding to the VPN. This Route Distinguisher is followed 195 by the detail flow specifications for the outer layer. 197 The VN ID is the identification for each tenant network. The "Flow 198 Specification" NLRI for an NVO3 header part should always include VN 199 ID field but a Route Distinguisher field doesn't need to be included. 201 The inner layer MAC/IP address is always associated with a VN ID. 202 Thus the NLRI format for the inner header should consist of a fixed- 203 length VN ID field (4 bytes). The VN ID is followed by the detailed 204 flow specifications for the inner layer. The NLRI length field shall 205 include both the 4 bytes of the VN ID as well as the subsequent flow 206 specification. In the NVO3 terminating into a VPN scenario, if 207 multiple access VN IDs map to one VPN instance, one shared VN ID can 208 be carried in the Flow-Spec rule to enforce the rule to the entire 209 VPN instance and the share VN ID and VPN correspondence should be 210 configured on each VPN PE beforehand. In this case, the function of 211 the layer3 VN ID is the same as a Route Distinguisher: it acts as the 212 identification of the VPN instance. 214 This document specifies the following Flow-Spec Component Types for 215 use with NVO3 flows: 217 Type TBD1 - Delimiter type 218 Encoding: . 220 When this delimiter type is present, it indicates the component 221 types for the next layer of NVO3 header fields immediately 222 follow. At the same time, it indicates the end of the component 223 types belonging to the previous layer of header fields. 225 The value field defines encapsulation type and is encoded as: 227 | 0 1 2 3 4 5 6 7 | 228 +---+---+---+---+---+---+---+---+ 229 | Encap Type | 230 +---+---+---+---+---+---+---+---+ 231 | I | O | Resv | 232 +---+---+---+---+---+---+---+---+ 234 This document defines the following Encap types: 236 - VXLAN: Tunnel Type = 0 238 - NVGRE: Tunnel Type = 1 240 I: If I is set to one, it indicates the component types for the 241 inner layer of NVO3 headers immediately follow. 243 O: If O is set to one, it indicates the component types for the 244 outer layer of NVO3 headers immediately follow. 246 For NVO3 header part, the following additional component types are 247 introduced. 249 Type TBD2 - VN ID 251 Encoding: . 253 Defines a list of {operation, value} pairs used to match 24-bit VN 254 ID which is used as tenant identification in NVO3 network. For 255 NVGRE encapsulation, the VN ID is equivalent to VSID. Values are 256 encoded as 1- to 3-byte quantities. 258 Type TBD3 - Flow ID 260 Encoding: 262 Defines a list of {operation, value} pairs used to match 8-bit 263 Flow ID fields which are only useful for NVGRE encapsulation. 264 Values are encoded as 1-byte quantity. 266 3. NVO3 Flow Specification Traffic Actions 268 The current traffic filtering actions are used for NVO3 encapsulation 269 traffic. For Traffic Marking, only the DSCP in the outer header can 270 be modified. 272 4. Security Considerations 274 No new security issues are introduced to the BGP protocol by this 275 specification. 277 5. IANA Considerations 279 IANA is requested to assign three new values in the "Flow Spec 280 Component Types" registry as follows: 282 Type Name Reference 283 ---- -------------- --------- 284 TBD1 Delimiter type [this document] 285 TBD2 VN ID [this document] 286 TBD3 Flow ID [this document] 288 Normative References 290 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 292 March 1997, . 294 [RFC5575] - Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, 295 J., and D. McPherson, "Dissemination of Flow Specification 296 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 297 . 299 [RFC8174] - [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs 300 Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 301 10.17487/RFC8174, May 2017, . 304 [GENEVE] - J. Gross, T. Sridhar, etc, "Geneve: Generic Network 305 Virtualization Encapsulation", draft-ietf-nvo3-geneve, work in 306 progress. 308 [GUE] - T. Herbert, L. Yong, O. Zia, "Generic UDP Encapsulation", 309 draft-ietf-nvo3-gue, work in progress. 311 Informative References 313 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 314 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 315 eXtensible Local Area Network (VXLAN): A Framework for 316 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 317 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 320 [RFC7367] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network 321 Virtualization Using Generic Routing Encapsulation", RFC 7637, 322 DOI 10.17487/RFC7637, September 2015, . 325 [IPv6-FlowSpec] - R. Raszuk, etc, "Dissemination of Flow 326 Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6, 327 work in progress. 329 [Layer2-FlowSpec] - W. Hao, etc, "Dissemination of Flow Specification 330 Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in 331 progress. 333 [GPE] - P. Quinn, etc, "Generic Protocol Extension for VXLAN", draft- 334 ietf-nvo3-vxlan-gpe, work in progress. 336 Acknowledgments 338 The authors wish to acknowledge the important contributions of Jeff 339 Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, and Lucy Yong. 341 Authors' Addresses 343 Donald Eastlake 344 Huawei Technologies 345 155 Beaver Street 346 Milford, MA 01757 USA 348 Tel: +1-508-333-2270 349 Email: d3e3e3@gmail.com 351 Weiguo Hao 352 Huawei Technologies 353 101 Software Avenue, 354 Nanjing 210012 China 356 Email: haoweiguo@huawei.com 358 Shunwan Zhuang 359 Huawei Technologies 360 Huawei Bld., No.156 Beiqing Rd. 361 Beijing 100095 China 363 Email: zhuangshunwan@huawei.com 365 Zhenbin Li 366 Huawei Technologies 367 Huawei Bld., No.156 Beiqing Rd. 368 Beijing 100095 China 370 Email: lizhenbin@huawei.com 372 Rong Gu 373 China Mobile 375 Email: gurong_cmcc@outlook.com 377 Copyright, Disclaimer, and Additional IPR Provisions 379 Copyright (c) 2018 IETF Trust and the persons identified as the 380 document authors. All rights reserved. 382 This document is subject to BCP 78 and the IETF Trust's Legal 383 Provisions Relating to IETF Documents 384 (http://trustee.ietf.org/license-info) in effect on the date of 385 publication of this document. Please review these documents 386 carefully, as they describe your rights and restrictions with respect 387 to this document. Code Components extracted from this document must 388 include Simplified BSD License text as described in Section 4.e of 389 the Trust Legal Provisions and are provided without warranty as 390 described in the Simplified BSD License.