Re: [IPFIX] IE-doctors: transitioning IEs

Hi Paul,

I'm wondering if this equivalent Options Template is not an overkill.

Let me explain:
_All _the exporters should export this IE equivalent Options Template to 
help the collector deduce the mapping between old/new IEs
If one of the exporters doesn't export the equivalent Options Template, 
the collector should anyway maintain its own mapping. Mapping that could 
be find in IANA. Isn't it a good practice anyway that the collectors 
should insert the latest IANA info on regular basis?

So which problem does this equivalent Options Template really solve?

Regards, Benoit (as a contributor)

> Brian,
>
> What is the conclusion to this?
>
> ie, do you want to rework ie-doctors, and I'll polish and publish my 
> -00 for IE equivalence?
>
> P.
>
>
> On 19/07/12 13:45, Brian Trammell wrote:
>> Hi, Paul,
>>
>> I'm not much of a fan of sticking enterprise-specific references in 
>> the registry, actually. It was suggested that this is a problem 
>> (indeed, I believe it is), and this is indeed a solution to it -- but 
>> it seems like a much cleaner mechanism for doing this would be to 
>> allow the actual devices doing the exporting to annotate the output 
>> data with an IE map (much like type information export as in RFC 5610).
>>
>> One clarifying point: the Collecting Process, of course, needs to be 
>> updated too, in order to understand the Options providing the IE map. 
>> But this only happens once, as opposed to the registry-based solution 
>> which requires the CP to be regularly updated (or to automatically 
>> query) the IANA registry.
>>
>> Removing a whole column and subset of sections from the ie-doctors at 
>> this late date may be a little problematic procedurally; I'm not sure 
>> of the right thing to do, and would turn to our chairs and AD for 
>> guidance...
>>
>> Cheers,
>>
>> Brian
>>
>>
>> On Jul 19, 2012, at 2:16 PM, Paul Aitken wrote:
>>
>>> Brian,
>>>
>>> In my IE-doctors reviews, I expressed some reservation about 
>>> recording Enterprise-Specific information in IANA's IPFIX registry 
>>> as specified in this text:
>>>
>>>     In order to support transition from experimental registration to 
>>> IANA
>>>     registration, the IANA registry provides an optional "enterprise-
>>>     specific IE reference" column for each Information Element.  In 
>>> cases
>>>     of promoted enterprise-specific Information Elements, this 
>>> column in
>>>     the registry SHOULD contain the private enterprise and Information
>>>     Element numbers of the enterprise-specific version of the 
>>> Information
>>>     Element.
>>>
>>>
>>> I've had a similar, but automated, idea in the back of my mind to 
>>> for some years: an upgraded device could export a table mapping 
>>> oldIE to newIE, where either of these IEs can be IANA standard or 
>>> Enterprise Specific.
>>>
>>> The table would be interpreted as "(if) I used to export oldIE, now 
>>> I export newIE", so the Collecting Process can readily re-map 
>>> exported data over the Exporting Process software change boundary. 
>>> If the Collecting Process never received any oldIE elements, it can 
>>> disregard the information.
>>>
>>> With the IE doctors / IANA registry idea, the information has to be 
>>> in the registry and the Collecting Process has to have read the new 
>>> registry. So both the Exporting Process and Collecting Process must 
>>> be updated.
>>>
>>> With my idea, only the Exporting Process is updated, and it informs 
>>> the Collecting Process.
>>>
>>> I drafted a -00 on this last year which requires a little more work, 
>>> so I've not published it yet.
>>>
>>> Of course the two mechanisms are complementary rather than mutually 
>>> exclusive. It's a question of which issues we're trying to solve.
>>>
>>> P.
>>>
>>>
>
>
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix
>
>

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