INTERNET-DRAFT                                               D. Eastlake
Intended Status: Proposed Standard                Futurewei Technologies
                                                                  W. Hao
                                                               S. Zhuang
                                                                   Z. Li
                                                     Huawei Technologies
                                                                   R. Gu
                                                             China Mobil
Expires: NJanuary 7, May 3, 2020                                   July 8,                                    November 4, 2019

                          BGP Dissemination of
    Network Virtualization Overlays (NVO3)
             Flow Specification Rules
                 <draft-ietf-idr-flowspec-nvo3-06.txt> for Tunneled Traffic
                    draft-ietf-idr-flowspec-nvo3-07

Abstract
   This draft specifies a new subset Border Gateway Protocol Network Layer
   Reachability Information (BGP NLRI) encoding format for flow
   specifications (RFC 5575bis) that can match on a variety of component types to support the
   (Network Virtualization Overlays (NVO3)) flow-spec application. tunneled
   traffic. In addition, flow specification components are specified for
   certain tunneling header fields.

Status of This Document

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Distribution of this document is unlimited. Comments should be sent
   to the authors or the TRILL IDR Working Group mailing list
   <dnsext@ietf.org>. <idr@ietf.org>.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
   Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

INTERNET-DRAFT                                        NVO3                                      BGP Tunnel Flow-Spec

Table of Contents

      1. Introduction............................................3
      1.1 Terminology............................................5 Terminology............................................3

      2. NVO3 Tunneled Traffic Flow Specification Encoding........................6 NLRI................5
      2.1 SAFI Code Point........................................6
      2.2 Component Code Points..................................6
      2.3 Specific Tunnel Types..................................8
      2.3.1 VXLAN................................................8
      2.3.2 VXLAN-GPE............................................8
      2.3.3 NVGRE................................................9
      2.3.4 L2TPv3...............................................9
      2.3.5 GRE.................................................10
      2.3.6 IP-in-IP............................................10
      2.4 Tunneled Traffic Actions..............................11

      3. NVO3 Flow Specification Order of Traffic Actions.................8 Filtering Rules.......................12
      4. Security Considerations.................................8 Flow Spec Validation...................................13

      5. Security Considerations................................13
      6. IANA Considerations.....................................8 Considerations....................................13

      Normative References.......................................9 References......................................14
      Informative References.....................................9

      Acknowledgments...........................................11 References....................................15

      Acknowledgments...........................................16
      Authors' Addresses........................................11 Addresses........................................16

INTERNET-DRAFT                                        NVO3                                      BGP Tunnel Flow-Spec

1. Introduction

   BGP Flow-spec [RFC5575bis] is an extension to BGP that supports the
   dissemination of traffic flow specification rules.  It uses the BGP Control Plane
   control plane to simplify the distribution of Access Control Lists
   (ACLs) and allows new filter rules to be injected to all BGP peers
   simultaneously without changing router configuration. A typical
   application of BGP Flow-spec is to automate the distribution of
   traffic filter lists to routers for Distributed Denial of Service
   (DDOS) mitigation.

   [RFC5575bis]

   BGP Flow-spec defines a new BGP Network Layer Reachability Information
   (NLRI) format used to distribute traffic flow specification rules.
   NLRI (AFI=1, SAFI=133)
   AFI=1/SAFI=133 is for IPv4 unicast filtering. NLRI (AFI=1,
   SAFI=134) AFI=1/SAFI=134 is for
   IPv4 BGP/MPLS VPN filtering. [IPv6-FlowSpec] [FlowSpecV6] and [Layer2- FlowSpec]
   extend the flow-spec rules for IPv6 and layer 2 Ethernet packets
   respectively. All these previous flow specifications match only a
   single layer level of IP/Ethernet information fields like
   source/destination MAC, such as
   source/destination IP prefix, protocol type, source/destination MAC,
   ports, EtherType and the like.

   In the cloud computing era, multi-tenancy has become a core
   requirement for data centers. Since It is increasingly common to see
   tunneled traffic with a field to distinguish tenants. An example is
   the Network Virtualization Overlays Over Layer 3 (NVO3 [RFC8014]) overlay
   technology that can satisfy multi-tenancy key requirements, this
   technology is being deployed in an increasing number of cloud data
   center networks. NVO3 is an overlay technology and requirements. VXLAN
   [RFC7348] and NVGRE [RFC7367] [RFC7637] are two typical NVO3 encapsulations. GENEVE
   [GENEVE], GUE [GUE] and GPE [GPE] are three emerging NVO3
   encapsulations.
   Other encapsulations such as IP-in-IP or GRE may be encountered.
   Because it is an these tunnel / overlay technology technologies involving an additional
   level of encapsulation, flow specification matching that can match on the
   inner header as well as the outer header, as specified below, is header are needed.

