idnits 2.17.1 draft-hao-idr-flowspec-nvo3-01.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 (August 15, 2015) is 3177 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 130 -- Looks like a reference, but probably isn't: 'Layer2-FlowSpec' on line 130 -- 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 130 -- Looks like a reference, but probably isn't: 'GENEVE' on line 186 -- Looks like a reference, but probably isn't: 'GUE' on line 186 -- Looks like a reference, but probably isn't: 'GPE' on line 186 == Unused Reference: '1' is defined on line 230, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 234, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 238, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 242, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 246, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 250, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 254, 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 Technologies Ltd. 5 Intended status: Standards Track 7 Expires: February 2016 August 15, 2015 9 Dissemination of Flow Specification Rules for NVO3 10 draft-hao-idr-flowspec-nvo3-01.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 The NLRI format for this address family consists of a fixed-length 114 Route Distinguisher field (8 bytes) followed by a flow specification, 115 following the encoding defined in this document. The NLRI length 116 field shall include both the 8 bytes of the Route Distinguisher as 117 well as the subsequent flow specification. 119 Flow specification rules received via this NLRI apply only to 120 traffic that belongs to the VPN instance(s) in which it is imported. 121 Flow rules are accepted by default, when received from remote PE 122 routers. 124 In default, the current flow-spec rules can only impose on the outer 125 layer header of NVO3 encapsulation data packets. To make traffic 126 filtering based on NVO3 header and inner header of NVO3 packets, a 127 new component type acts as a delimiter is introduced. The delimiter 128 type is used to specify the boundary of the inner or outer layer 129 component types for NVO3 data packets. All the component types 130 defined in [RFC5575],[IPv6-FlowSpec],[Layer2-FlowSpec],and etc can 131 be used within the delimiter. 133 The following component types are newly defined: 135 Type TBD1 - Delimiter type 137 Encoding: . 139 When the delimiter type is present, it indicates the component types 140 for the inner or outer layer of NVO3 packets will be followed 141 immediately. At the same time, it indicates the end of the component 142 types belonging to the former delimiter. 144 The value field defines encapsulation type and is encoded as: 146 0 1 2 3 4 5 6 7 147 +---+---+---+---+---+---+---+---+ 148 | Encap Type | 149 +---+---+---+---+---+---+---+---+ 150 | I | O | Resv | 151 +---+---+---+---+---+---+---+---+ 152 This document defines the following Encap types: 154 - VXLAN: Tunnel Type = 0 156 - NVGRE: Tunnel Type = 1 158 I: If I is set to one, it indicates the component types for the 159 inner layer of NVO3 packets will be followed immediately. 161 O: If O is set to one, it indicates the component types for the 162 outer layer of NVO3 packets will be followed immediately. 164 For NVO3 header part, the following additional component types are 165 introduced. 167 Type TBD2 - VNID 169 Encoding: . 171 Defines a list of {operation, value} pairs used to match 24-bit VN 172 ID which is used as tenant identification in NVO3 network. For NVGRE 173 encapsulation, the VNID is equivalent to VSID. Values are encoded as 174 1- to 3-byte quantities. 176 Type TBD3 - Flow ID 178 Encoding: 180 Defines a list of {operation, value} pairs used to match 8-bit Flow 181 id fields which are only useful for NVGRE encapsulation. Values are 182 encoded as 1-byte quantity. 184 Other types: 186 The additional types for GENEVE [GENEVE],GUE [GUE] and GPE [GPE] 187 header specific part will be added later. 189 3. The Flow Specification Traffic Actions for NVO3 191 The current traffic filtering actions can still be used for NVO3 192 encapsulation traffic. For Traffic Marking, only the DSCP in outer 193 header can be modified. 195 4. Security Considerations 197 No new security issues are introduced to the BGP protocol by this 198 specification. 200 5. IANA Considerations 202 IANA is requested to create and maintain a new registry entitled: 204 "Flow spec NVO3 Component Types": 206 Type TBD1 - Delimiter type 208 Type TBD2 - VNID 210 Type TBD3 - Flow ID 212 5.1. Normative References 214 [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 [2] [GENEVE] J. Gross, T. Sridhar, etc, " Geneve: Generic Network 219 Virtualization Encapsulation", draft-ietf-nvo3-geneve-00, May 220 2015. 222 [3] [GUE] T. Herbert, L. Yong, O. Zia, " Generic UDP 223 Encapsulation", draft-ietf-nvo3-gue-01, Jun 2015. 225 [4] [GPE] P. Quinn,etc, " Generic Protocol Extension for VXLAN", 226 draft-ietf-nvo3-vxlan-gpe-00, May 2015. 228 5.2. Informative References 230 [1] [EVPN-Overlays] A. Sajassi,etc, " A Network Virtualization 231 Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-01 , 232 work in progress, February, 2014. 234 [2] [Inter-Overlays] J. Rabadan,etc, " Interconnect Solution for 235 EVPN Overlay networks", draft-ietf-bess-dci-evpn-overlay-01, 236 work in progress, July, 2015. 238 [3] [RFC7348] M. Mahalingam, etc, "Virtual eXtensible Local Area 239 Network (VXLAN): A Framework for Overlaying Virtualized Layer 240 2 Networks over Layer 3 Networks", RFC7348, August 2014. 242 [4] [NVGRE] P. Garg, etc, "NVGRE: Network Virtualization using 243 Generic Routing Encapsulation", draft-sridharan- 244 virtualization-nvgre-08, April 13, 2015. 246 [5] [IPv6-FlowSpec] R. Raszuk, etc, " Dissemination of Flow 247 Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6-06, 248 November 2014. 250 [6] [Layer2-FlowSpec] W. Hao, etc, "Dissemination of Flow 251 Specification Rules for L2 VPN", draft-ietf-idr-flowspec- 252 l2vpn-02, August 2015. 254 [7] [RFC5575] P. Marques, N. Sheth, R. Raszuk, B. Greene, J.Mauch, 255 D. McPherson, "Dissemination of Flow Specification Rules", RFC 256 5575, August 2009. 258 6. Acknowledgments 260 The authors wish to acknowledge the important contributions of Susan 261 Hares, Qiandeng Liang, Nan Wu, Yizhou Li. 263 Authors' Addresses 265 Weiguo Hao 266 Huawei Technologies 267 101 Software Avenue, 268 Nanjing 210012 269 China 270 Email: haoweiguo@huawei.com 272 Shunwan Zhuang 273 Huawei Technologies 274 Huawei Bld., No.156 Beiqing Rd. 275 Beijing 100095 276 China 277 Email: zhuangshunwan@huawei.com 279 Zhenbin Li 280 Huawei Technologies 281 Huawei Bld., No.156 Beiqing Rd. 282 Beijing 100095 283 China 284 Email: lizhenbin@huawei.com