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

On 09/20/2011 10:19 AM, Benoit Claise wrote:
> 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.,
>
>
[ snip ]
>
>
>       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._

There is an extra "There" there.  :-)


[ snip ]

> (*) 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?

meteringProcessId makes sense to me since you are exporting "Metering 
Process Reliability Statistics".

If you want to send a cache id as meteringProcessId (and your cache ids 
are "unique per IPFIX Device") I don't see any harm.  At least as long 
as the 1:1 relationship between metering process and cache holds.  The 
IDs aren't meaningful to me as anything other than an identifier.

-Andrew

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix