[Docs] [txt|pdf|xml|html] [Tracker] [Email] [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: August 31, 2020                               February 28, 2020


          A New Definition of the Flowspec IFIT Wide Community
                     draft-liu-idr-flowspec-ifit-00

Abstract

   BGP Flowspec mechanism propogates both flow specification information
   and traffic filtering actions by making use of the BGP policy
   framework.  In this document, authors only add the requirements of
   one new IFIT application [I-D.song-opsawg-ifit-framework] and specify
   the encoding format of a new BGP Extended Community to propagate In-
   situ flow information telemetry(IFIT) actions so as to address the
   deployment challenges of IPv6 unicast and VPNv6 unicast on-path flow
   information telemetry automatically.

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 August 31, 2020.

Copyright Notice

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




Liu & Wang               Expires August 31, 2020                [Page 1]


Internet-Draft       draft-liu-idr-flowspec-ifit-00        February 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
     1.1.  Definitions of Terms Used in This Memo  . . . . . . . . .   3
   2.  IFIT Application  . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Flowspec IFIT Wide Community  . . . . . . . . . . . . . . . .   4
     3.1.  IFIT Action Community Value . . . . . . . . . . . . . . .   4
     3.2.  IFIT Action Atoms . . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  IOAM Pre-allocated Trace Option Atom Sub-TLV  . . . .   5
       3.2.2.  IOAM Incremental Trace Option Atom Sub-TLV  . . . . .   6
       3.2.3.  IOAM DEX Trace Option Atom Sub-TLV  . . . . . . . . .   7
       3.2.4.  IOAM Edge-to-Edge Option Atom Sub-TLV . . . . . . . .   9
       3.2.5.  Enhanced Alternate Marking Option Atom Sub-TLV  . . .   9
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  Registered Type 1 BGP Wide Communities Community Types  .  10
     4.2.  BGP Community Container Atoms Types . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  An Appendix  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   A family of on-path flow telemetry techniques being referred in
   [I-D.song-opsawg-ifit-framework], are emerging, which can provide
   flow information on the entire forwarding path on a per-packet basis
   in real time. we categorize these on-path telemetry echniques as the
   hybrid OAM type I according to the classification defined in
   [RFC7799].  These techniques 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, which
   are important for user SLA compliance, service path enforcement,
   fault diagnosis, and network resource optimization.  In IFIT
   reflection-loop architecture [I-D.song-opsawg-ifit-framework], an
   IFIT application would pick a suite of telemetry tecchniques based on



Liu & Wang               Expires August 31, 2020                [Page 2]


Internet-Draft       draft-liu-idr-flowspec-ifit-00        February 2020


   its requirements and apply an initial technique to the data plane.
   Then the IFIT head nodes are configured to decide the initial target
   flows/packets and telemetry data set, the encapsulation and tunneling
   scheme based on the underlying network architecture.  And the IFIT-
   capable nodes are configured to decide the inital telemetry data
   export policy.

   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.  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.  Meanwhile, the other
   document [I-D.ietf-idr-flow-spec-v6] extends
   [I-D.ietf-idr-rfc5575bis] and defines changes to it in order 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.

   But the former document defines these traffic filter actions by
   extending the BGP extended community value which are formatted into
   only 6-octet fixed length of data.  Concerning actions of variable
   IFIT option-types and different parameters, this document extends the
   wide BGP communities [I-D.ietf-idr-wide-bgp-communities-05] to define
   the IFIT action.

1.1.  Definitions of Terms Used in This Memo

   IFIT: in-situ Flow Information Telemetry

   NLRI: Network Layer Reachability Information

2.  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 August 31, 2020                [Page 3]


Internet-Draft       draft-liu-idr-flowspec-ifit-00        February 2020


   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 different application
   requirements.

   Then BGP Flowspec dynamic mechanism is preferred in the closed-loop
   network telemetry system, which is going to add a new Traffic IFIT
   Action value of BGP Wide Community to closely monitor the relevant
   flows in real time that matches the flow specification's Network
   Layer Reachability Information (NLRI) defined in [I-D.ietf-idr-
   rfc5575bis] and [I-D.ietf-idr-flow-spec-v6].

   In most cases, the IFIT application does not require Next Hop
   information that shall be encoded as a 0-octet length Next Hop in the
   MP_REACH_NLRI attribute.

   According to the IOAM attribute, there is no disagreement between
   IFIT action and the other defined traffic filtering actions.

3.  Flowspec IFIT Wide Community

   This section defines a new community value in BGP wide community for
   IFIT action and extends optional lists of Atoms that encode
   parameters of IFIT actions in accordance with different IFIT option
   types.

   Container Type 1, BGP Wide Community is defined in
   [I-D.ietf-idr-wide-bgp-communities-05] .

3.1.  IFIT Action Community Value

   The Type 1 BGP Community Container, the BGP Wide Community, is of
   variable size (but minimum length 12).  The Community Value, in the
   first 4-octets of a fixed 12-octets Wide Community header, indicates
   what set of actions a router is requested to take upon reception of a
   route containing this community.  Then for this new type-IFIT action,
   IANA is requested to allocate a new value in the corresponding
   registry:

            Name                                     Community Value
            ----                                     ----------
            IFIT Action                                TBD





Liu & Wang               Expires August 31, 2020                [Page 4]


Internet-Draft       draft-liu-idr-flowspec-ifit-00        February 2020


3.2.  IFIT Action Atoms

   The BGP Wide Community Parameter(s) TLV (Sub-Type 3) contains a list
   of Atoms.  Atoms are encoded as TLVs described in section 5 of
   [I-D.ietf-idr-wide-bgp-communities-05].  The TLV types are to be
   assigned by IANA registry.  The Length represents the length of the
   "Value" field in octets.  The Value field contains the TLV value.

   In IFIT architecture, there are a few of option types available for
   the specified traffic flow, e.g.  IOAM pre-allocated/incremental
   trace, IOAM DEX trace, E2E ,POT etc.  As different IFIT option types
   have different formats of parameters, following defines new Atoms in
   accordance with different IFIT option types.

   Supported format of the IFIT action TLVs can be:

   Type xx: IOAM Pre-allocated Trace Option

   Type xx: IOAM Incremental Trace Option

   Type xx: IOAM DEX Trace Option

   Type xx: IOAM Edge-to-Edge Option

   Type xx: Enhanced Alternate Marking Option

   In the following sections, the different IFIT action option types of
   Atoms will be presented.

3.2.1.  IOAM Pre-allocated Trace Option Atom Sub-TLV

   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 sub-TLV is defined as
   follows:













Liu & Wang               Expires August 31, 2020                [Page 5]


Internet-Draft       draft-liu-idr-flowspec-ifit-00        February 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         |    Length                     |  NamespaceID  |
       |               |                               |    high       |
       +---------------------------------------------------------------+
       |  NamespaceID  |          IOAM Trace Type                      |
       |    Low        |                                               |
       +---------------------------------------------------------------+
       | Flags |  Rsvd |
       |       |       |
       +---------------+

              Fig. 1 IOAM Pre-allocated Trace Option Sub-TLV

   Where:

   Type: to be assigned by IANA.

   Length: the total length of the value field not including Type and
   Length fields.

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

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

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

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

3.2.2.  IOAM Incremental Trace Option Atom Sub-TLV

   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 sub-TLV is defined as
   follows:








Liu & Wang               Expires August 31, 2020                [Page 6]


Internet-Draft       draft-liu-idr-flowspec-ifit-00        February 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         |    Length                     |  NamespaceID  |
       |               |                               |    high       |
       +---------------------------------------------------------------+
       |  NamespaceID  |          IOAM Trace Type                      |
       |    Low        |                                               |
       +---------------------------------------------------------------+
       | Flags |  Rsvd |
       |       |       |
       +---------------+

               Fig. 2 IOAM Incremental Trace Option Sub-TLV

   Where:

   Type: to be assigned by IANA.

   Length: the total length of the value field not including Type and
   Length fields.

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

3.2.3.  IOAM DEX Trace Option Atom Sub-TLV

   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 Trace option sub-TLV is defined as follows:
















Liu & Wang               Expires August 31, 2020                [Page 7]


Internet-Draft       draft-liu-idr-flowspec-ifit-00        February 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         |    Length                     |
       |               |                               |
       +---------------------------------------------------------------+
       |  NamespaceID                  |        Flags                  |
       |                               |                               |
       +---------------------------------------------------------------+
       |             IOAM-Trace-Type                   |      Rsvd     |
       |                                               |               |
       +---------------------------------------------------------------+
       |                FlowID(Optional)                               |
       |                                                               |
       +---------------------------------------------------------------+
       |                    Sequence Number(Optional)                  |
       |                                                               |
       +---------------------------------------------------------------+

                   Fig. 3 IOAM DEX Trace Option Sub-TLV

   Where:

   Type: to be assigned by IANA.

   Length: the total length of the value field not including Type and
   Length fields.

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

   Flags: a 16-bit field, comprised of 16 one-bit subfields.  Flags are
   allocated by IANA, as defined in Section 4.2 of
   [I-D.ioamteam-ippm-ioam-direct-export] .

   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]

   Rsvd: this field SHOULD be ignored by the receiver.

   Flow ID: a 32-bit flow identifier, as defined in section 3.2 of
   [I-D.ioamteam-ippm-ioam-direct-export]

   Sequence Number: a 32-bit sequence number , as defined in section 3.2
   of [I-D.ioamteam-ippm-ioam-direct-export] .





