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

[Benoit Claise <[e-mail]>]

Hi Paul,
> 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!".
There is a big difference here between your examples above and what we 
discuss here.
Your examples deal with the basis IPFIX protocol: RFC5101 or RFC5101bis.
The "IE equivalence options template" would be an extension, exactly 
like RFC5610. RFC 5610 is Standards Track
 From RFC 5610:

    an Exporting Process exporting
    data using Templates containing enterprise-specific Information
    Elements SHOULD export an Information Element type record for each
    enterprise-specific Information Element it exports.

So it's standards track, and it's a SHOULD. However, is it implemented?
Vendors might implement the base IPFIX, but the 
customers/vendors/collectors take a decision for each extension.
>
> 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.
Even if this new RFC contains a "MUST", this doesn't change anything to 
the logic.
It's not because the IETF produces Standards Track RFCs with "MUST's" 
that they are implemented.
>
> 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.
No disagreement on this one.
>
> 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.
I propose to let the collector people answer what (un)acceptable.

Regards, Benoit.
>
> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>
>>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipfix
>
>