INTERNET-DRAFT                                        NVO3 BGP Flow-Spec

                                +--+
                                |CE|
                                +--+
                                  |
                               +----+
                          +----| PE |----+
              +---------+ |    +----+    | +---------+
      +----+  |        +---+            +---+        |  +----+
      |NVE1|--|        |   |            |   |        |--|NVE3|
      +----+  |        |GW1|            |GW3|        |  +----+
              |        +---+            +---+        |
              |  NVO-1   |      MPLS      |   NVO-2  |
              |        +---+            +---+        |
              |        |   |            |   |        |
      +----+  |        |GW2|            |GW4|        |  +----+
      |NVE2|--|        +---+            +---+        |--|NVE4|
      +----+  +---------+ |              | +---------+  +----+
                          +--------------+

                Figure 1. NVO3 Data Center Interconnection

   The MPLS L2/L3 VPN in

   In summary, the WAN network can Flow specifications should be used for NVO3 based data
   center network interconnection. When the Data Center (DC) and the WAN
   are operated by the same administrative entity, the Service Provider
   can decide able to include inner
   nested header information as well as fields specific to integrate the gateway (GW) and WAN Edge PE functions type of
   tunneling in
   the same router use such as virtual network / tenant ID. This draft
   specifies methods for capital accomplishing this using SAFI=TBD1 and operational cost saving reasons. This
   is illustrated a new
   NLRI encoding.

1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in Figure 1. There this document are two interconnection solutions
   as follows:

   1. End-to-end NVO3 tunnel across different data centers: NVE1
      performs NVO3 encapsulation for DC interconnection with NVE3. The
      destination VTEP IP is NVE3's IP. The GW doesn't perform NVO3
      tunnel termination.  The DC interconnect WAN is pure an underlay
      network.

   2. Segmented NVO3 tunnels across different data centers: NVE1 doesn't
      perform end-to-end NVO3 encapsulation to NVE3 for DC
      interconnection.  The GW performs NVO3 tunnel encapsulation
      termination, and then transmits the inner original traffic through
      an MPLS network to the peer data center GW. The peer data center
      GW terminates MPLS encapsulation, and then performs NVO3
      encapsulation to transmit the traffic to the local NVE3.

   In the first solution, to differentiate bandwidth and Quality of
   Service (QoS) among different tenants or applications, different
   traffic engneered tunnels in the WAN network will be used to carry
   the end-to-end NVO3 encapsulation traffic using VN ID, NVO3 outer
   header DSCP, and other fields as the traffic classification match
   part. The BGP Flow-spec protocol can be used to set the traffic
   classification on all GWs simultaneously.

INTERNET-DRAFT                                        NVO3 BGP Flow-Spec

   In the second solution, a centralized BGP speaker can be deployed for
   DDOS mitigation in the WAN network. When the analyzer detects
   abnormal traffic, it will automatically generate Flow-spec rules and
   distribute them to each GW through the BGP Flow-spec protocol, the
   match part should include matching on inner or outer L2/L3 layer or
   NVO3 headers.

   In summary, the Flow specification match part on the GW/PE should be
   able to include inner layer 2 Ethernet header, inner layer 3 IP
   header, outer layer 2 Ethernet header, outer layer 3 IP header,
   and/or NVO3 header information. Because the current flow-spec
   matching facilities lack a layer indicator and NVO3 header
   information, those facilities can't be used directly for traffic
   filtering based on NVO3 headers or on a specified layer header
   directly. This draft specifies a new subset of component types to
   support the NVO3 flow-spec application.

