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

Dear all,

[catching up with emails after my vacation]

I believe that "IE equivalence options template" (solution 2) sounds 
like a nice idea but will not work in real live.
In a perfect world, all the EPs would export this "IE equivalence 
options template" and the CP could ONLY rely on this mechanism.
We don't live in a perfect world, so not all EPs will export this 
options template. This implies that the CPs need anyway a plan B: hard 
coding the mapping, potentially received from IANA.

This is the exact same example as RFC5610. It's not implemented by all 
EPs (because we don't live in a perfect world), so the CPs must 
sometimes hard code the information, and they can rely on RFC5610 only.

Now, I would like to hear from the collectors people on the list:
- Would the "IE equivalence options template" be an important 
improvements? Warning: assuming that only some EPs might implement this 
feature!
- What about the fact that the collectors don't update the registry 
frequently from IANA, as an argument for the solution (2) below?
Do you update from IANA? Yes/No? how frequently?

Regards, Benoit.

> 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
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix
>
>

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