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

Hi,
> 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.
Exactly.
>
>>> - 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.
Not quite.
The "IE equivalence options template" is for the situation when one 
exporter upgraded his software, and is aware of one new IE mapping (due 
to the software upgrade).
This "IE equivalence options template" is basically telling: "mister 
collector, you were receiving enterprise-specific IE X from me, and now 
I'm sending you the IANA IE Y: the two are equivalent"

The "IE equivalence options template"  has the context of the exporter 
only, while the URI solution contains a URI to a vendor maintained IANA 
like registry
>>
>>
>>> 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.
I'm not convinced this is a real use case.
>
> 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 share the same view.

Regards, Benoit (as a contributor)
>
> I'll give this some more thought though.
>
> -Andrew

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