[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
                                                                J. Kumar
INTERNET-DRAFT                                                  J. Kumar
Intended Status: Informational                                S. Anubolu
                                                                   Z. He
                                                                R. Manur
                                                        Broadcom Limited
                                                                  D. Cai
                                                                   H. OU
                                                            AliBaba Inc.
                                                                   Y. Li
                                                                S. Suwei
                                                                  Huawei
Expires: September 6, 2018                                 March 5, 2018


                          Inband Flow Analyzer
                           draft-kumar-ifa-00


Abstract

   Inband Flow Analyzer (IFA) records flow specific information from
   smart NIC and/or switches across the network.  This document
   discusses the method to collect the data on a per hop basis across
   the network and perform localized analytics operations on it.  This
   document also describes transport agnostic header definition for
   tunneled and non tunneled flows.


Status of this Memo

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

   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



Kumar, et al                                                    [Page 1]


INTERNET DRAFT                    IFA                         March 2018


   http://www.ietf.org/shadow.html


Copyright and License Notice

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



Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Scope, Applicability, and Motivation  . . . . . . . . . . . . .  3
   3. IFA Operations  . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1 IFA Zones  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2 IFA Function Nodes . . . . . . . . . . . . . . . . . . . . .  5
       3.2.1 Initiator Function Node  . . . . . . . . . . . . . . . .  5
       3.2.2. Transit Function Node . . . . . . . . . . . . . . . . .  6
       3.2.3. Terminating Function Node . . . . . . . . . . . . . . .  6
     3.3 IFA Header . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.4 IFA Metadata . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.5 IFA Analytics  . . . . . . . . . . . . . . . . . . . . . . . 12
     3.6 IFA Ordered Set  . . . . . . . . . . . . . . . . . . . . . . 12
     3.7 IFA False Positives  . . . . . . . . . . . . . . . . . . . . 12
       3.7.1 Prevention Model - Filters at the edge of IFA Zone . . . 13
       3.7.2 Detection and Drop Model - No configuration  . . . . . . 13
   4. Interoperability Considerations . . . . . . . . . . . . . . . . 13
   5. Security Considerations . . . . . . . . . . . . . . . . . . . . 14
   6. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1  Normative References  . . . . . . . . . . . . . . . . . . . 14
     6.2  Informative References  . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14







Kumar, et al                                                    [Page 2]


INTERNET DRAFT                    IFA                         March 2018


1.  Introduction

   This document describes an Inband Flow Analyzer (IFA) mechanism to
   mark a packet to enable the collection of analyzed meta data with the
   analyzing flow.  IFA defines an IFA header to mark the flow and
   mandate the collection of analyzed meta on per marked packet per hop
   basis across the network.  This ability to mark the packet using IFA
   OAM header can be leveraged to create synthetic flows meant for
   network data collection. This document describes mechanism to emulate
   the live traffic and/or create synthetic flows.  IFA avoids defining
   protocol header specific modifications for collecting and analyzing
   flows.  IFA puts minimal requirements on the switching silicon.  This
   document also describes IFA zones, IFA reports and IFA meta data.

1.1  Terminology

   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 RFC 2119 [RFC2119].

   E2E: Edge to Edge

   IFA: Inband Flow Analyzer

   Geneve: Generic Network Virtualization Encapsulation [I-D.ietf-nvo3-
   geneve]

   IOAM: In-situ Operations, Administration, and Maintenance

   MTU: Maximum Transmit Unit

2. Scope, Applicability, and Motivation

   This document describes the IFA deployment, type of traffic
   supported, header definitions, analytics and data path functions.

   Scope: IFA deployment involves defining a IFA zone, understanding the
   requirements in terms of traffic overhead and points of data
   collection. Given that IFA provides ability to perform local
   analytics on the collected data, this document describes the scope of
   analytics function as well.  Scope of IFA is from the smart NIC
   and/or ToR to any/all node in the network and can terminate in
   network and/or the smart NIC.

   Applicability: IFA analyzes traffic and is encapsulation agnostic.
   Simple TCP and UDP flows as well as tunneled flows can be monitored.
   IFA can be enabled on smart NIC or can be just enabled on the network
   nodes.  Enabling IFA on smart NIC provides better scalability and



Kumar, et al                                                    [Page 3]


INTERNET DRAFT                    IFA                         March 2018


   visibility in the traffic.  IFA best performs when there is a
   hardware assist for deriving the flow data in the data path.  This
   document describes data path functions for IFA.

   Motivation: Main motivation for IFA is to collect analyzed metadata
   on a per packet per flow basis for a given application. Since
   changing the application L4 header is not permissible, IFA attempts
   to create a sampled stream of application traffic and use it to
   collect the metadata along the application path. This sampled stream
   is later discarded. Provision is made to support inband insertion of
   metadata with flexibility to do payload or tail stamping. This draft
   attempts to define a marking of sampled or native packets using the
   IFA header so as to collect meta data in hardware. This draft also
   provides ability to handle false positives for the application
   traffic to be analyzed.

3. IFA Operations

   IFA performs flow analysis and possible actions of the flow data
   inband.  Once a flow is enabled for analysis, node with the role of
   "Initiator" makes a copy of the flow and tags them for analysis and
   data collection.  Copying of the flow is done by sampling or cloning
   the flow.  These new packets are representative packets of the
   original flow and poses exact same characterization as the original
   flow.  This means that representative packets also called as IFA flow
   traverse the same path in the network and same queues in the
   networking element. Figure 1 show the IFA based Telemetry Framework.
   The terminating node is responsible to terminate the IFA flow by
   summarizing the metadata of the entire path and send it to
   Collector.





















Kumar, et al                                                    [Page 4]


INTERNET DRAFT                    IFA                         March 2018


                              +----------+
                              |          |
                              |Collector |--------------+
                              |          |              |
                              +----------+              |
                                                        |
                                                        |
                                                        |
                                                        |
                                                        |
                                                        |
                                                        |
                                                        |
     +--------------+        +------------+        +----+-----------+
     |Initiator Node|        |Transit Node|        |Terminating Node|
     |   +------+   |        |  +------+  |        |     +------+   |
     |   | IFA  |   |------->|  | IFA  |  |------->|     | IFA  |   |
     |   +------+   |IFA flow|  +------+  |IFA flow|     +------+   |
     +--------------+        +------------+        +----------------+

                      Figure 1 IFA Zone Framework

3.1 IFA Zones

   IFA zone is the domain of interest where IFA monitoring is enabled.
   IFA zone MUST have designated IFA function nodes.  IFA zone can also
   be controlled by setting appropriate TTL value in L3 header.
   Initiator and Terminating function nodes are always at the edge of
   the IFA zone.  Internal nodes in the IFA zone are always Transit
   function nodes.


3.2 IFA Function Nodes

   There are three IFA functional nodes.

3.2.1 Initiator Function Node

   Smart NIC or ToR or any other node can perform the function of
   initiator.  Better design is keep this role closest to the
   application if possible else flow visibility will be coarse.  IFA
   initiator node performs following functions,

   - Samples the flow traffic of interest based on a configuration.
   - Converts the traffic into IFA flow by adding IFA header.
   - Updates the packet with initiator node metadata.
   - Re-inject the IFA flow in the network.
   - May mandate a specific template id metadata by all networking



Kumar, et al                                                    [Page 5]


INTERNET DRAFT                    IFA                         March 2018


   elements
   - May mandate tail stamping of metadata by all networking elements

3.2.2. Transit Function Node

   This node is responsible for inserting transit node metadata in the
   IFA packet.

3.2.3. Terminating Function Node

   This node is responsible for following
   - Insert terminating node metadata in the IFA packet
   - Perform local analytics function on one or more segment of metadata
   for e.g. threshold breach for resident time, congestion notifications
   and so on.
   - Terminate the IFA flow by summarizing the metadata of the entire
   path and send it to collector
   - Drop the IFA flow

3.3 IFA Header

   IFA header is a variation of https://tools.ietf.org/html/draft-
   lapukhov-dataplane-probe-01 header.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Probe Marker (1)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Probe Marker (2)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Ver  |Rep|C|E|   Ctrl  |MType|  RSVD |  TID  |     Flag      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Telemetry Request Vector    |   Telemetry Action  Vector    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Hop Limit   |   Hop Count   |         Must Be Zero          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Maximum Length        |        Current Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Sender's Handle        |        Sequence Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2 IFA Header Format

   (1) The "Probe Marker" fields are arbitrary 32-bit values generally
   used by the network elements to identify the packet as a probe
   packet.  These fields should be interpreted as unsigned integer
   values, stored in network byte order.  For example, a network element



Kumar, et al                                                    [Page 6]


INTERNET DRAFT                    IFA                         March 2018


   may be configured to recognize a UDP packet destined to port 31337
   and having 0xDEAD 0xBEEF as the values in "Probe Marker" field as an
   active probe, and treat it respectively.  These fields are
   initialized to a configured value.

   (2) "Ver" is version and currently set to 1.

   (3) "Rep" is replication requested. These bits are used to indicate
   replication of packet. This field is used to explore all the valid
   forwarding paths and is set to 00.

        0: No replication requested.
        1: Port level replication requested. This is application to LAG
        interfaces.
        2: Next hop level replication requested. This is application to
        L3 ECMP paths.
        3: Port and Next hop level replication requested. This is
        application to L3 ECMP over LAG interfaces

   (4) "C" is copy requested. This bit is set for all the replicated
   packets to distinguish from the original packets. This bit is set to
   0.

   (5) "E" is max hop count exceeded. This bit is set when device can
   not add metadata because it has exceeded the hop count limit.

   (6) "Ctrl" are the bits for local optimizations. For eg these bits
   can contain the instruction count in the "Telemetry Request Vector"
   field.

   (7) The "MType" is message type and field value could be either "1" -
   "Probe" or "2" - "Probe Reply".  This field is set to 1.

   (8) "RSVD" are the reserved bits and must be initialized to 0.

   (9) "TID" is the mandated template id and must be honored by all the
   networking elements in the path

   (10) The "Flags" field is 8 bits, and defines the following flags:

        1) Bit 0: "Overflow" (O-bit).  This bit is set by the network
        element if the number of records on the packet is at the maximum
        limit as specified by the packet: i.e. the packet is already
        "full" of telemetry information.

        2) Bit 1: "Inband" (I-bit). This bit if set indicates IFA is
        inband with terminating device disposing the IFA header,
        metadata stack and forwarding the packet. This bit is set by the



Kumar, et al                                                    [Page 7]


INTERNET DRAFT                    IFA                         March 2018


        initiator node.

        3) Bit 2: "TailStamp" (T-bit). This bit if set mandates all the
        network elements in the path to add the metadata at the tail of
        the packet. This bit is set by the initiator node.

        4) Bit 4: "Template ID" (TID-bit). This bit if set mandates all
        the network elements in the path to insert specified template id
        of the metadata. This bit is set by the initiator node.

   (11) "Telemetry Request Vector" is a 16-bit long field that requests
   well-known inband telemetry information from the network elements on
   the path.  A bit set in this vector translates to a request of a
   particular type of information.  The following types/bits are
   currently defined, starting with the least significant bit first.
   Telemetry request vector is always in context of a given template id.
   For eg template id 1 will have telemetry request vector as follows.

        1)  Bit 0: Device identifier.
        2)  Bit 1: Ingress port ID + egress port ID.
        3)  Bit 2: Hop latency.
        4)  Bit 3: Queue ID + Queue occupancy.
        5)  Bit 4: Ingress timestamp.
        6)  Bit 5: Egress timestamp.
        7)  Bit 6: Queue ID + Queue congestion status.
        8)  Bit 7: Egress port tx utilization

   (12) "Telemetry Action Vector" is a 16-bit long field that requests
   inband telemetry metadata to be inserted based on the action
   indicated from the network elements on the path.  A bit set in this
   vector translates to an action rule of a particular type of
   information.  When the network node is able to perform some on-
   premises intelligence in deciding whether to insert metadata based on
   the criteria indicated by some vector bit, this vector can be set.
   The following types/bits are currently defined, starting with the
   least significant bit first:

        1)  Bit 0: Insert(1)/Ignore(0).
        2)  Bit 1: Queue depth exceed watermark for ECN.
        3)  Bit 2: Queue depth exceed watermark for PFC.
        4)  Bit 3: Resident delay breach.

   (13) "Hop Limit" is treated as an integer value representing the
   number of network elements.  See the Section 4 on the intended use of
   the field.

   (14) The "Hop Count" field specifies the current number of hops of
   capable network elements the packet has transit through.  It begins



