[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-hao-idr-flowspec-nvo3) 00 01 02 03 04 05 06 07 08 09

INTERNET-DRAFT                                               D. Eastlake
Intended Status: Proposed Standard                Futurewei Technologies
                                                                  W. Hao
                                                               S. Zhuang
                                                                   Z. Li
                                                     Huawei Technologies
                                                                   R. Gu
                                                             China Mobil
Expires: October 11, 2020                                 April 12, 2020


                          BGP Dissemination of
             Flow Specification Rules for Tunneled Traffic
                    draft-ietf-idr-flowspec-nvo3-09



Abstract
   This draft specifies a Border Gateway Protocol (BGP) Network Layer
   Reachability Information (NLRI) encoding format for flow
   specifications (RFC 5575bis) that can match on a variety of 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 IDR Working Group mailing list <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.








D. Eastlake, et al                                              [Page 1]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


Table of Contents

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

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

      3. Order of Traffic Filtering Rules.......................14
      4. Flow Spec Validation...................................15

      5. Security Considerations................................15
      6. IANA Considerations....................................15

      Normative References......................................16
      Informative References....................................17

      Acknowledgments...........................................18
      Authors' Addresses........................................18
























D. Eastlake, et al                                              [Page 2]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


1. Introduction

   BGP Flow Specification (flowspec [RFC5575bis]) is an extension to BGP
   that supports the dissemination of traffic flow specification rules.
   It uses the BGP 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 flowspec is to automate the distribution
   of traffic filter lists to routers for Distributed Denial of Service
   (DDOS) mitigation.

   BGP flowspec defines BGP Network Layer Reachability Information
   (NLRI) formats used to distribute traffic flow specification rules.
   AFI=1/SAFI=133 is for IPv4 unicast filtering. AFI=1/SAFI=134 is for
   IPv4 BGP/MPLS VPN filtering. [FlowSpecV6] and [FlowSpecL2] extend the
   flowspec rules for IPv6 and Layer 2 Ethernet packets respectively.
   None of these previously defined flow specifications are suitable for
   matching in cases of tunneling or encapsulation where there might be
   duplicates of a layer of header such as two IPv6 headers in IP-in-IP
   or a nested header sequence such as the Layer 2 and 3 headers
   encapsulated in VXLAN [RFC7348].

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

   In summary, Flow Specifications should be able to include inner
   nested header information as well as fields specific to the type of
   tunneling in use such as virtual network / tenant ID. This draft
   specifies methods for accomplishing this using SAFI=TBD1 and 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 this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.



D. Eastlake, et al                                              [Page 3]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


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

   ACL - Access Control List

   DDoS - Distributed Denial of Service (Attack)

   DSCP - Differentiated Services Code Point

   GRE - Generic Router Encapsulation [RFC2890]

   L2TPv3 - Layer Two Tunneling Protocol - Version 3 [RFC3931]

   NLRI - Network Layer Reachability Information

   NVGRE - Network Virtualization Using Generic Routing Encapsulation
      [RFC7637]

   NVO3 - Network Virtual Overlay Layer 3 [RFC8014]

   PE - Provider Edge

   VN - virtual network

   VXLAN - Virtual eXtensible Local Area Network [RFC7348]


























D. Eastlake, et al                                              [Page 4]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


2. Tunneled Traffic Flow Specification NLRI

   The Flowspec rules specified in [RFC5575bis], [FlowSpecV6], and
   [FlowSpecL2] cannot match or filter tunneled traffic based on the
   tunnel type, any tunnel header fields, or headers past the tunnel
   header. To enable flow specification of tunneled traffic, a new 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.











