1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

INTERNET-DRAFT                                      BGP Tunnel Flow-Spec

   The reader is assumed to be familiar with BGP and NVO3 terminology. The
   following terms and acronyms are used in this document with the
   meaning indicated:

   ACL - Access Control List

   DC - Data Center

   DDOS - Distributed Denial of Service (Attack)

   DSCP - Differentiated Services Code Point

   GW

   GRE - gateway

   VN Generic Router Encapsulation [RFC2890]

   L2TPv3 - virtual network

   VTEP Layer Two Tunneling Protocol - Virtual Tunnel End Point

   WAN Version 3 [RFC3931]

   NLRI - wide area network

INTERNET-DRAFT Network Layer Reachability Information

   NVGRE - Network Virtualization Using Generic Routing Encapsulation
      [RFC7637]

   NVO3 - Network Virtual Overlay Layer 3 [RFC8014]

   VN - virtual network

   VXLAN - Virtual eXtensible Local Area Network [RFC7348]

INTERNET-DRAFT                                      BGP Tunnel Flow-Spec

2. NVO3 Tunneled Traffic Flow Specification Encoding NLRI

   The current Flow-spec rules in [RFC5575bis], [FlowSpecV6], and [FlowSpecL2]
   can only recognize flows based on the
   outer layer header one level of NVO3 encapsulation header in a data packets.
   packet. To enable
   traffic filtering based on an NVO3 header and on an inner header flow specification of
   NVO3 packets, tunneled traffic, a new component type acting as a delimiter is SAFI
   (TBD1) and NLRI encoding are introduced. This encoding, shown in
   Figure 1, enables flow specification of more than one layer of header
   when needed.

         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         | Length                          2 bytes       |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         | Tunnel Type                     2 bytes       |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       Flags:
         +--+--+--+--+--+--+--+--+
         | D| I| Reserved        |         1 byte
         +--+--+--+--+--+--+--+--+
       Optional Routing Discriminator:
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         |                                               |
         +                                               +
         |                                               |
         + Routing Discriminator           8 bytes       +
         |                                               |
         +                                               +
         |                                               |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       Outer Flow-spec:
         +--+--+--+--+--+--+--+--+
         | Outer Flowspec Length :         1 or 2 bytes
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         | Outer Flowspec                  variable      :
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       Optional Inner Flow-spec:
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         | Inner AFI                       2 bytes       |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         | Inner Flowspec Length :         1 or 2 bytes
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         | Inner Flowspec                  variable      :
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

                    Figure 1. Tunneled Traffic Flow-spec NLRI

   Length - The NLRI Length encoded as an unsigned integer including the
         Tunnel Type.

   Tunnel Type - The delimiter type is used to indicate of tunnel using a value from the IANA BGP
         Tunnel Encapsulation Attribute Tunnel Types registry.

