[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Interdomain Routing Working Group                            M. Liu, Ed.
Internet-Draft                                              Y. Wang, Ed.
Intended status: Standards Track                                  Huawei
Expires: September 6, 2020                                March 05, 2020


            BGP Flow Specification Extensions to Enable IFIT
                     draft-liu-idr-flowspec-ifit-01

Abstract

   BGP Flowspec mechanism propogates both traffic Flow Specifications
   and Traffic Filtering Actions by making use of the BGP NLRI and the
   BGP Extended Community encoding formats.  This document specifies a
   new BGP Extended Community named IFIT Action Specific Extended
   Community to distribute In-situ Flow Information Telemetry (IFIT)
   actions so as to address the automatical deployment of IPv6 unicast
   and VPNv6 unicast on-path flow telemetry.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on September 6, 2020.

Copyright Notice

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





Liu & Wang              Expires September 6, 2020               [Page 1]


Internet-Draft       draft-liu-idr-flowspec-ifit-01           March 2020


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminologies . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  IFIT Application  . . . . . . . . . . . . . . . . . . . . . .   3
   4.  IFIT Action Specific Extended Community . . . . . . . . . . .   4
     4.1.  IOAM Pre-allocated Trace Option sub-type  . . . . . . . .   5
     4.2.  IOAM Incremental Trace Option sub-type  . . . . . . . . .   5
     4.3.  IOAM DEX Option sub-type  . . . . . . . . . . . . . . . .   6
     4.4.  IOAM Edge-to-Edge Option sub-type . . . . . . . . . . . .   7
     4.5.  Enhanced Alternate Marking Option sub-type  . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  IFIT Action Extended Community Types  . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   At present, a family of on-path flow telemetry techniques referred in
   [I-D.song-opsawg-ifit-framework] are emerging, including In-situ OAM
   (IOAM) [I-D.ietf-ippm-ioam-data], PBT
   [I-D.song-ippm-postcard-based-telemetry] , IOAM Direct Export (DEX)
   [I-D.ioamteam-ippm-ioam-direct-export] , Enhanced Alternate Marking
   (EAM) [I-D.zhou-ippm-enhanced-alternate-marking], etc. we categorize
   these on-path telemetry echniques as the hybrid OAM type I according
   to the classification defined in [RFC7799].  These techniques provide
   flow information on the entire forwarding path on a per-packet basis
   in real time, which are invaluable for application-aware network
   operations not only in data center and enterprise networks but also
   in carrier networks which may cross multiple domains.  The data
   provided by on-path telemetry are especially useful for network
   operations in aspects of SLA compliance, service path enforcement,
   fault diagnosis, and network resource optimization.  In IFIT
   reflection-loop architecture [I-D.song-opsawg-ifit-framework], an



Liu & Wang              Expires September 6, 2020               [Page 2]


Internet-Draft       draft-liu-idr-flowspec-ifit-01           March 2020


   IFIT application needs to choose a suite of telemetry tecchniques and
   apply an initial technique to the data plane in accordance to the
   monitoring and measurement requirements.  Then the IFIT head nodes
   also need to decide the target flows and packets to enable the IFIT-
   specific functions and the telemetry data sets.

   However, applying only a single underlying on-path telemetry
   technique may lead to defective result.  A comprehensive solution
   needs the flexibility to switch between different underlying
   techniques and adjust the configurations and parameters to adapt to
   different network conditions and different application requirements.
   Hence, it's necessary to make the control and configuration
   dynamically to the IFIT nodes.

   As we know, Dissemination of Flow Specification Rules
   [I-D.ietf-idr-rfc5575bis] provides a protocol extension for
   propagation of traffic flow information for the purpose of rate
   limiting, filtering, shaping, classifying or redirecting.  And BGP
   extended community encoding formats can be used to propagate traffic
   filtering actions along with the flow specification NLRI.  Those
   traffic filtering actions encode actions a routing system can take if
   the packet matches the flow specifications.  And the other document
   [I-D.ietf-idr-flow-spec-v6] extends BGP Flowspec
   [I-D.ietf-idr-rfc5575bis] and to make it also usable and applicable
   to IPv6 data packets.

   From an operational perspective, the utilization of BGP Flowspec as
   the carrier for the specific flow information allows a network
   service provider to reuse BGP route distribute infrastructure.
   Therefore, this document defines the IFIT action BGP Extended
   Communities to enable the IFIT application.

2.  Terminologies

   IFIT: in-situ Flow Information Telemetry

   NLRI: Network Layer Reachability Information

3.  IFIT Application

   The IFIT applications, which enable the future autonomous network
   operation, will pick one of proper in-situ telemetry techniques and
   apply a flow, packet, and data selection policy to monitor the
   specific traffic flow for application-aware network operation.  In
   current deployments, there have been relatively static methods, ACL-
   like CLI and Netconf with YANG model to enable the specific flow or
   packets from the target flow to be monitored on the relevant IFIT-
   capable nodes.



Liu & Wang              Expires September 6, 2020               [Page 3]


Internet-Draft       draft-liu-idr-flowspec-ifit-01           March 2020


   However, with the evolution of intent-based and automatic network
   operation, and the trends of network virtualization, network
   convergence, and packet-optical integration, future data plane
   telemetry will support an on-demand and interactive fashion.
   Flexibility and extensibility of data defining and acquiring must be
   considered.  Therefore, flexible configurations and actions need to
   be deployed based on the real-time telemetry data analysis results
   and telemetry requirements of different application.

   BGP Flowspec mechanism is preferred in the reflective-loop network
   telemetry system.  This document defines IFIT Action BGP Extended
   Communities to enable IFIT actions for the relevant flows that
   matches the traffic Flow Specifications along with the BGP NLRI
   defined in [I-D.ietf-idr-rfc5575bis] and [I-D.ietf-idr-flow-spec-v6].

4.  IFIT Action Specific Extended Community

   This section defines a new BGP Extended Community and different sub-
   types for IFIT actions in accordance with different IFIT option
   types.

   The BGP Extended Community is encoded as an 8-octet quantity, which
   contains Type field and Value field [RFC4360].  The Types are to be
   assigned by IANA registry.  The Value field contains the IFIT
   actions.

   In IFIT framework architecture, there are a few of available option
   types for the specified traffic flow, e.g.  IOAM pre-allocated/
   incremental trace [I-D.ietf-ippm-ioam-data], IOM Edge-to-Edge
   [I-D.ietf-ippm-ioam-data], IOAM Direct Export (DEX)
   [I-D.ioamteam-ippm-ioam-direct-export], Enhanced Alternate Marking
   (EAM) [I-D.zhou-ippm-enhanced-alternate-marking], etc.  As different
   IFIT options have different formats of parameters, following defines
   various Sub-types in accordance with different IFIT option types.

   o  Type xx: IFIT Action

   o  Sub-type xx: IOAM Pre-allocated Trace Option

   o  Sub-type xx: IOAM Incremental Trace Option

   o  Sub-type xx: IOAM DEX Option

   o  Sub-type xx: IOAM Edge-to-Edge Option

   o  Sub-type xx: Enhanced Alternate Marking Option





Liu & Wang              Expires September 6, 2020               [Page 4]


Internet-Draft       draft-liu-idr-flowspec-ifit-01           March 2020


   In the following sections, the different IFIT action Extened
   Communities encoding formats are presented.

4.1.  IOAM Pre-allocated Trace Option sub-type

   The IOAM tracing data is expected to be collected at every node that
   a packet traverses to ensure visibility into the entire path a packet
   takes within an IOAM domain.  The pre-allocated tracing option will
   create pre-allocated space for each node to populate its information.

   The format of IOAM pre-allocated trace option Extended Community is
   defined as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-------------------------------+-------------------------------+
       |      Type     |    Sub-type   |      NamespaceID              |
       +---------------------------------------------------------------+
       | Flags |          IOAM-Trace-Type                      |  Rsvd |
       +---------------------------------------------------------------+

         Fig. 1 IOAM Pre-allocated Trace Option Extended Community

   Where:

   Namespace ID: A 16-bit identifier of an IOAM-Namespace.  The
   definition is the same as described in section 4.4
   of[I-D.ietf-ippm-ioam-data] .

   Flags: A 4-bit field.  The definition is the same as described in [I-
   D.ietf-ippm-ioam-flags] and section 4.4 of [I-D.ietf-ippm-ioam-data].

   IOAM-Trace-Type: A 24-bit identifier which specifies which data types
   are used in the node data list.  The definition is the same as
   described in section 4.4 of [I-D.ietf-ippm-ioam-data].

   Rsvd: A 4-bit field reserved for further usage.  It MUST be zero.

4.2.  IOAM Incremental Trace Option sub-type

   The incremental tracing option contains a variable node data fields
   where each node allocates and pushes its node data immediately
   following the option header.

   The format of IOAM incremental trace option Extended Community is
   defined as follows:





Liu & Wang              Expires September 6, 2020               [Page 5]


Internet-Draft       draft-liu-idr-flowspec-ifit-01           March 2020


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-------------------------------+-------------------------------+
       |      Type     |    Sub-type   |      NamespaceID              |
       +---------------------------------------------------------------+
       | Flags |          IOAM-Trace-Type                      |  Rsvd |
       +---------------------------------------------------------------+

          Fig. 2 IOAM Incremental Trace Option Extended Community

   Where:

   All the other fields definistion is the same as the pre-allocated
   trace option Extended Community in section 3.2.1.

4.3.  IOAM DEX Option sub-type

   The DEX option is used as a trigger to export IOAM data to a
   collector.  Moreover, IOAM nodes MAY send exported data for all
   traversing packets that carry the DEX option, or MAY selectively
   export data only for a subset of these packets.  The DEX option
   specifies which data fields should be exported to the collector, as
   specified in Section 3.2 of [I-D.ioamteam-ippm-ioam-direct-export].

   The format of IOAM DEX option Extended Community is defined as
   follows:


           0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-------------------------------+-------------------------------+
      |      Type     |    Sub-type   |      NamespaceID              |
      +---------------------------------------------------------------+
      |             IOAM-Trace-Type                   |     Flags     |
      +---------------------------------------------------------------+

                 Fig. 3 IOAM DEX Option Extended Community

   Where:

   Namespace-ID: a 16-bit identifier of the IOAM namespace, as defined
   in section 4.4 of [I-D.ietf-ippm-ioam-data].

   IOAM-Trace-Type: a 24-bit identifier which specifies which data
   fields should be exported.  The format of this field is as defined in
   section 4.4 of[I-D.ietf-ippm-ioam-data]





Liu & Wang              Expires September 6, 2020               [Page 6]


Internet-Draft       draft-liu-idr-flowspec-ifit-01           March 2020


   Flags: A 8-bit field, comprised of 8 one-bit subfields.  Flags are
   allocated by IANA.

4.4.  IOAM Edge-to-Edge Option sub-type

   The IOAM edge to edge option is to carry data that is added by the
   IOAM encapsulating node and interpreted by IOAM decapsulating node.

   The format of IOAM edge-to-edge option Extended Community is defined
   as follows:


           0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-------------------------------+-------------------------------+
      |      Type     |    Sub-type   |              Rsvd             |
      +---------------------------------------------------------------+
      |  NamespaceID                  |      IOAM-E2E-Type            |
      +---------------------------------------------------------------+


            Fig. 4 IOAM Edge-to-Edge Option Extended Community

   Where:

   Namespace ID: A 16-bit identifier of an IOAM-Namespace.  The
   definition is the same as described in section 4.6
   of[I-D.ietf-ippm-ioam-data].

   IOAM-E2E-Type: A 16-bit identifier which specifies which data types
   are used in the E2E option data.  The definition is the same as
   described in section 4.6 of [I-D.ietf-ippm-ioam-data].

   Rsvd: A 16-bit field reserved for further usage.  It MUST be zero.

4.5.  Enhanced Alternate Marking Option sub-type

   The Alternate Marking [RFC8321] technique is an hybrid performance
   measurement method and can be used to measure packet loss, latency,
   and jitter on live traffic because it is based on marking consecutive
   batches of packets.

   The Enhanced Alternate Marking (EAM)
   [I-D.zhou-ippm-enhanced-alternate-marking] defines data fields for
   the alternate marking with enough space, in particular for Postcard-
   based Telemetry.  More information can be considered within the
   alternate marking field to facilitate the efficiency and ease the
   deployment.



Liu & Wang              Expires September 6, 2020               [Page 7]


Internet-Draft       draft-liu-idr-flowspec-ifit-01           March 2020


   The format of EAM Option Extended Community is defined as follows:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-------------------------------+-------------------------------+
        |      Type     |    Sub-type   |          Rsvd                 |
        +---------------+---------------+-------+---------------+-------+
        |              FlowMonID                |     Period    |  Rsvd |
        +---------------------------------------+---------------+-------+


        Fig. 5 Enhanced Alternate Marking Option Extended Community

   Where:

   FlowMonID: A 20-bit identifier to uniquely identify a monitored flow
   within the measurement domain.  The definition is the same as
   described in section 2 of [I-D.zhou-ippm-enhanced-alternate-marking].

   Period: A 8-bit field.  Time interval between two alternate marking
   period.  The unit is second.

   Rsvd: reserved for further usage.  It MUST be zero.

5.  IANA Considerations

5.1.  IFIT Action Extended Community Types

   This document requests a new Transitive Extended Community Type and
   five new registery sub-types.  The new Transitive Extended Community
   Type name shall be "IFIT Action Extended Community (Sub-Types are
   defined in the "IFIT Action Extended Community Sub-Type" registery)".


                 Type Value                    Name
                 ---------                     ----------
                 TBD                           IFIT Action


             Name                               Sub-type Value
             ---------                           ----------
             IOAM Pre-allocated Trace Option     TBD
             IOAM Incremental Trace Option       TBD
             IOAM DEX Option                     TBD
             IOAM Edge-to-Edge Option            TBD
             Enhanced Alternate Marking          TBD





