idnits 2.17.1 draft-ietf-idr-flowspec-nvo3-08.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 (January 16, 2020) is 1561 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) ** Downref: Normative reference to an Informational RFC: RFC 7348 ** Downref: Normative reference to an Informational RFC: RFC 7637 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: July 15, 2020 January 16, 2020 11 BGP Dissemination of 12 Flow Specification Rules for Tunneled Traffic 13 draft-ietf-idr-flowspec-nvo3-08 15 Abstract 16 This draft specifies a Border Gateway Protocol Network Layer 17 Reachability Information (BGP NLRI) encoding format for flow 18 specifications (RFC 5575bis) that can match on a variety of tunneled 19 traffic. In addition, flow specification components are specified for 20 certain tunneling header fields. 22 Status of This Document 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Distribution of this document is unlimited. Comments should be sent 28 to the authors or the IDR Working Group mailing list . 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 42 Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Table of Contents 47 1. Introduction............................................3 48 1.1 Terminology............................................3 50 2. Tunneled Traffic Flow Specification NLRI................5 51 2.1 The SAFI Code Point....................................7 52 2.2 Tunnel Header Component Code Points....................8 53 2.3 Specific Tunnel Types..................................9 54 2.3.1 VXLAN................................................9 55 2.3.2 VXLAN-GPE...........................................10 56 2.3.3 NVGRE...............................................11 57 2.3.4 L2TPv3..............................................11 58 2.3.5 GRE.................................................12 59 2.3.6 IP-in-IP............................................12 60 2.4 Tunneled Traffic Actions..............................12 62 3. Order of Traffic Filtering Rules.......................13 63 4. Flow Spec Validation...................................14 65 5. Security Considerations................................14 66 6. IANA Considerations....................................14 68 Normative References......................................15 69 Informative References....................................16 71 Acknowledgments...........................................17 72 Authors' Addresses........................................17 74 1. Introduction 76 BGP Flow-spec [RFC5575bis] is an extension to BGP that supports the 77 dissemination of traffic flow specification rules. It uses the BGP 78 control plane to simplify the distribution of Access Control Lists 79 (ACLs) and allows new filter rules to be injected to all BGP peers 80 simultaneously without changing router configuration. A typical 81 application of BGP Flow-spec is to automate the distribution of 82 traffic filter lists to routers for Distributed Denial of Service 83 (DDOS) mitigation. 85 BGP Flow-spec defines a BGP Network Layer Reachability Information 86 (NLRI) format used to distribute traffic flow specification rules. 87 AFI=1/SAFI=133 is for IPv4 unicast filtering. AFI=1/SAFI=134 is for 88 IPv4 BGP/MPLS VPN filtering. [FlowSpecV6] and [FlowSpecL2] extend the 89 flow-spec rules for IPv6 and layer 2 Ethernet packets respectively. 90 None of these previous flow specifications are suitable for matching 91 in cases of tunneling or encapsulation where there might be 92 duplicates of a layer of header such as two IPv6 headers in IP-in-IP 93 or a nested header sequence such as the layer 2 and 3 headers 94 encapsulated in VXLAN [RFC7348]. 96 In the cloud computing era, multi-tenancy has become a core 97 requirement for data centers. It is increasingly common to see 98 tunneled traffic with a field to distinguish tenants. An example is 99 the Network Virtualization Over Layer 3 (NVO3 [RFC8014]) overlay 100 technology that can satisfy multi-tenancy key requirements. VXLAN 101 [RFC7348] and NVGRE [RFC7637] are two typical NVO3 encapsulations. 102 Other encapsulations such as IP-in-IP or GRE may be encountered. 103 Because these tunnel / overlay technologies involving an additional 104 level of encapsulation, flow specification that can match on the 105 inner header as well as the outer header are needed. 107 In summary, Flow specifications should be able to include inner 108 nested header information as well as fields specific to the type of 109 tunneling in use such as virtual network / tenant ID. This draft 110 specifies methods for accomplishing this using SAFI=TBD1 and a new 111 NLRI encoding. 113 1.1 Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 The reader is assumed to be familiar with BGP terminology. The 122 following terms and acronyms are used in this document with the 123 meaning indicated: 125 ACL - Access Control List 127 DDOS - Distributed Denial of Service (Attack) 129 DSCP - Differentiated Services Code Point 131 GRE - Generic Router Encapsulation [RFC2890] 133 L2TPv3 - Layer Two Tunneling Protocol - Version 3 [RFC3931] 135 NLRI - Network Layer Reachability Information 137 NVGRE - Network Virtualization Using Generic Routing Encapsulation 138 [RFC7637] 140 NVO3 - Network Virtual Overlay Layer 3 [RFC8014] 142 VN - virtual network 144 VXLAN - Virtual eXtensible Local Area Network [RFC7348] 146 2. Tunneled Traffic Flow Specification NLRI 148 The Flow-spec rules specified in [RFC5575bis], [FlowSpecV6], and 149 [FlowSpecL2] cannot match or filter tunneled traffic based on the 150 tunnel type, any tunnel header fields, or headers past the tunnel 151 header. To enable flow specification of tunneled traffic, a new SAFI 152 (TBD1) and NLRI encoding are introduced. This encoding, shown in 153 Figure 1, enables flow specification of more than one layer of header 154 when needed. 156 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 157 | Length 2 octets | 158 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 159 | Tunnel Type 2 octets | 160 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 161 Flags: 162 +--+--+--+--+--+--+--+--+ 163 | D| I| Reserved | 1 octet 164 +--+--+--+--+--+--+--+--+ 165 Optional Routing Discriminator: 166 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 167 | | 168 + + 169 | | 170 + Routing Discriminator 8 octets + 171 | | 172 + + 173 | | 174 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 175 Outer Flow-spec: 176 +--+--+--+--+--+--+--+--+ 177 | Outer Flowspec Length : 1 or 2 octets 178 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 179 | Outer Flow-spec variable : 180 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 181 Tunnel Header Flow-Spec: 182 +--+--+--+--+--+--+--+--+ 183 | Tunnel Flowspec Length: 1 or 2 octets 184 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 185 | Tunnel Header Flow-spec variable : 186 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 187 Optional Inner Flow-spec: 188 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 189 | Inner AFI 2 octets | 190 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 191 | Inner Flowspec Length : 1 or 2 octets 192 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 193 | Inner Flow-spec variable : 194 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 196 Figure 1. Tunneled Traffic Flow-spec NLRI 198 Length - The NLRI Length including the Tunnel Type encoded as an 199 unsigned integer. 201 Tunnel Type - The type of tunnel using a value from the IANA BGP 202 Tunnel Encapsulation Attribute Tunnel Types registry. 204 Flags: D bit - Indicates the presence of the Routing Discriminator 205 (see below). 207 Flags: I bit - Indicates the presence of the Inner AFI and the Inner 208 Flow-spec. 210 Flags: Reserved - Six bits that MUST be sent as zero and ignored on 211 receipt. 213 Routing Discriminator - If the outer Layer 3 address belongs to a 214 BGP/MPLS VPN, the routing discriminator can be included to 215 support traffic filtering within that VPN. Because NVO3 outer 216 layer addresses normally belong to a public network, a Route 217 Distinguisher field is normally not needed for NVO3. 219 Outer Flow-spec / Length - The flow specification for the outer 220 header. The length is encoded as provided in Section 4.1 of 221 [RFC5575bis]. The AFI for the outer Flow-spec is that AFI at 222 the beginning of the BGP multiprotocol MP_REACH_NLRI or 223 MP_UNREACH_NLRI containing the tunneled traffic flow 224 specification NLRI. 226 Tunnel Header Flow-spec / Length - The flow specification for the 227 tunneling header. This can specify matching criterion on tunnel 228 header fields. The tunnel type itself is indicated by the 229 Tunnel Type field above. For some types of tunneling, such as 230 IP-in-IP, there may be no tunnel header fields. For other types 231 of tunneling, there may be several tunnel header fields on 232 which matching could be specified with this Flow-spec. 234 Inner AFI - Depending on the Tunnel Type, there may be an Inner AFI 235 that indicates the address family for the inner flow 236 specification. There is no need for a SAFI as, in effect, it 237 is automatically TBD1, the SAFI for a tunneled traffic flow 238 specification. 240 Inner Flow-spec / Length - Depending on the Tunnel Type, there may be 241 an inner flow specification for the header level encapsulated 242 within the outer header. The length is encoded as provided in 243 Section 4.1 of [RFC5575bis]. 245 A Tunneled Traffic Flow-spec matches if the Outer Flow-spec, Tunnel 246 Header Flow-spec, and Inner Flow-spec all match and the Routing 247 Discriminator applies, if present. An omitted (as can be done for the 248 Inner Flow-spec) or null Flow-spec is considered to always match. 250 2.1 The SAFI Code Point 252 Use of the tunneled traffic flow specification NLRI format is 253 indicated by SAFI=TBD1. This is used in conjunction with the AFI for 254 the outer header, that is AFI=1 for IPv4, AFI=2 for IPv6, and AFI=6 255 for Layer 2. 257 2.2 Tunnel Header Component Code Points 259 For flow specification based on most tunneling headers, there are 260 additional tunnel header fields that can be tested by components that 261 appear in the Tunnel Header Flow-spec field. The types for these 262 components are specified in a Tunnel Header Flow-spec component 263 registry (see Section 6). 265 All Tunnel Header field components defined below and all such 266 components added in the future have a TLV structure as follows: 267 - one octet of type followed by 268 - one octet giving the length as an unsigned integer number of 269 octets followed by 270 - the specific matching operations/values as determined by the 271 type. 273 Type 1 - VN ID 274 Encoding: . 276 Defines a list of {operation, value} pairs used to match the 277 24-bit VN ID that is used as the tenant identification in some 278 tunneling headers. For VXLAN encapsulation, the VN ID is the 279 VNI. For NVGRE encapsulation, the VN ID is the VSID. op is 280 encoded as specified in Section 4.2.3 of [RFC5575bis]. Values 281 are encoded as a 1, 2, or 4 octet quantity. If value is 282 24-bits, they are left-justified in the first 3 octets of the 283 value and the last value octet MUST be sent as zero and ignored 284 on receipt. 286 Type 2 - Flow ID 287 Encoding: 289 Defines a list of {operation, value} pairs used to match 8-bit 290 Flow ID fields which are currently only useful for NVGRE 291 encapsulation. op is encoded as specified in Section 4.2.3 of 292 [RFC5575bis]. Values are encoded as a 1-octet quantity. 294 Type 3 - Session 295 Encoding: 297 Defines a list of {operation, value} pairs used to match a 298 32-bit Session field. This field is called Key in GRE [RFC2890] 299 encapsulation and Session ID in L2TPv3 encapsulation. op is 300 encoded as specified in Section 4.2.3 of [RFC5575bis]. Values 301 are encoded as a 1, 2, or 4 octet quantity. 303 Type 4 - Cookie 304 Encoding: 306 Defines a list of {operation, value} pairs used to match a 307 variable length Cookie field. This is only useful in L2TPv3 308 encapsulation. op is encoded as specified in Section 4.2.3 of 309 [RFC5575bis]. Values are encoded as a 1, 2, 4, or 8 octet 310 quantity. If the Cookie does not fit exactly into the value 311 length, it is left justified, that is, padded with following 312 octets the MUST be sent as zero and ignored on receipt. 314 Type 5 - VXLAN-GPE Flags 315 Encoding: 317 Defines a list of {operation, value} pairs used to match 318 against the VXLAN-GPE flags field. op is encoded as in Section 319 4.2.9 of [RFC5575bis]. bitmask is encoded as 1 octet. 321 2.3 Specific Tunnel Types 323 The following subsections describe how to handle flow specification 324 for several specific tunnel types. 326 2.3.1 VXLAN 328 The headers on a VXLAN [RFC7348] data packet are an outer Ethernet 329 header, an outer IP header, a UDP header, the VXLAN header, and an 330 inner Ethernet header. This inner Ethernet header is frequently, but 331 not always, followed by an inner IP header. If the tunnel type is 332 VXLAN, the I flag MUST be set. 334 If the outer Ethernet header is not being matched, the version (IPv4 335 or IPv6) of the outer IP header is indicated by the AFI at the 336 beginning of the multiprotocol MP_REACH_NLRI or MP_UNREACH_NLRI 337 containing the tunneled traffic flow specification NLRI. The outer 338 Flow-spec is used to filter the outer headers including, if desired, 339 the UDP header. 341 If the outer Ethernet header is being matched, then the initial AFI 342 is 6 [FlowSpecL2] and the Outer Flow-spec can match the outer 343 Ethernet header, specify the IP version of the outer IP header, and 344 match that IP header including, if desired, the UDP header. 346 The Tunnel Header Flow-spec can be used to filter on the VXLAN header 347 VN ID (VNI). 349 The inner Flow-spec can be used on the Inner Ethernet header 350 [FlowSpecL2] and any following IP header. If the inner AFI is 6, 351 then the inner Flow-spec provides filtering of the Layer 2 header, 352 indicates whether filtering on a following IPv4 or IPv6 header is 353 desired, and if it is desired provides the Flow-spec components for 354 that filtering. If the Inner AFI is 1 or 2, the Inner Ethernet 355 header is not matched and to match the Flow-spec the Inner Ethernet 356 header must be followed by an IPv4 or IPv6 header, respectively, and 357 the inner Flow-spec is used to filter that inner IP header. 359 The inner MAC/IP address is associated with a VN ID. In the NVO3 360 terminating into a VPN scenario, if multiple access VN IDs map to one 361 VPN instance, one shared VN ID can be carried in the Flow-Spec rule 362 to enforce the rule on the entire VPN instance and the shared VN ID 363 and VPN correspondence should be configured on each VPN PE 364 beforehand. In this case, the function of the Layer 3 VN ID is the 365 same as a Route Discriminator: it acts as the identification of the 366 VPN instance. 368 2.3.2 VXLAN-GPE 370 VXLAN-GPE [GPE] is similar to VXLAN and the VXLAN-GPE header is the 371 same size as the VXLAN header but has been extended from the VXLAN 372 header by specifying a number of bits that are reserved in the VXLAN 373 header. In particular, a number of additional flag bits are specified 374 and a Next Protocol field is added that is valid if the P flag bit is 375 set. These flags bits can be tested using the VXLAN-GPE Flags 376 component defined above. VXLAN and VXLAN-GPE are distinguished by the 377 port number in the UDP header the precedes the VXLAN or VXLAN-GPE 378 headers. 380 If the VXLAN-GPE header P flag is zero, then that header is followed 381 by the same sequence as for VXLAN and the same Flow-spec choices 382 apply (see Section 2.3.1). 384 If the VXLAN-GPE header P flag is one and that header's next protocol 385 field is 1, then the VXLAN-GPE header is followed by an IPv4 header. 386 The inner AFI/Flow-spec match only if the inner AFI is 1 and the 387 inner Flow-spec matches. 389 If the VXLAN-GPE header P flag is one and that header's next protocol 390 field is 2, then the VXLAN-GPE header is followed by an IPv6 header. 391 The inner AFI/Flow-spec match only if the inner AFI is 2 and the 392 inner Flow-spec matches. 394 2.3.3 NVGRE 396 NVGRE [RFC7637] is very similar to VXLAN except that the UDP header 397 and VXLAN header immediately after the outer IP header are replaced 398 by a GRE (Generic Router Encapsulation) header. The GRE header as 399 used in NVGRE has no Checksum or Reserved1 field as shown in 400 [RFC2890] but there are Virtual Subnet ID and Flow ID fields in place 401 of what is labeled in [RFC2890] as the Key field. Processing and 402 restrictions for NVGRE are as in Section 2.3.1 eliminating references 403 to a UDP header and replacing references to the VXLAN header and its 404 VN ID with references to the GRE header and its VN ID (VSID) and Flow 405 ID. 407 2.3.4 L2TPv3 409 The headers on an L2TPv3 [RFC3931] packets are an outer Ethernet 410 header, an outer IP header, the L2TPv3 header, an inner Ethernet 411 header, and possibly an inner IP header if indicated by the inner 412 Ethernet header EtherType. The outer Flow-spec operates on the outer 413 headers that precede the GRE header. The version of IP is specified 414 by the outer AFI at the beginning of the MP_REACH_NLRI or 415 MP_UNREACH_NLRI. 417 The L2TPv3 header consists of a 32-bit Session ID followed by a 418 variable length Cookie (maximum length 8 octets). The Session ID and 419 Cookie can be filtered for by using the Session and Cookie Flow-spec 420 components in the Tunnel Header Flow-spec. To filter on Cookie or 421 even be able to bypass Cookie and parse the remainder of the L2TPv3 422 packet, the node implementing Flow-spec needs to know the length 423 and/or value of the Cookie fields of interest. This is negotiated at 424 L2TPv3 session establishment and it is out of scope for this document 425 how the node would learn this information. Of course, if Flow-spec is 426 being used for DDOS mitigation and the Cookie has a fixed length 427 and/or value in the DDOS traffic, this could be learned by inspecting 428 that traffic. 430 If the I flag bit is zero, then no filtering is done on data beyond 431 the L2TPv3 header. If the I flag is one, indicating the presence of 432 an inner Flow-spec, and the node implementing Flow-spec does not know 433 the length of the L2TPv3 header Cookie, the match fails. If that node 434 does know the length of that Cookie, the inner Flow-spec if matched 435 against the headers at the beginning of that data using the inner 436 AFI. If the inner AFI is 1 or 2, then an inner IP header is required 437 and filtering can be done on the Ethernet header immediately after 438 the L2TPv3 header and the following IPv4 or IPv6 headers 439 respectively. If the inner AFI is 6, filtering SHOULD only be done on 440 the inner Ethernet header [FlowSpecL2]. 442 2.3.5 GRE 444 Generic Router Encapsulation (GRE [RFC2890]) is another type of 445 encapsulation. The outer Flow-spec operates on the outer headers that 446 precede the GRE header. The version of IP is specified by the outer 447 AFI at the beginning of the MP_REACH_NLRI or MP_UNREACH_NLRI. 449 If the I flag bit is zero, no filtering is done on data after the GRE 450 header. If the I flag bit is one, then there is an inner AFI and 451 Flow-spec and the Protocol Type field of the GRE header must match 452 the inner AFI as follows for the Flow-spec to match: 454 GRE Protocol Type Inner AFI 455 ------------------- ----------- 456 0x0800 (IPv4) 1 457 0x86DD (IPv6) 2 458 0x6558 6 460 With the I flag a one and the inner AFI and GRE Protocol Type fields 461 match, the inner Flow-spec is used to filter the inner Ethernet 462 header (AFI=6) or the inner IP and Ethernet headers (AFI=1 or 2). 464 2.3.6 IP-in-IP 466 IP-in-IP encapsulation is shown when the outer IP header indicates an 467 inner IP IPv4 or IPv6 header by the value of the outer IP header's 468 Protocol (IPv4) or Next Protocol (IPv6) field. If the Tunnel Type is 469 IP-in-IP, the I flag MUST be set. 471 The version of the outer IP header (IPv4 or IPv6) matched is 472 indicated by the AFI at the beginning of the MP_REACH_NLRI or 473 MP_UNREACH_NLRI. The version of the inner IP header is indicated by 474 the inner AFI. The outer Flow-spec applies to the outer IP header and 475 the inner Flow-spec applies to the inner IP header. 477 There are no fields that can be matched by the Tunnel Header Flow- 478 spec in the case of IP-in-IP. 480 2.4 Tunneled Traffic Actions 482 The traffic filtering actions previously specified in [RFC5575bis] 483 and [FlowSpecL2] are used for tunneled traffic. For Traffic Marking 484 in NVO3, only the DSCP in the outer header can be modified. 486 3. Order of Traffic Filtering Rules 488 In comparing an applicable tunneled traffic flow specification with a 489 non-tunneled flow specification, the tunneled specification has 490 precedence. 492 If comparing two tunneled traffic flow specifications, if both are 493 applicable, the tunnel types will be the same. If only one has a 494 Routing Discriminator, it has precedence. If both have a Routing 495 Discriminator, then either those Routing Discriminators will be equal 496 or only one of the Flow-specs will be applicable to the packet. 498 If neither has a Routing Discriminator or they have equal Routing 499 Discriminators, the order of precedence is determined by comparing 500 the outer Flow-spec. 502 If the outer Flow-specs are equal, then the Tunnel Header Flow-specs 503 are compared using the usual component comparison rules. 505 If the Tunnel Header Flow-specs are equal and the tunnel type calls 506 for an inner Flow-spec, then the precedence is determined by 507 comparing inner AFI as an unsigned integer with the inner AFI having 508 the smaller magnitude having precedence. 510 If the inner AFIs are equal, precedence is determined by comparing 511 the inner flow specifications. 513 4. Flow Spec Validation 515 Flow-specs received over AFI=1/SAFI=TBD1 or AFI=2/SFAI=TBD1 are 516 validated, using only the outer Flow-spec, against routing 517 reachability received over AFI=1/SAFI=133 and AFI=2/SAFI=133 518 respectively, as modified by [FlowSpecOID]. 520 5. Security Considerations 522 No new security issues are introduced to the BGP protocol by this 523 specification. 525 For general Flow-spec security considerations, see [rfc5575bis]. 527 6. IANA Considerations 529 IANA is requested to assign a new SAFI as follows: 531 Value Description Reference 532 ----- ------------------------------------------ --------------- 533 TBD1 Tunneled traffic flow specification rules [This document] 535 IANA is requested to create a Tunnel Header Flow Spec Component Type 536 registry on the Flow Spec Component Types registries web page as 537 follows: 539 Name: Tunnel Flow Spec Component Types 540 Reference: [this document] 541 Registration Procedures: 542 0 Reserved 543 1-127 Specification Required 544 128-254 First Come First Served 545 255 Reserved 547 Initial contents: 548 Type Name Reference 549 ----- -------------- ----------- 550 0 reserved 551 1 VN ID [this document] 552 2 Flow ID [this document] 553 3 Session [this document] 554 4 Cookie [this document] 555 5 VXLAN-GPE Flags [this document] 556 6-254 unassigned [this document] 557 255 reserved [this document] 559 Normative References 561 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 563 March 1997, . 565 [RFC2890] - Dommety, G., "Key and Sequence Number Extensions to GRE", 566 RFC 2890, DOI 10.17487/RFC2890, September 2000, 567 . 569 [RFC3931] - Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 570 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, 571 DOI 10.17487/RFC3931, March 2005, . 574 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 575 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 576 eXtensible Local Area Network (VXLAN): A Framework for 577 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 578 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 581 [RFC7637] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network 582 Virtualization Using Generic Routing Encapsulation", RFC 7637, 583 DOI 10.17487/RFC7637, September 2015, . 586 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 587 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 588 2017, . 590 [FlowSpecL2] - W. Hao, et al, "Dissemination of Flow Specification 591 Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in 592 progress. 594 [FlowSpecOID] - J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P. 595 Mohapatra, "Revised Validation Procedure for BGP Flow 596 Specifications", draft-ietf-idr-bgp-flowspec-oid, work in 597 progress. 599 [FlowSpecV6] - R. Raszuk, et al, "Dissemination of Flow Specification 600 Rules for IPv6", draft-ietf-idr-flow-spec-v6, work in progress. 602 [RFC5575bis] - Hares, S., Loibl, C., Raszuk, R., McPherson, D., 603 Bacher, M., "Dissemination of Flow Specification Rules", draft- 604 ietf-idr-rfc5575bis, Work in progress. 606 Informative References 608 [RFC8014] - Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 609 Narten, "An Architecture for Data-Center Network Virtualization 610 over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December 611 2016, . 613 [GPE] - P. Quinn, et al, "Generic Protocol Extension for VXLAN", 614 draft-ietf-nvo3-vxlan-gpe, work in progress. 616 Acknowledgments 618 The authors wish to acknowledge the important contributions of Jeff 619 Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, Robert Raszuk, 620 and Lucy Yong. 622 Authors' Addresses 624 Donald Eastlake 625 Futurewei Technologies 626 2386 Panoramic Circle 627 Apopka, FL 32703 USA 629 Tel: +1-508-333-2270 630 Email: d3e3e3@gmail.com 632 Weiguo Hao 633 Huawei Technologies 634 101 Software Avenue, 635 Nanjing 210012 China 637 Email: haoweiguo@huawei.com 639 Shunwan Zhuang 640 Huawei Technologies 641 Huawei Bld., No.156 Beiqing Rd. 642 Beijing 100095 China 644 Email: zhuangshunwan@huawei.com 646 Zhenbin Li 647 Huawei Technologies 648 Huawei Bld., No.156 Beiqing Rd. 649 Beijing 100095 China 651 Email: lizhenbin@huawei.com 653 Rong Gu 654 China Mobile 656 Email: gurong_cmcc@outlook.com 658 Copyright, Disclaimer, and Additional IPR Provisions 660 Copyright (c) 2020 IETF Trust and the persons identified as the 661 document authors. All rights reserved. 663 This document is subject to BCP 78 and the IETF Trust's Legal 664 Provisions Relating to IETF Documents 665 (http://trustee.ietf.org/license-info) in effect on the date of 666 publication of this document. Please review these documents 667 carefully, as they describe your rights and restrictions with respect 668 to this document. Code Components extracted from this document must 669 include Simplified BSD License text as described in Section 4.e of 670 the Trust Legal Provisions and are provided without warranty as 671 described in the Simplified BSD License.