INTERNET-DRAFT                                      BGP Tunnel Flow-Spec

   Flags: D bit - Indicates the boundary
   between presence of the Routing Discriminator
         (see below).

   Flags: I bit - Indicates the presence of an inner AFI and Flow-spec.

   Flags: Reserved - Six bits that MUST be sent as zero and ignored on
         receipt.

   Routing Discriminator - If the outer layer component types for NVO3 data
   packets. All the component types defined in [RFC5575bis],
   [IPv6-FlowSpec], [Layer2-FlowSpec], and 3 address belongs to a
         BGP/MPLS VPN, the like routing discriminator can be used for the
   inner or outer header as indicated by the use of delimiters. included to
         support traffic filtering within that VPN. Because the NVO3 outer
         layer address addresses normally belongs belong to a public network, the "Flow Specification" NLRI for the outer layer header
   doesn't need to include a Route
         Distinguisher field (8 bytes). If the
   outer layer address belongs to a VPN, the NLRI format is normally not needed for NVO3.

   Outer Flowspec / Length - The flow specification for the outer
   header should consist of a fixed-length Route Distinguisher field (8
   bytes) corresponding to the VPN. This Route Distinguisher
         header. The length is followed
   by the detail flow specifications encoded as provided in Section 4.1 of
         [RFC5575bis]. The AFI for the outer layer.

   The VN ID flowspec is that AFI at the identification for each tenant network. The "Flow
   Specification" NLRI for an NVO3 header part should always include
         beginning of the
   VN ID field but a Route Distinguisher field does not need to BGP multiprotocol MP_REACH_NLRI or
         MP_UNREACH_NLRI containing the tunneled traffic flow
         specification NLRI.

   Inner AFI - Depending on the Tunnel Type, there may be
   included.

   The an inner layer MAC/IP address is always associated with a VN ID.
   Thus AFI
         that indicates the NLRI format address family for the inner header should consist of flow
         specification. There is no need for a fixed-
   length VN ID field (4 bytes). The VN ID SAFI as it is followed by
         automatically TBD1, the detailed
   flow specifications SAFI for a tunneled traffic flow
         specification.

   Inner Flowspec / Length - Depending on the Tunnel Type, there may be
         an inner layer. The NLRI length field shall
   include both flow specification for the 4 bytes of header level encapsulated
         within the VN ID as well outer header. The length is encoded as provided in
         Section 4.1 of [RFC5575bis].

2.1 SAFI Code Point

   Use of the subsequent tunneled traffic flow
   specification. In the NVO3 terminating into a VPN scenario, if
   multiple access VN IDs map to one VPN instance, one shared VN ID can
   be carried specification NLRI format is
   indicated by SAFI=TBD1. This is used in conjunction with the Flow-Spec rule to enforce AFI for
   the rule outer layer 3 header, that is AFI=1 for IPv4 and AFI=2 for IPv6.

2.2 Component Code Points

   For flow specification based on certain tunnel header fields, the entire
   VPN instance and
   component types below are added. These are associated with the shared VN ID Tunnel
   Type and VPN correspondence should be
   configured on each VPN PE beforehand. In this case, MAY appear in the function of outer flow specification or, if it is
   present, in the layer3 VN ID is the same as a Route Distinguisher: it acts as the
   identification of the VPN instance.

   This document specifies the following Flow-Spec Component Types for
   use with NVO3 flows:

   Type TBD1 - Delimiter type
      Encoding: <type (1 octet), length (1 octet), Value>.

         When this delimiter type is present, it indicates the component
         types and layer for the NVO3 header fields immediately
         following. At the same time, it indicates the end of the
         component types belonging to the previous delimiter.

         The value field defines encapsulation type and is encoded as:

INTERNET-DRAFT                                        NVO3 BGP Flow-Spec

                        | 0   1   2   3   4   5   6   7 |
                        +---+---+---+---+---+---+---+---+
                        |          Encap Type           |
                        +---+---+---+---+---+---+---+---+
                        | I | O |        Resv           |
                        +---+---+---+---+---+---+---+---+

         This document defines the following Encap types:

            - VXLAN: Tunnel Type = 0

            - NVGRE: Tunnel Type = 1

         I: If I is set to one, it indicates the component types for the
         inner layer of NVO3 headers immediately follow.

         O: If O is set to one, it indicates the component types for the
         outer layer of NVO3 headers immediately follow.

For the NVO3 header part, the following additional two component types
   are introduced.

Type TBD2 - inner flow specification.

INTERNET-DRAFT                                      BGP Tunnel Flow-Spec

      Type TBD2 - VN ID
      Encoding: <type (1 octet), length (1 octet), [op, value]+>.

         Defines a list of {operation, value} pairs used to match the
         24-bit VN ID that is used as the tenant identification in NVO3
      networks. some
         tunneling headers. For VXLAN encapsulation, the VN ID is the
         VNI. For NVGRE encapsulation, the VN ID is equivalent to the VSID. op is
         encoded as specified in Section 4.2.3 of [RFC5575bis]. Values
         are encoded as 1- to 3-byte quantities.

      Type TBD3 - Flow ID
      Encoding: <type (1 octet), length (1 octet), [op, value]+>

         Defines a list of {operation, value} pairs used to match 8-bit
         Flow ID fields which are currently only useful for NVGRE
         encapsulation. op is encoded as specified in Section 4.2.3 of
         [RFC5575bis]. Values are encoded as 1-byte quantity.

