Subject: Re: [IPFIX] IE-doctors: transitioning IEs

From: Paul Aitken <[email-masked]>
Date: Wed, 01 Aug 2012 12:18:04 +0100

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.
>>
>>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 02 Aug 2012 10:00:21 -0700

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)

> ie, do you want to rework ie-doctors, and I'll polish and publish my 
> -00 for IE equivalence?
>
> P.
>
>
>> 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
>>
>>
>>> In my IE-doctors reviews, I expressed some reservation about 
>>> recording Enterprise-Specific information in IANA's IPFIX registry 
>>> as specified in this text:
>>>
>>> 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.
>>>
>>> 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-masked]
> https://www.ietf.org/mailman/listinfo/ipfix
>
>

---

From: Paul Aitken <[email-masked]>
Date: Thu, 02 Aug 2012 18:23:02 +0100

Benoit,

> _All _the exporters should export this IE equivalent Options Template 
> to help the collector deduce the mapping between old/new IEs

If the exporter begins to use different IEs, yes.

> 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.

This requires the collector to be able to query IANA - which isn't 
always possible. Or the collector manufacturer queries IANA and issues 
an updated collector (ie, new software version).

The proposed idea requires no enterprise-specific information to be 
recorded in IANA - because it simply does not belong there! And it 
provides a mechanism where collectors are immediately aware of the 
equivalence of old and new IEs without requiring any software update.

> Isn't it a good practice anyway that the collectors should insert the 
> latest IANA info on regular basis?

Perhaps. However, we know that some customers can test equipment in 
their labs for months or years before putting new versions into 
production. It's unlikely that they'd allow their collector to query 
IANA since this opens a potential attack vector if someone can inject 
incorrect information via the IANA registry lookup (eg, by DNS spoofing).

> So which problem does this equivalent Options Template really solve?

When an exporter begins to use a new IE (eg, IANA versus 
enterprise-specific), it enables a collector to process data received 
before the change with data received after the change without any 
software update being required.

P.