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

Andrew,

The idea was that the equivalence option could map any IEspec to any 
other IEspec. Although it'd be commonly used to map enterprise specific 
to IANA standard, it could also map enterprise to enterprise, and even 
IANA standard to enterprise specific, or IANA standard to IANA standard. 
In fact it could also map between MIB / enterprise / IANA.

Regarding A/B/C below, imagine that enterprise specific IE A exports 
uint8 values 1 and 2. Later, enterprise specific IE B increases the size 
to uint16 and adds new values 0x123 and 0x45678, so A isn't exported 
anymore. Then B is replaced by the standardised version, C - so neither 
A nor B are required anymore.

However, older devices still export B. As an older device, the 
equivalence option coming from this device wouldn't know about C, so 
it'd just report that A has been replaced by B.

Whereas the URI mechanism would report that A is now B and B is now C, 
without any way to determine when (in code / release terms) the 
equivalence happened - so collectors might only expect C, which would be 
incorrect since older devices could still be exporting B (or indeed, A).

P.


On 24/09/12 14:04, Andrew Feren wrote:
> 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