INTERNET-DRAFT                                        NVO3 BGP Flow-Spec

3. NVO3 Flow Specification Traffic Actions

   The current traffic filtering actions are

      Type TBD4 - Session
      Encoding: <type (1 octet), length (1 octet), [op, value]+>

         Defines a list of {operation, value} pairs used for NVO3 to match a
         32-bit Session field. This field is called Key in GRE [RFC2890]
         encapsulation
   traffic. For Traffic Marking, only the DSCP and Session ID in L2TPv3 encapsulation. op is
         encoded as specified in Section 4.2.3 of [RFC5575bis]. Values
         are encoded as a 1, 2, or 4 byte quantity.

      Type TBD5 - Cookie
      Encoding: <type (1 octet), length (1 octet), [op, value]+>

         Defines a list of {operation, value} pairs used to match a
         variable length Cookie field. This is only useful in L2TPv3
         encapsulation. op is encoded as specified in Section 4.2.3 of
         [RFC5575bis]. Values are encoded as a 1, 2, 4, or 8 byte
         quantity. If the Cookie does not fit exactly into the value
         length, it is left justified, that is, padded with following
         bytes the MUST be sent as zero and ignored on receipt.

      Type TBD6 - VXLAN-GPE Flags
      Encoding: <type (1 octet), length (1 octet), [op, bitmask]+>

         Defines a list of {operation, value} pairs used to match
         against the VSLAN-GPE flags field. op is encoded as in Section
         4.2.9 of [RFC5575bis]. bitmask is encoded as 1 byte.

INTERNET-DRAFT                                      BGP Tunnel Flow-Spec

2.3 Specific Tunnel Types

   The following subsections describe how to handle flow specification
   for several specific tunnel types.

2.3.1 VXLAN

   The headers on a VXLAN [RFC7348] data packet are an outer Ethernet
   header, an outer IP header, a UDP header, the VXLAN header, and an
   inner Ethernet header. This inner Ethernet header is frequently, but
   not always, followed by an inner IP header. If the tunnel type is
   VXLAN, the I flag MUST be set.

   The version (IPv4 or IPv6) of the outer IP header is indicated by the
   AFI at the beginning of the multiprotocol MP_REACH_NLRI or
   MP_UNREACH_NLRI containing the tunneled traffic flow specification
   NLRI.  The outer flowspec is used to filter the outer headers and the
   UDP header.

   The inner flowspec is used on the Inner Ethernet header [FlowSpecL2].
   If the inner AFI is 25, then whether or not an IP header follows the
   inner Ethernet header is ignored and the inner flowspec SHOULD NOT
   contain and IPv4 or IPv6 flowspec components.  If the inner AFI is 1
   or 2, to match the flowspec the Inner Ethernet header must be
   followed by an IPv4 or IPv6 header, respectively, and the inner
   flowspec is also used to filter that inner IP header.

   A component filtering on the VXLAN header VN ID (VNI) can appear in
   either the outer or inner flowspec. The inner MAC/IP address is
   associated with a VN ID. In the NVO3 terminating into a VPN scenario,
   if multiple access VN IDs map to one VPN instance, one shared VN ID
   can be carried in the Flow-Spec rule to enforce the rule on the
   entire VPN instance and the shared VN ID and VPN correspondence
   should be configured on each VPN PE beforehand. In this case, the
   function of the layer 3 VN ID is the same as a Route Discriminator:
   it acts as the identification of the VPN instance.

2.3.2 VXLAN-GPE

   VXLAN-GPE [GPE] is similar to VXLAN and the VXLAN-GPE header is the
   same size as the VXLAN header but has been extended from the VXLAN
   header by specifying a number of bits that are reserved in the VXLAN
   header. In particular, a number of additional flag bits are specified
   and a Next Protocol field is added that is valid if the P flag bit is
   set.  These flags bits can be tested using the VXLAN-GPE Flags
   component defined above. VXLAN and VXLAN-GPE are distinguished by the

