idnits 2.17.1 draft-ietf-idr-flowspec-nvo3-06.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 (July 8, 2019) is 1726 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) == Outdated reference: A later version (-27) exists of draft-ietf-idr-rfc5575bis-17 Summary: 0 errors (**), 0 flaws (~~), 3 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 Futurewei Technologies 3 W. Hao 4 S. Zhuang 5 Z. Li 6 Huawei Technologies 7 R. Gu 8 China Mobil 9 Expires: NJanuary 7, 2020 July 8, 2019 11 BGP Dissemination of 12 Network Virtualization Overlays (NVO3) Flow Specification Rules 13 15 Abstract 16 This draft specifies a new subset of component types to support the 17 (Network Virtualization Overlays (NVO3)) flow-spec application. 19 Status of This Document 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Distribution of this document is unlimited. Comments should be sent 25 to the authors or the TRILL Working Group mailing list 26 . 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 40 Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Table of Contents 45 1. Introduction............................................3 46 1.1 Terminology............................................5 48 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] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 308 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 309 2017, . 311 [GENEVE] - J. Gross, T. Sridhar, etc, "Geneve: Generic Network 312 Virtualization Encapsulation", draft-ietf-nvo3-geneve, work in 313 progress. 315 [GUE] - T. Herbert, L. Yong, O. Zia, "Generic UDP Encapsulation", 316 draft-ietf-nvo3-gue, work in progress. 318 [RFC5575bis] - Hares, S., Loibl, C., Raszuk, R., McPherson, D., 319 Bacher, M., "Dissemination of Flow Specification Rules", draft- 320 ietf-idr-rfc5575bis-17, Work in progress, January 2019. 322 Informative References 324 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 325 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 326 eXtensible Local Area Network (VXLAN): A Framework for 327 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 328 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 331 [RFC7367] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network 332 Virtualization Using Generic Routing Encapsulation", RFC 7637, 333 DOI 10.17487/RFC7637, September 2015, . 336 [RFC8014] - Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 337 Narten, "An Architecture for Data-Center Network Virtualization 338 over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December 339 2016, . 341 [IPv6-FlowSpec] - R. Raszuk, etc, "Dissemination of Flow 342 Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6, 343 work in progress. 345 [Layer2-FlowSpec] - W. Hao, etc, "Dissemination of Flow Specification 346 Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in 347 progress. 349 [GPE] - P. Quinn, etc, "Generic Protocol Extension for VXLAN", draft- 350 ietf-nvo3-vxlan-gpe, work in progress. 352 Acknowledgments 354 The authors wish to acknowledge the important contributions of Jeff 355 Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, and Lucy Yong. 357 Authors' Addresses 359 Donald Eastlake 360 Futurewei Technologies 361 1424 Pro Shop Court 362 Davenport, FL 33896 USA 364 Tel: +1-508-333-2270 365 Email: d3e3e3@gmail.com 367 Weiguo Hao 368 Huawei Technologies 369 101 Software Avenue, 370 Nanjing 210012 China 372 Email: haoweiguo@huawei.com 374 Shunwan Zhuang 375 Huawei Technologies 376 Huawei Bld., No.156 Beiqing Rd. 377 Beijing 100095 China 379 Email: zhuangshunwan@huawei.com 381 Zhenbin Li 382 Huawei Technologies 383 Huawei Bld., No.156 Beiqing Rd. 384 Beijing 100095 China 386 Email: lizhenbin@huawei.com 388 Rong Gu 389 China Mobile 391 Email: gurong_cmcc@outlook.com 393 Copyright, Disclaimer, and Additional IPR Provisions 395 Copyright (c) 2019 IETF Trust and the persons identified as the 396 document authors. All rights reserved. 398 This document is subject to BCP 78 and the IETF Trust's Legal 399 Provisions Relating to IETF Documents 400 (http://trustee.ietf.org/license-info) in effect on the date of 401 publication of this document. Please review these documents 402 carefully, as they describe your rights and restrictions with respect 403 to this document. Code Components extracted from this document must 404 include Simplified BSD License text as described in Section 4.e of 405 the Trust Legal Provisions and are provided without warranty as 406 described in the Simplified BSD License.