D. Eastlake, et al                                              [Page 5]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         | Length                          2 octets      |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         | Tunnel Type                     2 octets      |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       Flags:
         +--+--+--+--+--+--+--+--+
         | D| I| Reserved        |         1 octet
         +--+--+--+--+--+--+--+--+
       Optional Routing Distinguisher:
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         |                                               |
         +                                               +
         |                                               |
         + Routing Distinguisher           8 octets      +
         |                                               |
         +                                               +
         |                                               |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       Outer Flowspec:
         +--+--+--+--+--+--+--+--+
         | Outer Flowspec Length :         1 or 2 octets
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         | Outer Flowspec                  variable      :
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       Tunnel Header Flowspec:
         +--+--+--+--+--+--+--+--+
         | Tunnel Flowspec Length:         1 or 2 octets
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         | Tunnel Header Flowspec          variable      :
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       Optional Inner Flowspec:
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         | Inner AFI                       2 octets      |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         | Inner Flowspec Length :         1 or 2 octets
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         | Inner Flowspec                  variable      :
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

                    Figure 1. Tunneled Traffic Flowspec NLRI

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

   Tunnel Type - The type of tunnel using a value from the IANA BGP
         Tunnel Encapsulation Attribute Tunnel Types registry.

   Flags: D bit - Indicates the presence of the Routing Distinguisher
         (see below).


D. Eastlake, et al                                              [Page 6]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


   Flags: I bit - Indicates the presence of the Inner AFI and the Inner
         Flowspec (see below).

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

   Routing Distinguisher - If the outer Layer 3 address belongs to a
         BGP/MPLS VPN, the routing distinguisher is included to indicate
         traffic filtering within that VPN. Because NVO3 outer layer
         addresses normally belong to a public network, a Route
         Distinguisher field is normally not needed for NVO3.

   Outer Flowspec / Length - The flow specification for the outer
         header. The length is encoded as provided in Section 4.1 of
         [RFC5575bis]. The AFI for the Outer Flowspec is the AFI at the
         beginning of the BGP multiprotocol MP_REACH_NLRI or
         MP_UNREACH_NLRI containing the tunneled traffic flow
         specification NLRI.

   Tunnel Header Flowspec / Length - The flow specification for the
         tunneling header. This specifies matching criterion on tunnel
         header fields.  The tunnel type itself is indicated by the
         Tunnel Type field above. For some types of tunneling, such as
         IP-in-IP, there may be no tunnel header fields. For other types
         of tunneling, there may be several tunnel header fields on
         which matching can be specified with this flowspec.

   Inner AFI - Depending on the Tunnel Type, there may be an Inner AFI
         that indicates the address family for the inner flow
         specification.  There is no need for a SAFI as the treatment of
         this inner AFI and following flowspec is indicated by the outer
         SAFI TBD1, the SAFI for a tunneled traffic flow specification.

   Inner Flowspec / Length - Depending on the Tunnel Type, there may be
         an inner flowspec for the header level encapsulated within the
         outer header. The length is encoded as provided in Section 4.1
         of [RFC5575bis].

   A Tunneled Traffic Flowspec matches if the Outer Flowspec, Tunnel
   Header Flowspec, and Inner Flowspec, if present, all match and the
   Routing Distinguisher applies, if present. An omitted (as can be done
   for the Inner Flowspec) or null flowspec is considered to always
   match.



2.1 The SAFI Code Point

   Use of the tunneled traffic flow specification NLRI format is
   indicated by SAFI=TBD1. This is used in conjunction with the AFI for


D. Eastlake, et al                                              [Page 7]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


   the outer header, that is AFI=1 for IPv4, AFI=2 for IPv6, and AFI=6
   for Layer 2.



2.2 Tunnel Header Component Code Points

   For flowspec based on most tunneling, there are tunnel header fields
   that can be tested by components that appear in the Tunnel Header
   Flowspec field. The types for these components are specified in a
   Tunnel Header Flowspec component registry (see Section 6).

   All Tunnel Header field components defined below and all such
   components added in the future have a TLV structure as follows:
     - one octet of type followed by
     - one octet giving the length as an unsigned integer number of
       octets followed by
     - the specific matching operations/values as determined by the
       type.

      Type 1 - 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 some
         tunneling headers. For VXLAN encapsulation, the VN ID is the
         VNI. For NVGRE encapsulation, the VN ID is the VSID. op is
         encoded as specified in Section 4.2.3 of [RFC5575bis]. Values
         are encoded as a 1, 2, or 4 octet quantity. If value is
         24-bits, it is left-justified in the first 3 octets of the
         value and the last value octet MUST be sent as zero and ignored
         on receipt.

      Type 2 - 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 a 1-octet quantity.

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

         Defines a list of {operation, value} pairs used to match a
         32-bit Session field. This field is called Key in GRE [RFC2890]
         encapsulation 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 octet quantity.