INTERNET-DRAFT                                      BGP Tunnel Flow-Spec

   port number in the UDP header the precedes the VXLAN or VXLAN-GPE
   headers.

   If the VXLAN-GPE header P flag is zero, then the header is followed
   by the same sequence as for VXLAN and the same flow-spec choices
   apply (see Section 2.3.1).

   If the VXLAN-GPE header P flag is one and that header's next protocol
   field is 1, then the VXLAN-GPE header is followed by an IPv4 header.
   The inner AFI/flowspec match only if the inner AFI is 1 and the inner
   flowspec matches.

   If the VXLAN-GPE header P flag is one and that header's next protocol
   field is 2, then the VXLAN-GPE header is followed by an IPv6 header.
   The inner AFI/flowspec match only if the inner AFI is 2 and the inner
   flowspec matches.

2.3.3 NVGRE

   NVGRE [RFC7637] is very similar to VXLAN except that the UDP header
   and VXLAN header immediately after the outer IP header are replaced
   by a GRE (Generic Router Encapsulation) header. The GRE header as
   used in NVGRE has no Checksum or Reserved1 field as shown in
   [RFC2890] but there are Virtual Subnet ID and FlowID fields in place
   of what is labeled in [RFC2890] as the Key field. Processing and
   restrictions for NVGRE are as in Section 2.3.1 eliminating references
   to a UDP header and replacing references to the VXLAN header and its
   VN ID with references to the GRE header and its VN ID (VSID) and Flow
   ID.

2.3.4 L2TPv3

   The headers on an L2TPv3 [RFC3931] packets are an outer Ethernet
   header, an outer IP header, the L2TPv3 header, an inner Ethernet
   header, and possibly an inner IP header if indicated by the inner
   Ethernet header EtherType. The outer flowspec operates on the outer
   headers that precede the GRE header. The version of IP is specified
   by the outer AFI at the beginning of the MP_REACH_NLRI or
   MP_UNREACH_NLRI.

   The L2TPv3 header consists of a 32-bit Session ID followed by a
   variable length Cookie (maximum length 8 bytes). The Session ID and
   Cookie can be filtered for by using the Session and Cookie flowspec
   components. To filter on Cookie or even be able to bypass Cookie and
   parse the remainder of the L2TPv3 packet, the node implementing
   flowspec needs to know the length and/or value of the Cookie fields

INTERNET-DRAFT                                      BGP Tunnel Flow-Spec

   of interest. This is negotiated at L2TPv3 session establishment and
   it is out of scope for this document how the node would learn this
   information. Of course, if flowspec is being used for DDOS mitigation
   and the Cookie has a fixed length and/or value in the DDOS traffic,
   this could be learned by inspecting that traffic.

   If the I flag bit is zero, then no filtering is done on data beyond
   the L2TPv3 header. If the I flag is one, indicating the presence of
   an inner flowspec, and the node implementing flowspec does not know
   the length of the L2TPv3 header Cookie, the match fails. If that node
   does know the length of that Cookie, the inner flowspec if matched
   against the headers at the beginning of that data using the inner
   AFI. If the inner AFI is 1 or 2, then an inner IP header is required
   and filtering can be done on the Ethernet header immediately after
   the L2TPv3 header and the following IPv4 or IPv6 headers
   respectively. If the inner AFI is 25, filtering SHOULD only be done
   on the inner Ethernet header [FlowSpecL2].

2.3.5 GRE

   Generic Router Encapsulation (GRE [RFC2890]) is a common type of
   encapsulation. The outer flowspec operates on the outer headers that
   precede the GRE header. The version of IP is specified by the outer
   AFI at the beginning of the MP_REACH_NLRI or MP_UNREACH_NLRI.

   If the I flag bit is zero, no filtering is done on data after the GRE
   header. If the I flag bit is one, then there is an inner AFI and
   flowspec and the Protocol Type field of the GRE header must match the
   inner AFI as follows for the flowspec to match:

       GRE Protocol Type    Inner AFI
      -------------------  -----------
       0x0800  (IPv4)             1
       0x86DD  (IPv6)             2
       0x6558                    25

   With the I flag a one and the inner AFI and GRE Protocol Type fields
   match, the inner flowspec is used to filter the inner Ethernet header
   (AFI=25) or the inner IP and Ethernet headers (AFI=1 or 2).