Kumar, et al                                                    [Page 8]


INTERNET DRAFT                    IFA                         March 2018


   with zero and must be incremented by one for every network element
   that adds a telemetry record.  Combined with a push mechanism, this
   simplifies the work for the subsequent network element and the packet
   receiver.  The subsequent network element just needs to parse the
   template and then insert new record(s) immediately after the
   template.

   (15) The "Max Length" field specifies the maximum length of the
   telemetry payload in bytes.  Given that the sender knows the minimum
   path MTU, the sender can set the maximum of payload bytes allowed
   before exceeding the MTU.  Thus, a simple comparison between "Current
   Length" and "Max Length" allows to decide whether or not data could
   be added. Value of "0" means ignore.

   (16) The "Current Length" field specifies the current length of data
   stored in the probe.  This field is incremented by each network
   element by the number of bytes it has added with the telemetry data
   frame.

   (17) The "Sender's Handle" field is set by the sender to allow the
   receiver to identify a particular originator of probe packets.  Along
   with "Sequence Number" it allows for tracking of packet order and
   loss within the network.


3.4 IFA Metadata

   This is the information inserted by each hop after the IFA header.
   IFA metadata can be inserted at following offsets

   - Payload Stamping: After the layer 4 header
   - Tail Stamping: After the end of packet

   This document does not talk about merits or demerits of either
   approaches.

   Each hop MUST provide "device id" and "TID" (template ID) to be able
   to identify the source and template of metadata it is inserting. A
   node may have multiple sensors corresponding to different sets of
   telemetry data collection. The contents and format of such set of
   telemetry data is defined in a template that is identified by
   template ID (TID). Each hop may support different "TID" and may
   insert metadata as per its own "TID". Collector must have a list of
   all supported "TID" in a network path to be able to decode the
   metadata. Templates must be published with its assigned TID.  TID
   enables networking element to support diverse set of metadata and
   helps collector to decode the data appropriately.




