idnits 2.17.1 draft-hao-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 date (October 19, 2015) is 3112 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) -- Looks like a reference, but probably isn't: 'IPv6-FlowSpec' on line 119 -- Looks like a reference, but probably isn't: 'Layer2-FlowSpec' on line 119 -- Looks like a reference, but probably isn't: 'EVPN-Overlays' on line 90 -- Looks like a reference, but probably isn't: 'Inter-Overlays' on line 93 -- Looks like a reference, but probably isn't: 'RFC5575' on line 119 -- Looks like a reference, but probably isn't: 'GENEVE' on line 194 -- Looks like a reference, but probably isn't: 'GUE' on line 194 -- Looks like a reference, but probably isn't: 'GPE' on line 194 == Unused Reference: '1' is defined on line 238, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 242, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 246, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 250, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 254, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 258, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 262, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-overlay-01 == Outdated reference: A later version (-10) exists of draft-ietf-bess-dci-evpn-overlay-01 ** Downref: Normative reference to an Informational RFC: RFC 7348 (ref. '3') ** Downref: Normative reference to an Informational draft: draft-sridharan-virtualization-nvgre (ref. '4') == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-06 == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-02 -- Obsolete informational reference (is this intentional?): RFC 5575 (ref. '7') (Obsoleted by RFC 8955) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IDR Working Group W. Hao 2 S. Zhuang 3 Z. Li 4 Internet Draft Huawei 5 Intended status: Standards Track 7 Expires: April 2016 October 19, 2015 9 Dissemination of Flow Specification Rules for NVO3 10 draft-hao-idr-flowspec-nvo3-02.txt 12 Abstract 14 This draft proposes a new subset of component types to support the 15 NVO3 flow-spec application. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction ................................................ 2 56 2. The Flow Specification encoding for NVO3..................... 3 57 3. The Flow Specification Traffic Actions for NVO3.............. 5 58 4. Security Considerations...................................... 5 59 5. IANA Considerations ......................................... 5 60 5.1. Normative References.................................... 5 61 5.2. Informative References.................................. 6 62 6. Acknowledgments ............................................. 6 64 1. Introduction 66 BGP Flow-spec is an extension to BGP that allows for the 67 dissemination of traffic flow specification rules. It leverages the 68 BGP Control Plane to simplify the distribution of ACLs, new filter 69 rules can be injected to all BGP peers simultaneously without 70 changing router configuration. The typical application of BGP Flow- 71 spec is to automate the distribution of traffic filter lists to 72 routers for DDOS mitigation. 74 RFC5575 defines a new BGP Network Layer Reachability Information 75 (NLRI) format used to distribute traffic flow specification rules. 76 NLRI (AFI=1, SAFI=133)is for IPv4 unicast filtering. NLRI (AFI=1, 77 SAFI=134)is for BGP/MPLS VPN filtering. [IPv6-FlowSpec] defines 78 flow-spec extension for IPv6 data packets. [Layer2-FlowSpec] extends 79 the flow-spec rules for layer 2 Ethernet packets. 81 In cloud computing era, multi-tenancy has become a core requirement 82 for data centers. Since NVO3 can satisfy multi-tenancy key 83 requirements, this technology is being deployed in an increasing 84 number of cloud data center network. NVO3 focuses on the 85 construction of overlay networks that operate over an IP (L3) 86 underlay transport network. It can provide layer 2 bridging and 87 layer 3 IP service for each tenant. VXLAN and NVGRE are two typical 88 NVO3 encapsulations. 90 [EVPN-Overlays] provides a scalable and efficient multi-tenant 91 solution within the Data Center where VXLAN, NVGRE or MPLS over GRE 92 can be used as possible data plane encapsulation options. It uses 93 EVPN as the control plane. [Inter-Overlays] provides a interconnect 94 solution for EVPN overlay networks. 96 Both in data center inside or DCI networks, we also have 97 requirements to deploy BGP Flow-spec for DDoS attack traffic 98 mitigation. The Flow specification rules in NVO3 network can be 99 based on inner layer 2 Ethernet header, inner layer 3 IP header, 100 outer layer 2 Ethernet header, outer layer 3 IP header, and/or NVO3 101 header information. Currently the Flow specification rule [RFC5575] 102 only includes single layer IP information like source/destination 103 prefix, protocol, ports, and etc, the match part lacks layer 104 indicator and NVO3 header information, so it can't be used for the 105 traffic filtering based on NVO3 header or a specified layer header 106 directly. 108 This draft proposes a new subset of component types to support the 109 NVO3 flow-spec application. 111 2. The Flow Specification encoding for NVO3 113 In default, the current flow-spec rules can only impose on the outer 114 layer header of NVO3 encapsulation data packets. To make traffic 115 filtering based on NVO3 header and inner header of NVO3 packets, a 116 new component type acts as a delimiter is introduced. The delimiter 117 type is used to specify the boundary of the inner or outer layer 118 component types for NVO3 data packets. All the component types 119 defined in [RFC5575],[IPv6-FlowSpec],[Layer2-FlowSpec],and etc can 120 be used between two delimiters. 122 The NVO3 outer layer address normally belongs to public network, the 123 "Flow Specification" NLRI only for the outer layer header doesn't 124 need to include Route Distinguisher field (8 bytes). 126 VNID is the identification for each tenant network, the "Flow 127 Specification" NLRI for NVO3 header part should always include VNID 128 field, Route Distinguisher field doesn't need to be included. 130 The inner layer address normally belongs to a VPN, the NLRI format 131 for the inner header should consist of a fixed-length Route 132 Distinguisher field (8 bytes) corresponding to the VPN, the RD is 133 followed by the flow specification for the inner layer. The NLRI 134 length field shall include both the 8 bytes of the Route 135 Distinguisher as well as the subsequent flow specification. 137 Flow specification rules received via this NLRI apply only to 138 traffic that belongs to the VPN instance(s) in which it is imported. 140 This document proposes the following extended specifications for 141 NVO3 flow: 143 Type TBD1 - Delimiter type 145 Encoding: . 147 When the delimiter type is present, it indicates the component types 148 for the inner or outer layer of NVO3 packets will be followed 149 immediately. At the same time, it indicates the end of the component 150 types belonging to the former delimiter. 152 The value field defines encapsulation type and is encoded as: 154 0 1 2 3 4 5 6 7 155 +---+---+---+---+---+---+---+---+ 156 | Encap Type | 157 +---+---+---+---+---+---+---+---+ 158 | I | O | Resv | 159 +---+---+---+---+---+---+---+---+ 160 This document defines the following Encap types: 162 - VXLAN: Tunnel Type = 0 164 - NVGRE: Tunnel Type = 1 166 I: If I is set to one, it indicates the component types for the 167 inner layer of NVO3 packets will be followed immediately. 169 O: If O is set to one, it indicates the component types for the 170 outer layer of NVO3 packets will be followed immediately. 172 For NVO3 header part, the following additional component types are 173 introduced. 175 Type TBD2 - VNID 177 Encoding: . 179 Defines a list of {operation, value} pairs used to match 24-bit VN 180 ID which is used as tenant identification in NVO3 network. For NVGRE 181 encapsulation, the VNID is equivalent to VSID. Values are encoded as 182 1- to 3-byte quantities. 184 Type TBD3 - Flow ID 186 Encoding: 188 Defines a list of {operation, value} pairs used to match 8-bit Flow 189 id fields which are only useful for NVGRE encapsulation. Values are 190 encoded as 1-byte quantity. 192 Other types: 194 The additional types for GENEVE [GENEVE],GUE [GUE] and GPE [GPE] 195 header specific part will be added later. 197 3. The Flow Specification Traffic Actions for NVO3 199 The current traffic filtering actions can still be used for NVO3 200 encapsulation traffic. For Traffic Marking, only the DSCP in outer 201 header can be modified. 203 4. Security Considerations 205 No new security issues are introduced to the BGP protocol by this 206 specification. 208 5. IANA Considerations 210 IANA is requested to create and maintain a new registry entitled: 212 "Flow spec NVO3 Component Types": 214 Type TBD1 - Delimiter type 216 Type TBD2 - VNID 218 Type TBD3 - Flow ID 220 5.1. Normative References 222 [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 224 Requirement Levels", BCP 14, RFC 2119, March 1997. 226 [2] [GENEVE] J. Gross, T. Sridhar, etc, " Geneve: Generic Network 227 Virtualization Encapsulation", draft-ietf-nvo3-geneve-00, May 228 2015. 230 [3] [GUE] T. Herbert, L. Yong, O. Zia, " Generic UDP 231 Encapsulation", draft-ietf-nvo3-gue-01, Jun 2015. 233 [4] [GPE] P. Quinn,etc, " Generic Protocol Extension for VXLAN", 234 draft-ietf-nvo3-vxlan-gpe-00, May 2015. 236 5.2. Informative References 238 [1] [EVPN-Overlays] A. Sajassi,etc, " A Network Virtualization 239 Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-01 , 240 work in progress, February, 2014. 242 [2] [Inter-Overlays] J. Rabadan,etc, " Interconnect Solution for 243 EVPN Overlay networks", draft-ietf-bess-dci-evpn-overlay-01, 244 work in progress, July, 2015. 246 [3] [RFC7348] M. Mahalingam, etc, "Virtual eXtensible Local Area 247 Network (VXLAN): A Framework for Overlaying Virtualized Layer 248 2 Networks over Layer 3 Networks", RFC7348, August 2014. 250 [4] [NVGRE] P. Garg, etc, "NVGRE: Network Virtualization using 251 Generic Routing Encapsulation", draft-sridharan- 252 virtualization-nvgre-08, April 13, 2015. 254 [5] [IPv6-FlowSpec] R. Raszuk, etc, " Dissemination of Flow 255 Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6-06, 256 November 2014. 258 [6] [Layer2-FlowSpec] W. Hao, etc, "Dissemination of Flow 259 Specification Rules for L2 VPN", draft-ietf-idr-flowspec- 260 l2vpn-02, August 2015. 262 [7] [RFC5575] P. Marques, N. Sheth, R. Raszuk, B. Greene, J.Mauch, 263 D. McPherson, "Dissemination of Flow Specification Rules", RFC 264 5575, August 2009. 266 6. Acknowledgments 268 The authors wish to acknowledge the important contributions of Susan 269 Hares, Qiandeng Liang, Nan Wu, Yizhou Li, Lucy Yong. 271 Authors' Addresses 273 Weiguo Hao 274 Huawei Technologies 275 101 Software Avenue, 276 Nanjing 210012 277 China 278 Email: haoweiguo@huawei.com 280 Shunwan Zhuang 281 Huawei Technologies 282 Huawei Bld., No.156 Beiqing Rd. 283 Beijing 100095 284 China 285 Email: zhuangshunwan@huawei.com 287 Zhenbin Li 288 Huawei Technologies 289 Huawei Bld., No.156 Beiqing Rd. 290 Beijing 100095 291 China 292 Email: lizhenbin@huawei.com