idnits 2.17.1 draft-ietf-idr-flowspec-nvo3-04.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 4, 2019) is 1872 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 D. Eastlake 2 Intended Status: Proposed Standard W. Hao 3 S. Zhuang 4 Z. Li 5 Huawei Technologies 6 R. Gu 7 China Mobil 8 Expires: September 3, 2019 March 4, 2019 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 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 Access Control Lists (ACLs) and 65 allows new filter rules to be injected to all BGP peers 66 simultaneously without changing router configuration. A typical 67 application of BGP Flow-spec is to automate the distribution of 68 traffic filter lists to routers for Distributed Denial of Service 69 (DDOS) mitigation. 71 [RFC5575] defines a new BGP Network Layer Reachability Information 72 (NLRI) format used to distribute traffic flow specification rules. 73 NLRI (AFI=1, SAFI=133) is for IPv4 unicast filtering. NLRI (AFI=1, 74 SAFI=134) is for BGP/MPLS VPN filtering. [IPv6-FlowSpec] and [Layer2- 75 FlowSpec] extend the flow-spec rules for IPv6 and layer 2 Ethernet 76 packets respectively. All these previous flow specifications match 77 only single layer IP/Ethernet information fields like 78 source/destination MAC, source/destination IP prefix, protocol type, 79 ports, and the like. 81 In the cloud computing era, multi-tenancy has become a core 82 requirement for data centers. Since Network Virtualization Overlays 83 (NVO3) can satisfy multi-tenancy key requirements, this technology is 84 being deployed in an increasing number of cloud data center networks. 85 NVO3 is an overlay technology and VXLAN [RFC7348] and NVGRE [RFC7367] 86 are two typical NVO3 encapsulations. GENEVE [GENEVE], GUE [GUE] and 87 GPE [GPE] are three emerging NVO3 encapsulations. Because it is an 88 overlay technology involving an additional level of encapsulation, 89 flow specification matching on the inner header as well as the outer 90 header, as specified below, is needed. 92 +--+ 93 |CE| 94 +--+ 95 | 96 +----+ 97 +----| PE |----+ 98 +---------+ | +----+ | +---------+ 99 +----+ | +---+ +---+ | +----+ 100 |NVE1|--| | | | | |--|NVE3| 101 +----+ | |GW1| |GW3| | +----+ 102 | +---+ +---+ | 103 | NVO-1 | MPLS | NVO-2 | 104 | +---+ +---+ | 105 | | | | | | 106 +----+ | |GW2| |GW4| | +----+ 107 |NVE2|--| +---+ +---+ |--|NVE4| 108 +----+ +---------+ | | +---------+ +----+ 109 +--------------+ 111 Figure 1. NVO3 Data Center Interconnection 113 The MPLS L2/L3 VPN in the WAN network can be used for NVO3 based data 114 center network interconnection. When the Data Center (DC) and the WAN 115 are operated by the same administrative entity, the Service Provider 116 can decide to integrate the gateway (GW) and WAN Edge PE functions in 117 the same router for capital and operational cost saving reasons. This 118 is illustrated in Figure 1. There are two interconnection solutions 119 as follows: 121 1. End-to-end NVO3 tunnel across different data centers: NVE1 122 performs NVO3 encapsulation for DC interconnection with NVE3. The 123 destination VTEP IP is NVE3's IP. The GW doesn't perform NVO3 124 tunnel termination. The DC interconnect WAN is pure an underlay 125 network. 127 2. Segmented NVO3 tunnels across different data centers: NVE1 doesn't 128 perform end-to-end NVO3 encapsulation to NVE3 for DC 129 interconnection. The GW performs NVO3 tunnel encapsulation 130 termination, and then transmits the inner original traffic through 131 an MPLS network to the peer data center GW. The peer data center 132 GW again terminates MPLS encapsulation, and then performs NVO3 133 encapsulation to transmit the traffic to the local NVE3. 135 In the first solution, to differentiate bandwidth and Quality of 136 Service (QoS) among different tenants or applications, different TE 137 tunnels in the WAN network will be used to carry the end-to-end NVO3 138 encapsulation traffic using VN ID, NVO3 outer header DSCP, and other 139 fields as the traffic classification match part. The BGP Flow-spec 140 protocol can be used to set the traffic classification on all GWs 141 simultaneously. 143 In the second solution, a centralized BGP speaker can be deployed for 144 DDOS mitigation in the WAN network. When the analyzer detects 145 abnormal traffic, it will automatically generate Flow-spec rules and 146 distribute them to each GW through the BGP Flow-spec protocol, the 147 match part should include matching on inner or outer L2/L3 layer or 148 NVO3 headers. 150 In summary, the Flow specification match part on the GW/PE should be 151 able to include inner layer 2 Ethernet header, inner layer 3 IP 152 header, outer layer 2 Ethernet header, outer layer 3 IP header, 153 and/or NVO3 header information. Because the current flow-spec 154 matching facilities lack a layer indicator and NVO3 header 155 information, those facilities can't be used directly for traffic 156 filtering based on NVO3 headers or on a specified layer header 157 directly. This draft specifies a new subset of component types to 158 support the NVO3 flow-spec application. 160 1.1 Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119] [RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 The reader is assumed to be familiar with BGP and NVO3 terminology. 169 The following terms and acronyms are used in this document with the 170 meaning indicated: 172 ACL - Access Control List 174 DC - Data Center 176 DDOS - Distributed Denial of Service (Attack) 178 GW - gateway 180 VN - virtual network 182 VTEP - Virtual Tunnel End Point 184 WAN - wide area network 186 2. NVO3 Flow Specification Encoding 188 The current Flow-spec rules can only recognize flows based on the 189 outer layer header of NVO3 encapsulation data packets. To enable 190 traffic filtering based on an NVO3 header and on an inner header of 191 NVO3 packets, a new component type acting as a delimiter is 192 introduced. The delimiter type is used to indicate the boundary 193 between the inner and outer layer component types for NVO3 data 194 packets. All the component types defined in [RFC5575], 195 [IPv6-FlowSpec], [Layer2-FlowSpec], and the like can be used for the 196 inner or outer header as indicated by the use of delimiters. 198 Because the NVO3 outer layer address normally belongs to a public 199 network, the "Flow Specification" NLRI for the outer layer header 200 doesn't need to include a Route Distinguisher field (8 bytes). If the 201 outer layer address belongs to a VPN, the NLRI format for the outer 202 header should consist of a fixed-length Route Distinguisher field (8 203 bytes) corresponding to the VPN. This Route Distinguisher is followed 204 by the detail flow specifications for the outer layer. 206 The VN ID is the identification for each tenant network. The "Flow 207 Specification" NLRI for an NVO3 header part should always include the 208 VN ID field but a Route Distinguisher field does not need to be 209 included. 211 The inner layer MAC/IP address is always associated with a VN ID. 212 Thus the NLRI format for the inner header should consist of a fixed- 213 length VN ID field (4 bytes). The VN ID is followed by the detailed 214 flow specifications for the inner layer. The NLRI length field shall 215 include both the 4 bytes of the VN ID as well as the subsequent flow 216 specification. In the NVO3 terminating into a VPN scenario, if 217 multiple access VN IDs map to one VPN instance, one shared VN ID can 218 be carried in the Flow-Spec rule to enforce the rule on the entire 219 VPN instance and the shared VN ID and VPN correspondence should be 220 configured on each VPN PE beforehand. In this case, the function of 221 the layer3 VN ID is the same as a Route Distinguisher: it acts as the 222 identification of the VPN instance. 224 This document specifies the following Flow-Spec Component Types for 225 use with NVO3 flows: 227 Type TBD1 - Delimiter type 228 Encoding: . 230 When this delimiter type is present, it indicates the component 231 types and layer for the NVO3 header fields immediately 232 following. At the same time, it indicates the end of the 233 component types belonging to the previous delimiter. 235 The value field defines encapsulation type and is encoded as: 237 | 0 1 2 3 4 5 6 7 | 238 +---+---+---+---+---+---+---+---+ 239 | Encap Type | 240 +---+---+---+---+---+---+---+---+ 241 | I | O | Resv | 242 +---+---+---+---+---+---+---+---+ 244 This document defines the following Encap types: 246 - VXLAN: Tunnel Type = 0 248 - NVGRE: Tunnel Type = 1 250 I: If I is set to one, it indicates the component types for the 251 inner layer of NVO3 headers immediately follow. 253 O: If O is set to one, it indicates the component types for the 254 outer layer of NVO3 headers immediately follow. 256 For the NVO3 header part, the following additional component types are 257 introduced. 259 Type TBD2 - VN ID 261 Encoding: . 263 Defines a list of {operation, value} pairs used to match the 264 24-bit VN ID that is used as the tenant identification in NVO3 265 networks. For NVGRE encapsulation, the VN ID is equivalent to 266 VSID. Values are encoded as 1- to 3-byte quantities. 268 Type TBD3 - Flow ID 270 Encoding: 272 Defines a list of {operation, value} pairs used to match 8-bit 273 Flow ID fields which are only useful for NVGRE encapsulation. 274 Values are encoded as 1-byte quantity. 276 3. NVO3 Flow Specification Traffic Actions 278 The current traffic filtering actions are used for NVO3 encapsulation 279 traffic. For Traffic Marking, only the DSCP in the outer header can 280 be modified. 282 4. Security Considerations 284 No new security issues are introduced to the BGP protocol by this 285 specification. 287 5. IANA Considerations 289 IANA is requested to assign three new values in the "Flow Spec 290 Component Types" registry as follows: 292 Type Name Reference 293 ---- -------------- --------- 294 TBD1 Delimiter type [this document] 295 TBD2 VN ID [this document] 296 TBD3 Flow ID [this document] 298 Normative References 300 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 302 March 1997, . 304 [RFC5575] - Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, 305 J., and D. McPherson, "Dissemination of Flow Specification 306 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 307 . 309 [RFC8174] - [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs 310 Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 311 10.17487/RFC8174, May 2017, . 314 [GENEVE] - J. Gross, T. Sridhar, etc, "Geneve: Generic Network 315 Virtualization Encapsulation", draft-ietf-nvo3-geneve, work in 316 progress. 318 [GUE] - T. Herbert, L. Yong, O. Zia, "Generic UDP Encapsulation", 319 draft-ietf-nvo3-gue, work in progress. 321 Informative References 323 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 324 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 325 eXtensible Local Area Network (VXLAN): A Framework for 326 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 327 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 330 [RFC7367] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network 331 Virtualization Using Generic Routing Encapsulation", RFC 7637, 332 DOI 10.17487/RFC7637, September 2015, . 335 [IPv6-FlowSpec] - R. Raszuk, etc, "Dissemination of Flow 336 Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6, 337 work in progress. 339 [Layer2-FlowSpec] - W. Hao, etc, "Dissemination of Flow Specification 340 Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in 341 progress. 343 [GPE] - P. Quinn, etc, "Generic Protocol Extension for VXLAN", draft- 344 ietf-nvo3-vxlan-gpe, work in progress. 346 Acknowledgments 348 The authors wish to acknowledge the important contributions of Jeff 349 Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, and Lucy Yong. 351 Authors' Addresses 353 Donald Eastlake 354 Huawei Technologies 355 1424 Pro Shop Court 356 Davenport, FL 33896 USA 358 Tel: +1-508-333-2270 359 Email: d3e3e3@gmail.com 361 Weiguo Hao 362 Huawei Technologies 363 101 Software Avenue, 364 Nanjing 210012 China 366 Email: haoweiguo@huawei.com 368 Shunwan Zhuang 369 Huawei Technologies 370 Huawei Bld., No.156 Beiqing Rd. 371 Beijing 100095 China 373 Email: zhuangshunwan@huawei.com 375 Zhenbin Li 376 Huawei Technologies 377 Huawei Bld., No.156 Beiqing Rd. 378 Beijing 100095 China 380 Email: lizhenbin@huawei.com 382 Rong Gu 383 China Mobile 385 Email: gurong_cmcc@outlook.com 387 Copyright, Disclaimer, and Additional IPR Provisions 389 Copyright (c) 2019 IETF Trust and the persons identified as the 390 document authors. All rights reserved. 392 This document is subject to BCP 78 and the IETF Trust's Legal 393 Provisions Relating to IETF Documents 394 (http://trustee.ietf.org/license-info) in effect on the date of 395 publication of this document. Please review these documents 396 carefully, as they describe your rights and restrictions with respect 397 to this document. Code Components extracted from this document must 398 include Simplified BSD License text as described in Section 4.e of 399 the Trust Legal Provisions and are provided without warranty as 400 described in the Simplified BSD License.