Kumar, et al                                                    [Page 9]


INTERNET DRAFT                    IFA                         March 2018


   Following is done at each hop before inserting IFA metadata.

        (1) Overflow bit in Flags - Check if bit is set. If yes then do
        not insert the metadata and forward the packet.

        (2) Hop Count - Increment by 1.

        (3) Hop Limit - Decrement by 1. Check if the value has reached
        0. If yes and it is a terminating node then perform the
        terminating node functions else just drop it.

        (4) Current Length - Increase the current length by the size (in
        Bytes) of metadata added by network element. If "Max Length"
        field is non zero, perform the size exceeded check. If size is
        exceeded then set the "Overflow Bit" in "Flags field.


   Data field of IFA metadata is shown below:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Device ID.                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  TID  |              TID defined metadata                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      ~                TID defined metadata (contd)                   ~
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 3 IFA Metadata Format


   (1) Device ID: 32-bit unique device identifier. Note that Device ID
   is at fixed location at offset 0.

   (2) TID: 4-bit template ID.  Defines the following flexible format of
   metadata header.

   (3) TID defined metadata:  Variable length field.  This data field is
   defined by the template identified by the TID. Some of the TID
   defined metadata is defined as follows.


   When TID is 1, IFA metadata format is specified below.




Kumar, et al                                                   [Page 10]


