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

On 09/18/2012 09:33 AM, 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.

The argument that this will not work in real life confuses me.  The base 
protocol doesn't have a required way to share IE information 
(equivalence or other).  Plan A (not plan B) is, therefore, hard coded 
IE information.  Plan B is any other option.  If an EP can give me 
useful information about an IE it is in my (and my customers') interest 
to use it for that EP even if not all EPs will send that information.  
Are you proposing that there should never be a plan B?

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

Exactly!  (I read the end of that sentence as "they can[not] rely on 
RFC5610 only".  I assume that was just a typo :-)

>
> 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!

I have seen no need for IE equivalence yet, but let's assume the need is 
on the horizon.  In that case I think Brian left out option 3 in his 
original email.  Extend 5610.

At IETF 84 Chris Inacio presented an idea to export a URI to XML ( 
http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IET84_IPFIX&chapter=part_10). 
Brian further suggested it made sense to extend 5610 to do this.  It 
seems like IE equivalence would fit within that work.  This way we can 
have a plan A and plan B instead of an alphabet soup of plans.

I do see a large and looming need for sharing vendor IE information.  
Especially for security and policy information as in Chris's example.

>
> - 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?

Yes I update from IANA.  I do this by importing the XML from the IANA 
site.  Currently this is done statically prior to each new release, but 
I anticipate the ability to update installed collectors in the near future.


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

I if you replace "IE equivalence options template" with "extend 5610" 
then I support (a) too.

-Andrew

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