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

[Benoit Claise <[e-mail]>]

Andrew,

Thanks for your comments.
See in line.
> 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.  :-)
Thanks
>
>
> [ 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. 
That's something I was unable to double check in [IPFIX-CONF] or 
RFC5470, even if I believe it's a right assumption.
Gerhard?

Regards, Benoit.

> The IDs aren't meaningful to me as anything other than an identifier.
>
> -Andrew
>
>
>
> _______________________________________________
> IPFIX mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipfix