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