Liu & Wang              Expires September 6, 2020               [Page 8]


Internet-Draft       draft-liu-idr-flowspec-ifit-01           March 2020


6.  Security Considerations

   No new security issues are introduced to the BGP Flow Specifications
   in [I-D.ietf-idr-flow-spec-v6] and [I-D.ietf-idr-rfc5575bis].

7.  Acknowledgements

8.  References

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

   [RFC4360]  "BGP Extended Communities Attribute",
              <https://www.rfc-editor.org/info/rfc4360>.

   [RFC7799]  "Active and Passive Metrics and Methods (with Hybrid Types
              In-Between)", <https://www.rfc-editor.org/info/rfc7799>.

   [RFC8321]  "Alternate-Marking Method for Passive and Hybrid
              Performance Monitoring",
              <https://www.rfc-editor.org/info/rfc8321>.

8.2.  Informative References

   [I-D.ietf-idr-flow-spec-v6]
              "Dissemination of Flow Specification Rules for IPv6",
              <https://datatracker.ietf.org/doc/draft-ietf-idr-flow-
              spec-v6/>.

   [I-D.ietf-idr-rfc5575bis]
              "Dissemination of Flow Specification Rules",
              <https://datatracker.ietf.org/doc/draft-ietf-idr-
              rfc5575bis/>.

   [I-D.ietf-ippm-ioam-data]
              "Data Fields for In-situ OAM",
              <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-
              data/>.

   [I-D.ioamteam-ippm-ioam-direct-export]
              "In-situ OAM Direct Exporting",
              <https://datatracker.ietf.org/doc/draft-ioamteam-ippm-
              ioam-direct-export/>.




Liu & Wang              Expires September 6, 2020               [Page 9]


Internet-Draft       draft-liu-idr-flowspec-ifit-01           March 2020


   [I-D.song-ippm-postcard-based-telemetry]
              "Postcard-based On-Path Flow Data Telemetry",
              <https://datatracker.ietf.org/doc/draft-song-ippm-
              postcard-based-telemetry/>.

   [I-D.song-opsawg-ifit-framework]
              "In-situ Flow Information Telemetry Framework",
              <https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-
              framework/>.

   [I-D.zhou-ippm-enhanced-alternate-marking]
              "Enhanced Alternate Marking Method",
              <https://datatracker.ietf.org/doc/draft-zhou-ippm-
              enhanced-alternate-marking/>.

Authors' Addresses

   Min Liu (editor)
   Huawei
   156 Beiqing Rd., Haidian District
   Beijing
   China

   Email: lucy_liumin@huawei.com


   Yali Wang (editor)
   Huawei
   156 Beiqing Rd., Haidian District
   Beijing
   China

   Email: wangyali11@huawei.com


















Liu & Wang              Expires September 6, 2020              [Page 10]


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