D. Eastlake, et al                                              [Page 8]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


      Type 4 - 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 octet
         quantity. If the Cookie does not fit exactly into the value
         length, it is left justified, that is, padded with following
         octets the MUST be sent as zero and ignored on receipt.

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

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



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.

   If the outer Ethernet header is not being matched, 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 including, if desired,
   the UDP header.

   If the outer Ethernet header is being matched, then the initial AFI
   is 6 [FlowSpecL2] and the Outer Flowspec can match the outer Ethernet
   header, specify the IP version of the outer IP header, and match that
   IP header including, if desired, the UDP header.

   The Tunnel Header Flowspec can be used to filter on the VXLAN header
   VN ID (VNI).



D. Eastlake, et al                                              [Page 9]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


   The Inner Flowspec can be used on the Inner Ethernet header
   [FlowSpecL2] and any following IP header.  If the inner AFI is 6,
   then the inner Flowspec provides filtering of the Layer 2 header,
   indicates whether filtering on a following IPv4 or IPv6 header is
   desired, and if it is desired provides the Flowspec components for
   that filtering.  If the Inner AFI is 1 or 2, the Inner Ethernet
   header is not matched and to match the Flowspec the Inner Ethernet
   header must be followed by an IPv4 or IPv6 header, respectively, and
   the inner Flowspec is used to filter that inner IP header.

   The inner MAC/IP address is associated with the 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 flowspec 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
   Distinguisher: it acts as the identification of the VPN instance.



2.3.2 VXLAN-GPE

   VXLAN-GPE [GPE] is similar to VXLAN. 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 flowspec
   component defined above. VXLAN and VXLAN-GPE are distinguished by the
   port number in the UDP header the precedes the VXLAN or VXLAN-GPE
   headers.

   If the VXLAN-GPE header P flag is zero, then that header is followed
   by the same sequence as for VXLAN and the same flowspec 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 Flowspec matches 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 Flowspec match only if the Inner AFI is 2 and the Inner
   Flowspec matches.







D. Eastlake, et al                                             [Page 10]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


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 Flow ID 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 in the outer
   IP header is specified by either the outer AFI at the beginning of
   the MP_REACH_NLRI or MP_UNREACH_NLRI or, if that AFI is 6 (L2),
   optionally specified by the inner AFI within that L2 flowspec.

   The L2TPv3 header consists of a 32-bit Session ID followed by a
   variable length Cookie (maximum length 8 octets). The Session ID and
   Cookie can be filtered for by using the Session and Cookie flowspec
   components in the Tunnel Header Flowspec. 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 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 that 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 6, filtering is done on the inner
   Ethernet header and, if a non-zero inner AFI is specified within the


D. Eastlake, et al                                             [Page 11]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


   inner L2 flowspec, done on the following IP header [FlowSpecL2].



2.3.5 GRE

   Generic Router Encapsulation (GRE [RFC2890]) is another 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                     6

   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 IP headers
   (Inner AFI=1 or 2) or the inner Ethernet header and optionally a
   following IP header (Inner AFI=6).



2.3.6 IP-in-IP

   IP-in-IP encapsulation is indicated when an 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.

   The IP version of the outer IP header (IPv4 or IPv6) matched is
   indicated by an AFI of 1 or 2 at the beginning of the MP_REACH_NLRI
   or MP_UNREACH_NLRI while if that AFI is 6, it indicates a match on
   the out Ethernet header and, optionally, the following IP Header
   [FlowSpecL2].  The IP version of the inner IP header is indicated by
   the Inner AFI and the Inner Flowspec applies to the inner IP header.

   There are no fields that can be matched by the Tunnel Header Flowspec
   in the case of IP-in-IP.