Liu & Wang               Expires August 31, 2020                [Page 8]


Internet-Draft       draft-liu-idr-flowspec-ifit-00        February 2020


3.2.4.  IOAM Edge-to-Edge Option Atom Sub-TLV

   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 sub-TLV 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         |    Length                     |
       |               |                               |
       +---------------------------------------------------------------+
       |  NamespaceID                  |      IOAM E2E Type            |
       |                               |                               |
       +---------------------------------------------------------------+


                  Fig. 4 IOAM Edge-to-Edge Option Sub-TLV

   Where:

   Type: to be assigned by IANA.

   Length: the total length of the value field not including Type and
   Length fields.

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

3.2.5.  Enhanced Alternate Marking Option Atom Sub-TLV

   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 August 31, 2020                [Page 9]


Internet-Draft       draft-liu-idr-flowspec-ifit-00        February 2020


   The format of EAM sub-TLV 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         |    Length                     |
   |               |                               |
   +---------------+-----------------------+-------+-------+-------+
   |  FlowMonID                            |   Period      | Rsvd  |
   |                                       |               |       |
   +---------------------------------------+---------------+-------+


             Fig. 5 Enhanced Alternate Marking Option Sub-TLV

   Where: Type: to be assigned by IANA.

   Length: the total length of the value field not including Type and
   Length fields.

   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: Time interval between two alternate marking period.  The unit
   is second.

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

4.  IANA Considerations

4.1.  Registered Type 1 BGP Wide Communities Community Types

   For the new type-IFIT action, this document requests IANA to allocate
   a new value in the corresponding registry named " Registered Type 1
   BGP Wide Community Community Types":

                     +-------------+----------------+
                     | Name        | Community Type |
                     +-------------+----------------+
                     | IFIT Action | TBD            |
                     +-------------+----------------+

4.2.  BGP Community Container Atoms Types

   This document requests IANA to define new Atoms types for IFIT action
   option types in registry named: "BGP Community Container Atom Types":




Liu & Wang               Expires August 31, 2020               [Page 10]


Internet-Draft       draft-liu-idr-flowspec-ifit-00        February 2020


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



5.  Security Considerations

   No new security issues are introduced to the BGP protocol by this
   specification over the security considerations in [I-D.ietf-idr-
   rfc5575bis].

6.  Acknowledgements

7.  References

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

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

7.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-idr-wide-bgp-communities-05]
              "BGP Community Container Attribute",
              <https://datatracker.ietf.org/doc/draft-ietf-idr-wide-bgp-
              communities/>.





Liu & Wang               Expires August 31, 2020               [Page 11]


Internet-Draft       draft-liu-idr-flowspec-ifit-00        February 2020


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

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

Appendix A.  An Appendix

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 August 31, 2020               [Page 12]


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