Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs

Hi Paul,

On 09/24/2012 08:16 AM, Paul Aitken wrote:
> Benoit,
>
>> 4. If a single router from a specific vendor sends that URI, the 
>> collector receives all the mappings.
>>
>> The point 4 is my primary argument against "IE equivalence options 
>> template".
>> - "IE equivalence options template" must be sent from _all _the 
>> exporters (because different exporters support different sets of IEs) 
>> for the collector to rely on the mechanism. And we know there are 
>> different platforms, with different software versions, even from a 
>> single vendor.
>
> That's not quite correct.
>
> If each box must send it's own unique equivalence option, then each 
> box would require a unique URI for the collector to obtain the correct 
> mapping for that device alone.
>
> Since you clearly see that a single URI is sufficient for all devices 
> from a vendor, then a single option template from a single device is 
> also sufficient for all devices from a vendor, since the option would 
> contain the exact same information as the URI.
Benoit can correct me if I am not understanding him correctly, but I 
think he is envisioning something a bit broader than just the mapping 
needed for a single device.  I think what Benoit has in mind is a URI to 
a vendor maintained IANA like registry.  This registry would have info 
about all of that vendors information elements.

>> - Sending the URI only needs to be sent from a single exporter (from 
>> that vendor) and the collector gets all the required information.
>
> Similarly for the equivalence option.
>
> Consider the mechanism versus the content: there are two mechanisms 
> (option versus URI), while the underlying content is the same.
>
>
>> Note that the collector could even be hard coded the URI in the 
>> collector, as this should not change.
>
> Consider how the URI mechanism would handle versioning. ie, an 
> enterprise-specific IE changes from A to B to C. If the latest URI 
> says A is B and B is C (as it must), then older EPs from before the B 
> to C change, which truly do export B, may not be interpreted correctly.
>
> Whereas with the equivalence option mechanism, an older device could 
> export the "A to B" equivalence without the "B to C" equivalence.

First I thought the idea was to declare the "equivalence" of a vendor IE 
to some now standard IE.  I suppose a large vendor might have to IEs 
(say A and C) that are both equivalent to some new standard IE B.  Maybe 
A and C each only ever exported a subset of the values now standard for 
B, whatever.  If I can say that A is equivalent to B and I can say B is 
equivalent to C then I better also be able to say that A is equivalent 
to C.... Ahhh.

OK as I type this out I think I see where you are going.  Let's be more 
specific with my above example

A exports values (1 and 2)
C exports values (3 and 4)
B exports values (1, 2, 3, 4)

saying A is equivalent to C is a bit bizarre.  Maybe equivalence is the 
wrong word.  Anyone have a better suggestion?

I think this is a pretty compelling argument for each vendor maintaining 
a single registry.  I'm not really interested in versioning beyond 
getting the latest (most complete definition). Maintaining a per 
exporter registry seems like a lot of work with not a lot of upside.

I'll give this some more thought though.

-Andrew

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