INTERNET DRAFT                    IFA                         March 2018


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Device ID.                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | TID=1 |  CN   | Eg Port Drop U|     TTL       |   Queue ID    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Rx Time Stamp U.                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Rx Time Stamp L.         |   Rx Time Stamp ns U.         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Rx Time Stamp ns L.      |        Tx Time Stamp ns U.    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Tx Time Stamp ns L.      |      Egr Port Utilization     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Ingress Port ID.        |      Egress Port ID.          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Eg Port Drop L                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4 IFA Metadata Format when TID = 1


      (1) Device ID: 32-bit unique device identifier. Note that Device
      ID is at fixed location at offset 0.

      (2) TID: 1

      (3) CN: 4b field indicating the state of congestion.

      (4) Eg Port Drop U: Upper 8b of 40b egress drop count.

      (5) TTL: 8b field initialized by Initiator function node.

      (6) Queue ID: 16b egress queue ID.

      (7) Rx Time Stamp U: Upper 32b of 48b seconds of Rx Time stamp.

      (8) Rx Time Stamp L: Lower 16b of 48b seconds of Rx Time stamp.

      (9) Rx Time Stamp ns U: Upper 16b of 32b nano sec of Rx Time
      stamp.

      (10) Rx Time Stamp ns L: Lower 16b of 32b nano sec of Rx Time
      stamp.

      (11) Tx Time Stamp ns U: Upper 16b of 32b nano sec of Tx Time
      stamp.



Kumar, et al                                                   [Page 11]


INTERNET DRAFT                    IFA                         March 2018


      (12) Tx Time Stamp ns L: Lower 16b of 32b nano sec of Tx Time
      stamp.

      (13) Egr Port Utilization: 16b egress port utilization (in %)

      (14) Ingress Port ID: 12b ingress port id.

      (15) Egress Port ID: 12b egress port id.

      (16) Eg Port Drop L: Lower 32b of 40b egress drop count.

3.5 IFA Analytics

   Once network path data is collected for a flow, IFA provides ability
   to act on the data.  There are two kind of actions considered in this
   proposal.

   (1)  Action Bit MAP in IFA Header - This is encoded in the IFA
   header. Node in the path will use the action bitmap to insert or not
   insert the metadata based on threshold breach. Not insert operation
   is setting the field value to -1.

   (2) Terminating Node Actions - Terminating node may decide to perform
   threshold or other actions on the set of metadata in the packet. This
   information is not encoded in the IFA header

3.6 IFA Ordered Set

   TTL field in the IFA metadata is used to create an ordered set for
   the cases where network node is not capable of inserting the IFA
   metadata or inserts at the a different offset for e.g. as a Tail
   Stamp metadata.

   Copying of TTL from outer IP header will be skipped for the IFA non
   compatible nodes.  This will create a hole in TTL values in the set
   of IFA metadata in a packet.  These holes are identified and can be
   used to either create null metadata for the receiver.  If there is
   Tail Stamp metadata present then these holes are filled with the Tail
   Stamp metadata.  This mechanism is implemented by terminating
   function to create a IFA metadata ordered set for the receiver.

3.7 IFA False Positives

   One of the challenge of using probe signature in IFA header is a
   false positive. This draft proposes following actions to avoid any
   false positives.

   False positive happens when payload of the packet matches the IFA



Kumar, et al                                                   [Page 12]


