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

From: Gerhard Muenz <[email-masked]>
Date: Wed, 18 Jan 2012 23:20:58 +0100

Hi Benoit,

Getting back to this issue:

On 20.09.2011 16:19, Benoit Claise wrote:
> Thirdly, the section 4.2 doesn't take into account a metering process 
> id. Indeed, what if we have multiple caches on the exporter?

Having another look at RFC5101, I see that this situation is already 
covered in RFC5101!
See the following paragraph which appears in sections 4.1 and 4.2:

    Note that if several Metering Processes are available on the Exporter
    Observation Domain, the Information Element meteringProcessId MUST be
    specified as an additional Scope Field.

If you now want to make meteringProcessId mandatory, you need to remove 
these paragraphs at least.

Gerhard

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

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 19 Jan 2012 21:26:01 +0100

Dear all,

On 21.09.2011 21:46, Gerhard Muenz wrote:
[...]
> We do not have selectorId, exportingProcessId, and meteringProcessId in
> the configuration data model. If we think about adding
> meteringProcessId, it may be worth thinking about the other IDs as well.
>
> I do not see a problem if these are defined as state parameters (e.g.
> read-only).
>
> selectorId is a bit different because the scope is OD, not IPFIX device.
> Therefore, the same ID value may appear for different Selectors of the
> same device.

I found that we had an internal discussion about selectorId back in 
2010. The conclusion was twofold:

1) It is not possible to simply add a single selectorId parameter per 
Selector because Selector ID is only unique per Observation Domain and 
not per PSAMP Device. Similarly to selectionSequenceId, only a list of 
tuples (observationDomainId,selectorId) would make sense in the 
configuration model.

2) selectorId is actually not needed in the configuration model because 
we already have the tuples (observationDomainId,selectionSequenceId) 
which allow associating "Selection Sequence Report Interpretation" and 
"Selection Sequence Statistics Report Interpretation" with the 
corresponding Selection Process in the configuration model.

So, I will only add exportingProcessId and meteringProcessId.

If somebody thinks of writing an RFC5476bis, I suggest to broaden the 
scope of selectorId and selectionSequenceId from Observation Domain to 
PSAMP Device in order to be consistent with meteringProcessId and 
exportingProcessId.

Gerhard

---

From: Paul Aitken <[email-masked]>
Date: Thu, 19 Jan 2012 22:23:08 +0000

Gerhard,

> PSAMP Device in order to be consistent with meteringProcessId and 

Well volunteered!

P.