[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.
- [IPFIX] RFC5101: time first flow dropped and time… Benoit Claise
- Re: [IPFIX] RFC5101: time first flow dropped and … Andrew Feren
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] RFC5… Paul Aitken
- Re: [IPFIX] RFC5101: time first flow dropped and … Benoit Claise
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] RFC5… Benoit Claise
- Re: [IPFIX] RFC5101: time first flow dropped and … Gerhard Muenz
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] RFC5… Gerhard Muenz
- Re: [IPFIX] RFC5101: time first flow dropped and … Paul Aitken
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] RFC5… Benoit Claise
- Re: [IPFIX] RFC5101: time first flow dropped and … Benoit Claise
- Re: [IPFIX] RFC5101: time first flow dropped and … Andrew Feren
- Re: [IPFIX] RFC5101: time first flow dropped and … Benoit Claise
- Re: [IPFIX] RFC5101: time first flow dropped and … Gerhard Muenz
- Re: [IPFIX] [SPAM I AM] Re: RFC5101: time first f… Andrew Feren
- Re: [IPFIX] [SPAM I AM] Re: RFC5101: time first f… Brian Trammell
- Re: [IPFIX] [SPAM I AM] Re: RFC5101: time first f… Andrew Feren
- Re: [IPFIX] RFC5101: time first flow dropped and … Paul Aitken
- Re: [IPFIX] RFC5101: time first flow dropped and … Brian Trammell
- Re: [IPFIX] RFC5101: time first flow dropped and … Paul Aitken
- Re: [IPFIX] RFC5101: time first flow dropped and … Brian Trammell
- Re: [IPFIX] RFC5101: time first flow dropped and … Benoit Claise
- Re: [IPFIX] RFC5101: time first flow dropped and … Benoit Claise
- Re: [IPFIX] RFC5101: time first flow dropped and … Brian Trammell
- Re: [IPFIX] RFC5101: time first flow dropped and … Brian Trammell
- Re: [IPFIX] RFC5101: time first flow dropped and … Benoit Claise
- Re: [IPFIX] RFC5101: time first flow dropped and … Andrew Feren
- Re: [IPFIX] RFC5101: time first flow dropped and … Gerhard Muenz
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] RFC5… Gerhard Muenz
- Re: [IPFIX] RFC5101: time first flow dropped and … Paul Aitken