INTERNET DRAFT                    IFA                         March 2018


   probe markers. This will trigger insertion of metadata and IFA header
   updates at each hop thereby corrupting the packet. If this is a
   packet belonging to real traffic then this corrupted packet will get
   forwarded to the application. If this is a sampled IFA packet it will
   result in drop of real traffic.

   To avoid this condition, following two deployment models are
   considered.

3.7.1 Prevention Model - Filters at the edge of IFA Zone

   This model requires installing global filters on all ports on the
   edge nodes of an IFA zone. Note that edge nodes are the initiator or
   terminator function nodes. This model requires careful
   configuration.

   1) Initiator node MUST install a match rule attached to the
   port/flows being monitored for probe marker.

   2) Initiator node MUST transition the detected packet to IFA packet
   by inserting IFA header with "O" and "I" Flag bits set. This will
   result in no metadata insertion.

   3) Terminating node MUST detect the "I" flag in the IFA header. If
   set, it MUST dispose the IFA header and forward the packet per
   forwarding rules.

3.7.2 Detection and Drop Model - No configuration

   This model doesn't require any configuration and relies on the fact
   that the any false positives will be dropped by the terminator node.

   Drop and mirror functionality can be used to report these dropped
   packets.

   Initiator node can install global rules for detection and reporting.


4. Interoperability Considerations

   Some encapsulations use protocol specific identifications, e.g., a
   VXLAN-GPE Next Protocol value ([I-D.brockners-inband-oam-transport])
   or a Geneve Option Class value ([I-D.draft-brockners-nvo3-ioam-
   geneve-00]) to indicate the presence of metadata. Similar approach
   can be used for IFA flow identification.

   If the hardware supports IFA flow creation directly to live traffic
   and non-sampling based metadata collection from the terminating node



Kumar, et al                                                   [Page 13]


INTERNET DRAFT                    IFA                         March 2018


   has no performance concern, IFA header and metadata can be inserted
   to live data packet without sampling, and the initiating and
   terminating nodes should work consistently and coordinately in
   inserting and stripping the metadata. The intermediate nodes are no
   change.


5. Security Considerations

   TBD

6. References

6.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


6.2  Informative References


   [I-D.brockners-inband-oam-transport] Brockners, F., Bhandari, S.,
              Govindan, V., Pignataro, C.,Gredler, H., Leddy, J.,
              Youell, S., Mizrahi, T., Mozes, D., Lapukhov, P., and R.
              Chang, "Encapsulations for In-situ OAM Data", draft-
              brockners-inband-oam-transport-05 (work in progress), July
              2017.

   [I-D.draft-brockners-nvo3-ioam-geneve-00] Brockners, F., Bhandari,
              S., Govindan, V., Pignataro, C.,Gredler, H., Leddy, J.,
              Youell, S., Mizrahi, T., Mozes, D., Lapukhov, P., and R.
              Chang, "Geneve encapsulation for In-situ OAM Data", draft-
              brockners-nvo3-ioam-geneve-00 (work in progress), October
              2017.

   [INT Specification] https://p4.org/assets/INT-current-spec.pdf

Authors' Addresses


   Jai Kumar
   Broadcom Limited
   Email: jai.kumar@broadcom.com


   Surendra Anubolu
   Broadcom Limited



Kumar, et al                                                   [Page 14]


INTERNET DRAFT                    IFA                         March 2018


   Email: surendra.anubolu@broadcom.com


   Zongying He
   Broadcom Limited
   Email: zongying.he@broadcom.com


   Rajeev Manur
   Broadcom Limited
   Email: Rajeev.manur@broadcom.com


   Dezhong Cai
   AliBaba Inc.
   Email: d.cai@alibaba-inc.com

   Heidi OU
   AliBaba Inc.
   Email: heidi.ou@alibaba-inc.com


   Yizhou Li
   Huawei Technologies
   EMail: liyizhou@huawei.com

   Sun Suwei
   Huawei Technologies
   EMail: sunsuwei@huawei.com






















Kumar, et al                                                   [Page 15]