2.3.6 IP-in-IP

   IP-in-IP encapsulation is shown when the outer IP header indicates an
   inner IP IPv4 or IPv6 header by the value of the outer IP header's
   Protocol (IPv4) or Next Protocol (IPv6) field. If the Tunnel Type is
   IP-in-IP, the I flag MUST be set.

INTERNET-DRAFT                                      BGP Tunnel Flow-Spec

   The version of the outer IP header (IPv4 or IPv6) matched is
   indicated by the AFI at the beginning of the MP_REACH_NLRI or
   MP_UNREACH_NLRI.  The version of the inner IP header is indicated by
   the inner AFI. The outer flowspec applies to the outer IP header and
   the inner flowspec applies to the inner IP header.

2.4 Tunneled Traffic Actions

   The previously specified traffic filtering actions are used for
   tunneled traffic [RFC5575bis] [FlowSpecL2]. For Traffic Marking in
   NVO3, only the DSCP in the outer header can be modified.

INTERNET-DRAFT                                      BGP Tunnel Flow-Spec

3. Order of Traffic Filtering Rules

   In comparing an applicable tunneled traffic flow specification with a
   non-tunneled flow specification, the tunneled specification has
   precedence.

   If comparing two tunneled traffic flow specifications, if both are
   applicable, the tunnel types will be the same. If only one has a
   Routing Discriminator, it has precedence. If both have a Routing
   Discriminator, those discriminators are compared as unsigned integers
   and the one with the smaller magnitude Routing Discriminator has
   precedence.

   If neither has a Routing Discriminator or they have equal Routing
   Discriminators, the order of precedence is determined by comparing
   the outer flowspec.

   If the outer flowspecs are equal and the tunnel type calls for an
   inner flowspec, then the precedence is determined by comparing inner
   AFI as an unsigned integer with the inner AFI having the smaller
   magnitude having precedence.

   If the inner AFIs are equal, precedence is determined by comparing
   the inner flow specifications.

INTERNET-DRAFT                                      BGP Tunnel Flow-Spec

4. Flow Spec Validation

   Flow-specs received over AFI=1/SAFI=TBD1 or AFI=2/SFAI=TBD1 are
   validated, using only the outer header can
   be modified.

4. Flow-spec, against routing
   reachability received over AFI=1/SAFI=133 and AFI=2/SAFI=133
   respectively, as modified by [FlowSpecOID].

5. Security Considerations

   No new security issues are introduced to the BGP protocol by this
   specification.

5.

6. IANA Considerations

   IANA is requested to assign three a new SAFI as follows:

      Value  Description                                 Reference
      ----- ------------------------------------------  ---------------
       TBD1  Tunneled traffic flow specification rules  [This document]

   IANA is requested to assign two new values in the "Flow Spec
   Component Types" registry as follows:

      Type    Name            Reference
      ----   --------------   ---------
      TBD1   Delimiter type   [this document]
      TBD2   VN ID            [this document]
      TBD3   Flow ID          [this document]
      TBD4   Session          [this document]
      TBD5   Cookie           [this document]
      TBD6   VXLAN-GPE Flags  [this document]

INTERNET-DRAFT                                        NVO3                                      BGP Tunnel Flow-Spec