D. Eastlake, et al                                             [Page 12]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


2.4 Tunneled Traffic Actions

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















































D. Eastlake, et al                                             [Page 13]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


3. Order of Traffic Filtering Rules

   The following rules determine which flowspec takes precedence where
   one or more are applicable and at least one of the applicable
   flowspecs is a tunneled traffic flowspec:

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

   -  If comparing tunneled traffic flow specifications, if all are
      applicable, the tunnel types will be the same. Any that have a
      Routing Distinguisher will take precedence over those without a
      Routing Distinguisher. Of those with a Routing Distinguisher, all
      applicable flowspecs will have the same Routing Distinguisher.

   -  At this point in the process, all remaining contenders for the
      highest precedence will either not have a Routing Distinguisher or
      have equal Routing Distinguishers. If more than one contender
      remain, those with an L2 Outer Flowspec take precedence over those
      with an L3 Outer Flowspec.  If the Outer Flowspec AFI is the same,
      their order of precedence is determined by comparing the Outer
      Flowspecs as described in [RFC5575bis] and [FlowSpecV6] for AFI
      for 1 or 2 respectively or [FlowSpecL2] for AFI=6.

   -  If the Outer Flowspecs are equal, then the Tunnel Header Flowspecs
      are compared using the usual sequential component comparison
      process [RFC5575bis].

   -  If the Tunnel Header Flowspecs are equal then compare the "I"
      flag.  Those with an Inner Flowspec take precedence over those
      without an Inner Flowspec.  If you get to this stage in the
      ordering process, those without an Inner Flowspec are equal. For
      those with an Inner Flowspec, check the Inner AFI. An L2 Inner AFI
      (AFI=6) takes precedence over an L2 Inner AFI.

   -  If the Inner AFIs are equal, precedence is determined by comparing
      the Inner Flowspecs as described in [FlowSpecL2] for L2 or
      [RFC5575bis] for L3.













D. Eastlake, et al                                             [Page 14]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


4. Flow Spec Validation

   Flowspecs received over AFI=1/SAFI=TBD1 or AFI=2/SFAI=TBD1 are
   validated, using only the Outer Flowspec, 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.

   For general Flowspec security considerations, see [rfc5575bis].



6. IANA Considerations

   IANA is requested to assign a new SAFI as follows:

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

   IANA is requested to create a Tunnel Header Flow Spec Component Type
   registry on the Flow Spec Component Types registries web page as
   follows:

      Name:  Tunnel Flow Spec Component Types
      Reference: [this document]
      Registration Procedures:
                  0  Reserved
              1-127  Specification Required
            128-254  First Come First Served
                255  Reserved

   Initial contents:
       Type    Name             Reference
      -----   --------------   -----------------
          0   reserved          [this document]
          1   VN ID             [this document]
          2   Flow ID           [this document]
          3   Session           [this document]
          4   Cookie            [this document]
          5   VXLAN-GPE Flags   [this document]
      6-254   unassigned        [this document]
        255   reserved          [this document]



D. Eastlake, et al                                             [Page 15]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


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>.

   [RFC2890] - Dommety, G., "Key and Sequence Number Extensions to GRE",
         RFC 2890, DOI 10.17487/RFC2890, September 2000,
         <https://www.rfc-editor.org/info/rfc2890>.

   [RFC3931] - Lau, J., Ed., Townsley, M., 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>.

   [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, et al, "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, et al, "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, Work in progress.






D. Eastlake, et al                                             [Page 16]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


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>.

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











































D. Eastlake, et al                                             [Page 17]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


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
      2386 Panoramic Circle
      Apopka, FL 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





D. Eastlake, et al                                             [Page 18]


INTERNET-DRAFT                                       BGP Tunnel Flowspec


Copyright, Disclaimer, and Additional IPR Provisions

   Copyright (c) 2020 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.






































D. Eastlake, et al                                             [Page 19]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/