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

Benoit,

0. Your argument that "we don't live in a perfect world" doesn't hold in 
this case. Although the world may be imperfect, IPFIX implementers MUST 
follow the defined standards. I can't simply put the wrong export 
version, or use the wrong set ID, or the wrong field sizes, or send NFv5 
to your IPFIX collector, and simply claim "but we don't live in a 
perfect world!".

1. If the equivalence options template is mandated as the IPFIX 
mechanism, then EPs MUST implement it to be IPFIX compliant, perfect 
world or not.

1a. Whereas, if we give a choice of two mechanisms, some may choose one, 
some may choose the other, and we'll have only ourselves to blame for 
the ensuing mess.

2. Regardless of what collector experts say on this list, we know that 
some enterprises lock down their network configuration and spend a lot 
of time testing updates before rolling them out in their networks. 
Allowing a device to update on the fly using an unverified third-party 
configuration (even if it is from IANA) would be entirely unacceptable.

P.


On 18/09/12 14:33, Benoit Claise wrote:
> 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

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