Normative References

   [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119,
         March 1997, <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]

   [RFC2890] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
         2119 Key Words", BCP 14, Dommety, G., "Key and Sequence Number Extensions to GRE",
         RFC 8174, 2890, DOI 10.17487/RFC8174, May
         2017, <https://www.rfc-editor.org/info/rfc8174>.

   [GENEVE] - J. Gross, T. Sridhar, etc, "Geneve: Generic Network
         Virtualization Encapsulation", draft-ietf-nvo3-geneve, work in
         progress.

   [GUE] - T. Herbert, L. Yong, O. Zia, "Generic UDP Encapsulation",
         draft-ietf-nvo3-gue, work in progress.

   [RFC5575bis] 10.17487/RFC2890, September 2000,
         <https://www.rfc-editor.org/info/rfc2890>.

   [RFC3931] - Hares, S., Loibl, C., Raszuk, R., McPherson, D.,
         Bacher, Lau, J., Ed., Townsley, M., "Dissemination of Flow Specification Rules", draft-
         ietf-idr-rfc5575bis-17, Work in progress, January 2019.

Informative References Ed., and I. Goyret, Ed.,
         "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
         DOI 10.17487/RFC3931, March 2005, <https://www.rfc-
         editor.org/info/rfc3931>.

   [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
         L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
         eXtensible Local Area Network (VXLAN): A Framework for
         Overlaying Virtualized Layer 2 Networks over Layer 3 Networks",
         RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-
         editor.org/info/rfc7348>.

   [RFC7367]

   [RFC7637] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network
         Virtualization Using Generic Routing Encapsulation", RFC 7637,
         DOI 10.17487/RFC7637, September 2015, <https://www.rfc-
         editor.org/info/rfc7637>.

   [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
         2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
         2017, <https://www.rfc-editor.org/info/rfc8174>.

   [FlowSpecL2] - W. Hao, etc, "Dissemination of Flow Specification
         Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in
         progress.

   [FlowSpecOID] - J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P.
         Mohapatra, "Revised Validation Procedure for BGP Flow
         Specifications", draft-ietf-idr-bgp-flowspec-oid, work in
         progress.

   [FlowSpecV6] - R. Raszuk, etc, "Dissemination of Flow Specification
         Rules for IPv6", draft-ietf-idr-flow-spec-v6, work in progress.

   [RFC5575bis] - Hares, S., Loibl, C., Raszuk, R., McPherson, D.,
         Bacher, M., "Dissemination of Flow Specification Rules", draft-
         ietf-idr-rfc5575bis-17, Work in progress, January 2019.

INTERNET-DRAFT                                      BGP Tunnel Flow-Spec

Informative References

   [RFC8014] - Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.
         Narten, "An Architecture for Data-Center Network Virtualization
         over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December
         2016, <https://www.rfc-editor.org/info/rfc8014>.

   [IPv6-FlowSpec] - R. Raszuk, etc, "Dissemination of Flow
         Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6,
         work in progress.

   [Layer2-FlowSpec] - W. Hao, etc, "Dissemination of Flow Specification
         Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in
         progress.

INTERNET-DRAFT                                        NVO3 BGP Flow-Spec

   [GPE] - P. Quinn, etc, "Generic Protocol Extension for VXLAN", draft-
         ietf-nvo3-vxlan-gpe, work in progress.

INTERNET-DRAFT                                        NVO3                                      BGP Tunnel Flow-Spec

Acknowledgments

   The authors wish to acknowledge the important contributions of Jeff
   Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, Robert Raszuk,
   and Lucy Yong.

Authors' Addresses

      Donald Eastlake
      Futurewei Technologies
      1424 Pro Shop Court
      Davenport,
      2386 Panoramic Circle
      Apopka, FL 33896 32703 USA

      Tel: +1-508-333-2270
      Email: d3e3e3@gmail.com

      Weiguo Hao
      Huawei Technologies
      101 Software Avenue,
      Nanjing 210012 China

      Email: haoweiguo@huawei.com

      Shunwan Zhuang
      Huawei Technologies
      Huawei Bld., No.156 Beiqing Rd.
      Beijing  100095 China

      Email: zhuangshunwan@huawei.com

      Zhenbin Li
      Huawei Technologies
      Huawei Bld., No.156 Beiqing Rd.
      Beijing  100095 China

      Email: lizhenbin@huawei.com

      Rong Gu
      China Mobile

      Email: gurong_cmcc@outlook.com

INTERNET-DRAFT                                        NVO3                                      BGP Tunnel Flow-Spec

Copyright, Disclaimer, and Additional IPR Provisions

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.