idnits 2.17.1 draft-ietf-idr-flowspec-nvo3-05.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 (April 27, 2019) is 1823 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: October 26, 2019 April 27, 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...........................................11 58 Authors' Addresses........................................11 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 [RFC5575bis] 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 [RFC8014]) can satisfy multi-tenancy key requirements, this 84 technology is being deployed in an increasing number of cloud data 85 center networks. NVO3 is an overlay technology and VXLAN [RFC7348] 86 and NVGRE [RFC7367] are two typical NVO3 encapsulations. GENEVE 87 [GENEVE], GUE [GUE] and GPE [GPE] are three emerging NVO3 88 encapsulations. Because it is an overlay technology involving an 89 additional level of encapsulation, flow specification matching on the 90 inner header as well as the outer header, as specified below, is 91 needed. 93 +--+ 94 |CE| 95 +--+ 96 | 97 +----+ 98 +----| PE |----+ 99 +---------+ | +----+ | +---------+ 100 +----+ | +---+ +---+ | +----+ 101 |NVE1|--| | | | | |--|NVE3| 102 +----+ | |GW1| |GW3| | +----+ 103 | +---+ +---+ | 104 | NVO-1 | MPLS | NVO-2 | 105 | +---+ +---+ | 106 | | | | | | 107 +----+ | |GW2| |GW4| | +----+ 108 |NVE2|--| +---+ +---+ |--|NVE4| 109 +----+ +---------+ | | +---------+ +----+ 110 +--------------+ 112 Figure 1. NVO3 Data Center Interconnection 114 The MPLS L2/L3 VPN in the WAN network can be used for NVO3 based data 115 center network interconnection. When the Data Center (DC) and the WAN 116 are operated by the same administrative entity, the Service Provider 117 can decide to integrate the gateway (GW) and WAN Edge PE functions in 118 the same router for capital and operational cost saving reasons. This 119 is illustrated in Figure 1. There are two interconnection solutions 120 as follows: 122 1. End-to-end NVO3 tunnel across different data centers: NVE1 123 performs NVO3 encapsulation for DC interconnection with NVE3. The 124 destination VTEP IP is NVE3's IP. The GW doesn't perform NVO3 125 tunnel termination. The DC interconnect WAN is pure an underlay 126 network. 128 2. Segmented NVO3 tunnels across different data centers: NVE1 doesn't 129 perform end-to-end NVO3 encapsulation to NVE3 for DC 130 interconnection. The GW performs NVO3 tunnel encapsulation 131 termination, and then transmits the inner original traffic through 132 an MPLS network to the peer data center GW. The peer data center 133 GW terminates MPLS encapsulation, and then performs NVO3 134 encapsulation to transmit the traffic to the local NVE3. 136 In the first solution, to differentiate bandwidth and Quality of 137 Service (QoS) among different tenants or applications, different 138 traffic engneered tunnels in the WAN network will be used to carry 139 the end-to-end NVO3 encapsulation traffic using VN ID, NVO3 outer 140 header DSCP, and other fields as the traffic classification match 141 part. The BGP Flow-spec protocol can be used to set the traffic 142 classification on all GWs simultaneously. 144 In the second solution, a centralized BGP speaker can be deployed for 145 DDOS mitigation in the WAN network. When the analyzer detects 146 abnormal traffic, it will automatically generate Flow-spec rules and 147 distribute them to each GW through the BGP Flow-spec protocol, the 148 match part should include matching on inner or outer L2/L3 layer or 149 NVO3 headers. 151 In summary, the Flow specification match part on the GW/PE should be 152 able to include inner layer 2 Ethernet header, inner layer 3 IP 153 header, outer layer 2 Ethernet header, outer layer 3 IP header, 154 and/or NVO3 header information. Because the current flow-spec 155 matching facilities lack a layer indicator and NVO3 header 156 information, those facilities can't be used directly for traffic 157 filtering based on NVO3 headers or on a specified layer header 158 directly. This draft specifies a new subset of component types to 159 support the NVO3 flow-spec application. 161 1.1 Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in BCP 166 14 [RFC2119] [RFC8174] when, and only when, they appear in all 167 capitals, as shown here. 169 The reader is assumed to be familiar with BGP and NVO3 terminology. 170 The following terms and acronyms are used in this document with the 171 meaning indicated: 173 ACL - Access Control List 175 DC - Data Center 177 DDOS - Distributed Denial of Service (Attack) 179 DSCP - Differentiated Services Code Point 181 GW - gateway 183 VN - virtual network 185 VTEP - Virtual Tunnel End Point 187 WAN - wide area network 189 2. NVO3 Flow Specification Encoding 191 The current Flow-spec rules can only recognize flows based on the 192 outer layer header of NVO3 encapsulation data packets. To enable 193 traffic filtering based on an NVO3 header and on an inner header of 194 NVO3 packets, a new component type acting as a delimiter is 195 introduced. The delimiter type is used to indicate the boundary 196 between the inner and outer layer component types for NVO3 data 197 packets. All the component types defined in [RFC5575bis], 198 [IPv6-FlowSpec], [Layer2-FlowSpec], and the like can be used for the 199 inner or outer header as indicated by the use of delimiters. 201 Because the NVO3 outer layer address normally belongs to a public 202 network, the "Flow Specification" NLRI for the outer layer header 203 doesn't need to include a Route Distinguisher field (8 bytes). If the 204 outer layer address belongs to a VPN, the NLRI format for the outer 205 header should consist of a fixed-length Route Distinguisher field (8 206 bytes) corresponding to the VPN. This Route Distinguisher is followed 207 by the detail flow specifications for the outer layer. 209 The VN ID is the identification for each tenant network. The "Flow 210 Specification" NLRI for an NVO3 header part should always include the 211 VN ID field but a Route Distinguisher field does not need to be 212 included. 214 The inner layer MAC/IP address is always associated with a VN ID. 215 Thus the NLRI format for the inner header should consist of a fixed- 216 length VN ID field (4 bytes). The VN ID is followed by the detailed 217 flow specifications for the inner layer. The NLRI length field shall 218 include both the 4 bytes of the VN ID as well as the subsequent flow 219 specification. In the NVO3 terminating into a VPN scenario, if 220 multiple access VN IDs map to one VPN instance, one shared VN ID can 221 be carried in the Flow-Spec rule to enforce the rule on the entire 222 VPN instance and the shared VN ID and VPN correspondence should be 223 configured on each VPN PE beforehand. In this case, the function of 224 the layer3 VN ID is the same as a Route Distinguisher: it acts as the 225 identification of the VPN instance. 227 This document specifies the following Flow-Spec Component Types for 228 use with NVO3 flows: 230 Type TBD1 - Delimiter type 231 Encoding: . 233 When this delimiter type is present, it indicates the component 234 types and layer for the NVO3 header fields immediately 235 following. At the same time, it indicates the end of the 236 component types belonging to the previous delimiter. 238 The value field defines encapsulation type and is encoded as: 240 | 0 1 2 3 4 5 6 7 | 241 +---+---+---+---+---+---+---+---+ 242 | Encap Type | 243 +---+---+---+---+---+---+---+---+ 244 | I | O | Resv | 245 +---+---+---+---+---+---+---+---+ 247 This document defines the following Encap types: 249 - VXLAN: Tunnel Type = 0 251 - NVGRE: Tunnel Type = 1 253 I: If I is set to one, it indicates the component types for the 254 inner layer of NVO3 headers immediately follow. 256 O: If O is set to one, it indicates the component types for the 257 outer layer of NVO3 headers immediately follow. 259 For the NVO3 header part, the following additional two component types 260 are introduced. 262 Type TBD2 - VN ID 264 Encoding: . 266 Defines a list of {operation, value} pairs used to match the 267 24-bit VN ID that is used as the tenant identification in NVO3 268 networks. For NVGRE encapsulation, the VN ID is equivalent to 269 VSID. Values are encoded as 1- to 3-byte quantities. 271 Type TBD3 - Flow ID 273 Encoding: 275 Defines a list of {operation, value} pairs used to match 8-bit 276 Flow ID fields which are only useful for NVGRE encapsulation. 277 Values are encoded as 1-byte quantity. 279 3. NVO3 Flow Specification Traffic Actions 281 The current traffic filtering actions are used for NVO3 encapsulation 282 traffic. For Traffic Marking, only the DSCP in the outer header can 283 be modified. 285 4. Security Considerations 287 No new security issues are introduced to the BGP protocol by this 288 specification. 290 5. IANA Considerations 292 IANA is requested to assign three new values in the "Flow Spec 293 Component Types" registry as follows: 295 Type Name Reference 296 ---- -------------- --------- 297 TBD1 Delimiter type [this document] 298 TBD2 VN ID [this document] 299 TBD3 Flow ID [this document] 301 Normative References 303 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 305 March 1997, . 307 [RFC8174] - [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs 308 Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 309 10.17487/RFC8174, May 2017, . 312 [GENEVE] - J. Gross, T. Sridhar, etc, "Geneve: Generic Network 313 Virtualization Encapsulation", draft-ietf-nvo3-geneve, work in 314 progress. 316 [GUE] - T. Herbert, L. Yong, O. Zia, "Generic UDP Encapsulation", 317 draft-ietf-nvo3-gue, work in progress. 319 [RFC5575bis] - Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, 320 J., and D. McPherson, "Dissemination of Flow Specification 321 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 322 . 324 Informative References 326 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 327 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 328 eXtensible Local Area Network (VXLAN): A Framework for 329 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 330 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 333 [RFC7367] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network 334 Virtualization Using Generic Routing Encapsulation", RFC 7637, 335 DOI 10.17487/RFC7637, September 2015, . 338 [RFC8014] - Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 339 Narten, "An Architecture for Data-Center Network Virtualization 340 over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December 341 2016, . 343 [IPv6-FlowSpec] - R. Raszuk, etc, "Dissemination of Flow 344 Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6, 345 work in progress. 347 [Layer2-FlowSpec] - W. Hao, etc, "Dissemination of Flow Specification 348 Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in 349 progress. 351 [GPE] - P. Quinn, etc, "Generic Protocol Extension for VXLAN", draft- 352 ietf-nvo3-vxlan-gpe, work in progress. 354 Acknowledgments 356 The authors wish to acknowledge the important contributions of Jeff 357 Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, and Lucy Yong. 359 Authors' Addresses 361 Donald Eastlake 362 Huawei Technologies 363 1424 Pro Shop Court 364 Davenport, FL 33896 USA 366 Tel: +1-508-333-2270 367 Email: d3e3e3@gmail.com 369 Weiguo Hao 370 Huawei Technologies 371 101 Software Avenue, 372 Nanjing 210012 China 374 Email: haoweiguo@huawei.com 376 Shunwan Zhuang 377 Huawei Technologies 378 Huawei Bld., No.156 Beiqing Rd. 379 Beijing 100095 China 381 Email: zhuangshunwan@huawei.com 383 Zhenbin Li 384 Huawei Technologies 385 Huawei Bld., No.156 Beiqing Rd. 386 Beijing 100095 China 388 Email: lizhenbin@huawei.com 390 Rong Gu 391 China Mobile 393 Email: gurong_cmcc@outlook.com 395 Copyright, Disclaimer, and Additional IPR Provisions 397 Copyright (c) 2019 IETF Trust and the persons identified as the 398 document authors. All rights reserved. 400 This document is subject to BCP 78 and the IETF Trust's Legal 401 Provisions Relating to IETF Documents 402 (http://trustee.ietf.org/license-info) in effect on the date of 403 publication of this document. Please review these documents 404 carefully, as they describe your rights and restrictions with respect 405 to this document. Code Components extracted from this document must 406 include Simplified BSD License text as described in Section 4.e of 407 the Trust Legal Provisions and are provided without warranty as 408 described in the Simplified BSD License.