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

Andrew,

Thanks for your feedback.
See in line.
> 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. 
Yes.
> 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?
No. I'm advocating that, if the plan B is the "IE equivalence options 
template", that will not work.
>
>>
>> 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 :-)
Yes, a typo. "And they can not] rely on RFC5610 only". Thanks for the 
correction.

>
>>
>> Now, I would like to hear from the collectors people on the list:
>> - Would the "IE equivalence options template" be an important 
>> improvement? 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). 

This solution makes more way more sense, for the following reasons:
1. The URI would get the entire list of IEs in XML format, similar to IANA
2. All enterprise-specific IEs for the specific vendor would be included
3. The URI could include some more metadata, if needed.
      For example, the mapping between the mapping between 
entreprise-specific and IANA.
4. If a single router from a specific vendor sends that URI, the 
collector receives all the mappings.

The point 4 is my primary argument against "IE equivalence options 
template".
- "IE equivalence options template" must be sent from _all _the 
exporters (because different exporters support different sets of IEs) 
for the collector to rely on the mechanism. And we know there are 
different platforms, with different software versions, even from a 
single vendor.
- Sending the URI only needs to be sent from a single exporter (from 
that vendor) and the collector gets all the required information. Note 
that the collector could even be hard coded the URI in the collector, as 
this should not change.

Regards, Benoit (as a contributor)

> 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