[IPFIX] RFC5101: time first flow dropped and time last flow dropped

Benoit Claise <bclaise@cisco.com> Tue, 20 September 2011 14:17 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFEB21F8A56 for <ipfix@ietfa.amsl.com>; Tue, 20 Sep 2011 07:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.477
X-Spam-Level:
X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTQYZdtWRTWI for <ipfix@ietfa.amsl.com>; Tue, 20 Sep 2011 07:17:02 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id EC0AD21F87C2 for <ipfix@ietf.org>; Tue, 20 Sep 2011 07:17:01 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8KEJPJt007648 for <ipfix@ietf.org>; Tue, 20 Sep 2011 16:19:25 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8KEJO3v024601 for <ipfix@ietf.org>; Tue, 20 Sep 2011 16:19:24 +0200 (CEST)
Message-ID: <4E78A0EC.9030003@cisco.com>
Date: Tue, 20 Sep 2011 16:19:24 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: "ipfix@ietf.org" <ipfix@ietf.org>
References: <4A8015DF.6040903@cisco.com>
In-Reply-To: <4A8015DF.6040903@cisco.com>
X-Forwarded-Message-Id: <4A8015DF.6040903@cisco.com>
Content-Type: multipart/alternative; boundary="------------060508030409000901020108"
Subject: [IPFIX] RFC5101: time first flow dropped and time last flow dropped
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Sep 2011 14:17:03 -0000

Dear all,

[this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO 
DO -> "time first flow dropped" and "time last flow dropped" 
inconsistency.  See the discussion on the list.]

Paul Aitken discovered this issue.,

 From [RFC5101], section 4.3. The Exporting Process Reliability 
Statistics Option Template

time first flow dropped
                         The timestamp of the first _Flow _was dropped by
                         the Metering Process.  For this timestamp, any
                         of the "flowStart" timestamp Information
                         Elements flowStartMilliseconds,
                         flowStartMicroseconds, flowStartNanoseconds, and
                         flowStartDeltaMicroseconds can be used.

time last flow dropped
                         The timestamp of the last _IP packet_ that was
                         ignored by the Metering Process.  For this
                         timestamp, any of the "flowEnd" timestamp
                         Information Elements flowEndMilliseconds,
                         flowEndMicroseconds, flowEndNanoseconds, and
                         flowEndDeltaMicroseconds can be used.


Firstly, these definitions are inconsistent since the names and the 
first definition say "flow" while the second definition says "IP 
packet". Obviously "IP packet" != "flow" :-o

Secondly, "The timestamp of the first Flow was dropped by the Metering 
Process." is bad English: at least it's missing "that".

Thirdly, the section 4.2 doesn't take into account a metering process 
id. Indeed, what if we have multiple caches on the exporter?

Here is a proposal for 4.2 and 4.3. The underlined parts are new


      4.2. The Metering Process Reliability Statistics Option Template



    The Metering Process Reliability Option Template specifies the
    structure of a Data Record for reporting lack of reliability in the
    Metering Process.  It SHOULD contain the following Information
    Elements that are defined in [RFC5102  <http://tools.ietf.org/html/rfc5102>]:

    observationDomainId
                            An identifier of an Observation Domain that
                            is locally unique to the Exporting Process.
                            This Information Element MUST be defined as a
                            Scope Field.


_    meteringProcessId (*)
                            The identifier of the Metering Process for
                            which lack of reliability is reported.  There
                            This Information Element MUST be defined as a
                            Scope Field._

    ignoredPacketTotalCount
                            The total number of IP packets that the
                            Metering Process did not process.

    ignoredOctetTotalCount
                            The total number of octets in observed IP
                            packets that the Metering Process did not
                            process.

    time first_packet_ignored
                            The timestamp of the first IP packet that was
                            ignored by the Metering Process.  For this
                            timestamp, any of the "flowStart" timestamp
                            Information Elements flowStartMilliseconds,
                            flowStartMicroseconds, flowStartNanoseconds,
                            and flowStartDeltaMicroseconds can be used.

    time last_packet_ignored
                            The timestamp of the last IP packet that was
                            ignored by the Metering Process.  For this
                            timestamp, any of the "flowEnd" timestamp
                            Information Elements flowEndMilliseconds,
                            flowEndMicroseconds, flowEndNanoseconds, and
                            flowEndDeltaMicroseconds can be used.




      4.3. The Exporting Process Reliability Statistics Option Template


    The Exporting Process Reliability Option Template specifies the
    structure of a Data Record for reporting lack of reliability in the
    Exporting process.  It SHOULD contain the following Information
    Elements that are defined in [RFC5102  <http://tools.ietf.org/html/rfc5102>]:

    Exporting Process ID
                         The identifier of the Exporting Process for
                         which lack of reliability is reported.  There
                         are three Information Elements specified in
                         [RFC5102  <http://tools.ietf.org/html/rfc5102>] that can be used for this purpose:
                         exporterIPv4Address, exporterIPv6Address, or
                         exportingProcessId.  This Information Element
                         MUST be defined as a Scope Field.

    notSentFlowTotalCount
                         The total number of Flows that were generated by
                         the Metering Process and dropped by the Metering
                         Process or by the Exporting Process instead of
                         being sent to the Collecting Process.

    notSentPacketTotalCount
                         The total number of packets in Flow Records that
                         were generated by the Metering Process and
                         dropped by the Metering Process or by the
                         Exporting Process instead of being sent to the
                         Collecting Process.

    notSentOctetTotalCount
                         The total number of octets in packets in Flow
                         Records that were generated by the Metering
                         Process and dropped by the Metering Process or
                         by the Exporting Process instead of being sent
                         to the Collecting Process.

    time first flow dropped
   _                       The time at which the first Flow Record was dropped by
                         the__Exporting Process._   For this timestamp, any
                         of the "flowStart" timestamp Information
                         Elements flowStartMilliseconds,
                         flowStartMicroseconds, flowStartNanoseconds, and
                         flowStartDeltaMicroseconds can be used.

    time last flow dropped
                         _The time at which the last Flow Record was
                         dropped by the Exporting Process_.  For this
                         timestamp, any of the "flowEnd" timestamp
                         Information Elements flowEndMilliseconds,
                         flowEndMicroseconds, flowEndNanoseconds, and
                         flowEndDeltaMicroseconds can be used.

    The Exporting Process SHOULD export the Data Record specified by the
    Exporting Process Reliability Statistics Option Template on a regular
    basis or based on some export policy.  This periodicity or export
    policy SHOULD be configurable.





(*) regarding the meteringProcessId, we were hesitating between the 
meteringProcessId and the cache id
1. there is a meteringProcessId in IPFIX IANA while there is no cache id
2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be 
the value in meteringProcessId?
     [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
     From figure 1 and 2, it seems that there is a one to one matching 
between the cache and the metering process.
     If this is the case, a solution could be to add a meteringProcess 
inside the cache in the figure 12 in [IPFIX-CONF] below


      4.3. Cache Class


     +-----------------------------------+
     | Cache                             |
     +-----------------------------------+        1 +------------------+
     | name                              |<>--------| immediateCache/  |
     | dataRecords {readOnly}            |          | timeoutCache/    |
     | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
     |                                   |          | permanentCache   |
     |                                   |          +------------------+
     |                                   |
     |                                   |     0..* +------------------+
     |                                   |--------->| ExportingProcess |
     +-----------------------------------+          +------------------+

                           Figure 12: Cache class

What do you think? Do you see another way?

Regards, Paul & Benoit.