[IPFIX] RFC5101: time first flow dropped and time last flow dropped
Benoit Claise <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix