idnits 2.17.1 draft-ietf-idr-flowspec-nvo3-00.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 (May 17, 2016) is 2900 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 163 -- Looks like a reference, but probably isn't: 'RFC5575' on line 163 -- Looks like a reference, but probably isn't: 'Layer2-FlowSpec' on line 163 == Unused Reference: '1' is defined on line 284, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 288, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 292, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 296, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 300, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 304, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 308, 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 (==), 5 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 R.Gu 6 China Mobile 7 Expires: November 2016 May 17, 2016 9 Dissemination of Flow Specification Rules for NVO3 10 draft-ietf-idr-flowspec-nvo3-00.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) 2016 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..................... 4 57 3. The Flow Specification Traffic Actions for NVO3.............. 6 58 4. Security Considerations...................................... 6 59 5. IANA Considerations ......................................... 6 60 5.1. Normative References.................................... 7 61 5.2. Informative References.................................. 7 62 6. Acknowledgments ............................................. 8 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] and [Layer2- 78 FlowSpec] extend the flow-spec rules for IPv6 and layer 2 Ethernet 79 packets respectively. All these flow specifications match parts only 80 reflect single layer IP/Ethernet information like source/destination 81 MAC, source/destination IP prefix, protocol type, ports, and etc. 83 In cloud computing era, multi-tenancy has become a core requirement 84 for data centers. Since NVO3 can satisfy multi-tenancy key 85 requirements, this technology is being deployed in an increasing 86 number of cloud data center network. NVO3 is an overlay technology, 87 VXLAN and NVGRE are two typical NVO3 encapsulations. GENEVE [draft- 88 ietf-nvo3-geneve-00],GUE[draft-ietf-nvo3-gue-01] and GPE [draft- 89 ietf-nvo3-vxlan-gpe-00] are three emerging NVO3 encapsulations in 90 progress. 92 +--+ 93 |CE| 94 +--+ 95 | 96 +----+ 97 +----| PE |----+ 98 +---------+ | +----+ | +---------+ 99 +----+ | +---+ +---+ | +----+ 100 |NVE1|--| | | | | |--|NVE3| 101 +----+ | |GW1| |GW3| | +----+ 102 | +---+ +---+ | 103 | NVO-1 | MPLS | NVO-2 | 104 | +---+ +---+ | 105 | | | | | | 106 +----+ | |GW2| |GW4| | +----+ 107 |NVE2|--| +---+ +---+ |--|NVE4| 108 +----+ +---------+ | | +---------+ +----+ 109 +--------------+ 110 Figure 1 NVO3 data center interconnection 112 The MPLS L2/L3 VPN in the WAN network can be used for NVO3 based 113 data center network interconnection. When the DC and the WAN are 114 operated by the same administrative entity, the Service Provider can 115 decide to integrate the GW and WAN Edge PE functions in the same 116 router for obvious CAPEX and OPEX saving reasons. This is 117 illustrated in Figure 1. There are two interconnection solutions as 118 follows: 120 1. End to end NVO3 tunnel across different data centers. NVE1 121 perform NVO3 encapsulation for DCI interconnection with NVE3, the 122 destination VTEP IP is NVE3's IP. The GW doesn't perform NVO3 tunnel 123 termination. The DCI WAN is pure underlay network. 125 2. Segmented NVO3 tunnels across different data centers. NVE1 126 doesn't perform end to end NVO3 encapsulation to NVE3 for DCI 127 interconnection. The GW performs NVO3 tunnel encapsulation 128 termination, and then transmits the inner original traffic through 129 MPLS network to peer data center GW. The peer data center GW 130 terminates MPLS encapsulation, and then performs NVO3 encapsulation 131 to transmit the traffic to local NVE3. 133 In the first solution, to differentiate bandwidth and QOS among 134 different tenants or applications, different TE tunnels in the WAN 135 network will be used to carry the end to end NVO3 encapsulation 136 traffic using VN ID, NVO3 outer header DSCP and etc as traffic 137 classification match part. BGP Flow-spec protocol can be used to set 138 the traffic classification on all GWs simultaneously. 140 In the second solution, a centralized BGP speaker can be deployed 141 for DDOS mitigation in the WAN network. When the analyzer detects 142 abnormal traffic, it will automatically generate Flow-spec rules and 143 distribute it to each GW through BGP Flow-spec protocol, the match 144 part should include inner or outer L2/L3 layer or NVO3 header. 146 In summary, the Flow specification match part on the GW/PE should 147 include inner layer 2 Ethernet header, inner layer 3 IP header, 148 outer layer 2 Ethernet header, outer layer 3 IP header, and/or NVO3 149 header information. Because the current match part lacks layer 150 indicator and NVO3 header information, so it can't be used directly 151 for the traffic filtering based on NVO3 header or a specified layer 152 header directly. This draft will propose a new subset of component 153 types to support the NVO3 flow-spec application. 155 2. The Flow Specification encoding for NVO3 157 In default, the current flow-spec rules can only impose on the outer 158 layer header of NVO3 encapsulation data packets. To make traffic 159 filtering based on NVO3 header and inner header of NVO3 packets, a 160 new component type acts as a delimiter is introduced. The delimiter 161 type is used to specify the boundary of the inner or outer layer 162 component types for NVO3 data packets. All the component types 163 defined in [RFC5575],[IPv6-FlowSpec],[Layer2-FlowSpec],and etc can 164 be used between two delimiters. 166 The NVO3 outer layer address normally belongs to public network, the 167 "Flow Specification" NLRI only for the outer layer header doesn't 168 need to include Route Distinguisher field (8 bytes). If the outer 169 layer address belongs to a VPN, the NLRI format for the outer header 170 should consist of a fixed-length Route Distinguisher field (8 bytes) 171 corresponding to the VPN, the RD is followed by the detail flow 172 specifications for the outer layer. 174 VN ID is the identification for each tenant network, the "Flow 175 Specification" NLRI for NVO3 header part should always include VN ID 176 field, Route Distinguisher field doesn't need to be included. 178 The inner layer MAC/IP address always associates with a VN ID, the 179 NLRI format for the inner header should consist of a fixed-length 180 VNID field (4 bytes), the VNID is followed by the detail flow 181 specifications for the inner layer. The NLRI length field shall 182 include both the 4 bytes of the VN ID as well as the subsequent flow 183 specification. In NVO3 terminating into VPN scenario, if multiple 184 access VN ID maps to one VPN instance, one share VN ID can be 185 carried in the Flow-Spec rule to enforce the rule to entire VPN 186 instance, the share VN ID and VPN correspondence should be 187 configured on each VPN PE beforehand, the function of the layer3 VN 188 ID is same with Route Distinguisher to act as the identification of 189 VPN instance. 191 This document proposes the following extended specifications for 192 NVO3 flow: 194 Type TBD1 - Delimiter type 196 Encoding: . 198 When the delimiter type is present, it indicates the component types 199 for the inner or outer layer of NVO3 packets will be followed 200 immediately. At the same time, it indicates the end of the component 201 types belonging to the former delimiter. 203 The value field defines encapsulation type and is encoded as: 205 0 1 2 3 4 5 6 7 206 +---+---+---+---+---+---+---+---+ 207 | Encap Type | 208 +---+---+---+---+---+---+---+---+ 209 | I | O | Resv | 210 +---+---+---+---+---+---+---+---+ 211 This document defines the following Encap types: 213 - VXLAN: Tunnel Type = 0 215 - NVGRE: Tunnel Type = 1 217 I: If I is set to one, it indicates the component types for the 218 inner layer of NVO3 packets will be followed immediately. 220 O: If O is set to one, it indicates the component types for the 221 outer layer of NVO3 packets will be followed immediately. 223 For NVO3 header part, the following additional component types are 224 introduced. 226 Type TBD2 - VNID 228 Encoding: . 230 Defines a list of {operation, value} pairs used to match 24-bit VN 231 ID which is used as tenant identification in NVO3 network. For NVGRE 232 encapsulation, the VNID is equivalent to VSID. Values are encoded as 233 1- to 3-byte quantities. 235 Type TBD3 - Flow ID 237 Encoding: 239 Defines a list of {operation, value} pairs used to match 8-bit Flow 240 id fields which are only useful for NVGRE encapsulation. Values are 241 encoded as 1-byte quantity. 243 3. The Flow Specification Traffic Actions for NVO3 245 The current traffic filtering actions can still be used for NVO3 246 encapsulation traffic. For Traffic Marking, only the DSCP in outer 247 header can be modified. 249 4. Security Considerations 251 No new security issues are introduced to the BGP protocol by this 252 specification. 254 5. IANA Considerations 256 IANA is requested to create and maintain a new registry entitled: 258 "Flow spec NVO3 Component Types": 260 Type TBD1 - Delimiter type 262 Type TBD2 - VNID 264 Type TBD3 - Flow ID 266 5.1. Normative References 268 [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, March 1997. 272 [2] [GENEVE] J. Gross, T. Sridhar, etc, " Geneve: Generic Network 273 Virtualization Encapsulation", draft-ietf-nvo3-geneve-00, May 274 2015. 276 [3] [GUE] T. Herbert, L. Yong, O. Zia, " Generic UDP 277 Encapsulation", draft-ietf-nvo3-gue-01, Jun 2015. 279 [4] [GPE] P. Quinn,etc, " Generic Protocol Extension for VXLAN", 280 draft-ietf-nvo3-vxlan-gpe-00, May 2015. 282 5.2. Informative References 284 [1] [EVPN-Overlays] A. Sajassi,etc, " A Network Virtualization 285 Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-01 , 286 work in progress, February, 2014. 288 [2] [Inter-Overlays] J. Rabadan,etc, " Interconnect Solution for 289 EVPN Overlay networks", draft-ietf-bess-dci-evpn-overlay-01, 290 work in progress, July, 2015. 292 [3] [RFC7348] M. Mahalingam, etc, "Virtual eXtensible Local Area 293 Network (VXLAN): A Framework for Overlaying Virtualized Layer 294 2 Networks over Layer 3 Networks", RFC7348, August 2014. 296 [4] [NVGRE] P. Garg, etc, "NVGRE: Network Virtualization using 297 Generic Routing Encapsulation", draft-sridharan- 298 virtualization-nvgre-08, April 13, 2015. 300 [5] [IPv6-FlowSpec] R. Raszuk, etc, " Dissemination of Flow 301 Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6-06, 302 November 2014. 304 [6] [Layer2-FlowSpec] W. Hao, etc, "Dissemination of Flow 305 Specification Rules for L2 VPN", draft-ietf-idr-flowspec- 306 l2vpn-02, August 2015. 308 [7] [RFC5575] P. Marques, N. Sheth, R. Raszuk, B. Greene, J.Mauch, 309 D. McPherson, "Dissemination of Flow Specification Rules", RFC 310 5575, August 2009. 312 6. Acknowledgments 314 The authors wish to acknowledge the important contributions of Jeff 315 Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, Lucy Yong. 317 Authors' Addresses 319 Weiguo Hao 320 Huawei Technologies 321 101 Software Avenue, 322 Nanjing 210012 323 China 324 Email: haoweiguo@huawei.com 326 Shunwan Zhuang 327 Huawei Technologies 328 Huawei Bld., No.156 Beiqing Rd. 329 Beijing 100095 330 China 331 Email: zhuangshunwan@huawei.com 333 Zhenbin Li 334 Huawei Technologies 335 Huawei Bld., No.156 Beiqing Rd. 336 Beijing 100095 337 China 338 Email: lizhenbin@huawei.com 340 Rong Gu 341 China Mobile 342 gurong_cmcc@outlook.com