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

From: Brian Trammell <[email-masked]>
Date: Tue, 21 Aug 2012 16:55:50 +0200

Greetings, all,

To close the discussion from Vancouver, we have two proposals under consideration for handling the transition of enterprise-specific IEs used for testing, research, or other pre-standardization purposes to IANA IEs:

(1) The addition of an Enterprise-specific Reference column to the IANA registry, which would include PEN(s) and IE number(s) which have a description compatible with the IANA-registered IE; this is covered in the present revision of the IE-DOCTORS draft. The advantage of this is it provides a central registry; however, it presumes a model in which CPs are either frequently updated or periodically retrieve new registration information from IANA, and requires all users of ESIE codepoints replaced with an IANA codepoint to register that information with IANA.

(2) The definition of an IE equivalence options template, which would define the equivalence of a set of IANA and enterprise-specific IEs. This would be sent by EPs which had updated an IE from an older enterprise-specific codepoint to a new IANA codepoint; this would be covered in a new draft which Paul Aitken has (I think) already started work on. This has the advantage that equivalence is not dependent on the IANA registry. Benoit noted that this required the EP to (i) send additional information on session startup and (ii) to be updated both to use the new IANA codepoint as well as to send this additional information: a CP would not know an old ESIE was equivalent to a newer IANA IE if the EP it was receiving data from had not been updated.

As I see it, there are four possible ways forward:

(a) Support both methods: Leave approach (1) in IE-DOCTORS, develop a draft describing approach (2). 

(b) Support only the IANA method: leave approach (1) in IE-DOCTORS.

(c) Support only the Options method: remove approach (1) from IE-DOCTORS, develop a draft describing approach (2).

(d) Defer the question and leave ESIE promotion an open issue: remove approach (1) from IE-DOCTORS with no present decision on a draft about approach (2).

I suppose I'm in favor of option (a), since each approach has its own use cases, as long as we're clear in both IE-DOCTORS and the equivalence options draft about the applicability of each approach.

Thoughts?

Cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Tue, 21 Aug 2012 16:18:46 +0100

Brian,

> (1) The addition of an Enterprise-specific Reference column to the IANA registry, which would include PEN(s) and IE number(s) which have a description compatible with the IANA-registered IE; this i…

NB "compatible description" isn't sufficient. The type, range, 
semantics, units, all have to be compatible too.

> (2) The definition of an IE equivalence options template, which would define the equivalence of a set of IANA and enterprise-specific IEs. This would be sent by EPs which had updated an IE from an older enterprise-specific codepoint to a new IANA codepoint; this would be covered in a new draft which Paul Aitken has (I think) already started work on. This has the advantage that equivalence is not dependent on the IANA registry.

The draft was written over a year ago, and only needs some polishing 
before publication.

> Benoit noted that this required the EP to (i) send additional information on session startup and (ii) to be updated both to use the new IANA codepoint as well as to send this additional information: a CP would not know an old ESIE was equivalent to a newer IANA IE if the EP it was receiving data from had not been updated.

So when updating an ESIE to IANA, I either notify IANA for method (1), 
or I add the mapping to my code for method (2). There's little 
difference in effort between them.

Method (1) has some disadvantages: IANA must store enterprise-specific 
information, which seems contrary; and CP's must frequently refer to 
IANA for updates, which may not be possible or desirable in deployed 
systems.

Method (2) ensures that a CP is always up to date for any EP which 
exports to it. It also has an additional advantage that a mapping can be 
sent from old-ESIE to new-ESIE, which isn't possible with method (1).

> (a) Support both methods: Leave approach (1) in IE-DOCTORS, develop a draft describing approach (2).

Providing two methods for the same thing is asking for trouble in 
future. eg, non-interoperable implementations, one using method (1), the 
other using method (2). Worse, how to handle inconsistencies between the 
information received by each method?

> I suppose I'm in favor of option (a), since each approach has its own use cases, as long as we're clear in both IE-DOCTORS and the equivalence options draft about the applicability of each approach.

Let me see if I can quickly polish up the draft so people can see what 
method (2) entails.

P.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 21 Aug 2012 17:32:38 +0200

Hi, Paul,

thanks for the swift reply! inline per tradition:

On Aug 21, 2012, at 5:18 PM, Paul Aitken wrote:

> NB "compatible description" isn't sufficient. The type, range, semantics, units, all have to be compatible too.

indeed; I should have used a different word than "description" -- "IEs which are interoperable by definition"...

> The draft was written over a year ago, and only needs some polishing before publication.

Excellent.

> So when updating an ESIE to IANA, I either notify IANA for method (1), or I add the mapping to my code for method (2). There's little difference in effort between them.
> 
> Method (1) has some disadvantages: IANA must store enterprise-specific information, which seems contrary; and CP's must frequently refer to IANA for updates, which may not be possible or desirable in deployed systems.
> 
> Method (2) ensures that a CP is always up to date for any EP which exports to it. It also has an additional advantage that a mapping can be sent from old-ESIE to new-ESIE, which isn't possible with method (1).
> 
> 
> Providing two methods for the same thing is asking for trouble in future. eg, non-interoperable implementations, one using method (1), the other using method (2). Worse, how to handle inconsistencies between the information received by each method?

A good point; however, the worst-case interoperability of a two-method solution is no worse than that of no solution. Rules for conflict resolution would be a necessary part of any two-method solution.

> Let me see if I can quickly polish up the draft so people can see what method (2) entails.

Please do!

Cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Tue, 21 Aug 2012 21:01:21 +0100

Brian,

Once more inline...

> indeed; I should have used a different word than "description" -- "IEs which are interoperable by definition"...

To be picky: eg, are TOS and DSCP interoperable?

> A good point; however, the worst-case interoperability of a two-method solution is no worse than that of no solution.

Disagree. If there was no method, we'd work to create one as soon as the 
need was established. Whereas with two methods, we don't know who's 
doing what.

> Rules for conflict resolution would be a necessary part of any two-method solution.

Yep.

>> Let me see if I can quickly polish up the draft so people can see what method (2) entails.

Ack!

P.