Subject: [IPFIX] IE-doctors: transitioning IEs

From: Paul Aitken <[email-masked]>
Date: Thu, 19 Jul 2012 13:16:19 +0100

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: Brian Trammell <[email-masked]>
Date: Thu, 19 Jul 2012 14:45:34 +0200

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