Re: [IPFIX] review of draft-trammell-ipfix-ie-doctors-00

[Paul Aitken <[e-mail]>]

Benoit,

Replying to just a few points:


>>>     [RFC5103] defines a method for exporting bidirectional flow
>>>     information using IPFIX; this document should be followed when
>>>     extending IPFIX to represent information about bidirectional network
>>>     interactions in general.  Additionally, new Information Elements
>>>     should be annotated  for their reversibility or lack thereof as per
>>>     this document.
>>>    
>>
>> Where is this annotation to be recorded? AFAIK there's currently 
>> nowhere to do this in the IANA registry, yet there's no requirement 
>> to create any other document before creating new IEs.
> Isn't part of the description in the IPFIX IANA?

If that's what you intend then you should explicitly say that here.

eg "new Information Elements should be annotated in the IANA registry...".


>>>     Optionally, a Working Group or individual contributor may choose to
>>
>> You should detail "Optionally". New IEs don't need an RFC, but some 
>> applications may require changes to the IPFIX protocol which do 
>> require an RFC.
> This was discussed during the IPFIX working group: unless really 
> really required, don't create a RFC for new IEs allocation.

Exactly! So write it in this draft.

Surely you don't expect new contributors to trawl the group archives 
first? :-(


>> Potentially these issues may be solved with clear version tracking.
> exactly.
> Discussing with Brian in Beijing, we think that one (if not the only 
> one) solution would be to have a version number for IPFIX IANA 
> registry. Everything single time something is changed in it (new IE, 
> extra value for a sub registry, etc...), the version number would be 
> incremented.

I could be OK with that. Did you investigate how other registries deal 
with this issue (if they do, at all?).


>>>     Deprecated Information Elements SHOULD continue to be supported by
>>>     Collecting Processes, but SHOULD NOT be exported by Exporting
>>>     Processes.  The use of deprecated Information Elements SHOULD result
>>>     in a log entry or human-readable warning at theExporting  and
>>>    
>>
>> That's crazy! You're saying that the EP should be updated to report 
>> that it's still sending deprecated fields? LOL. If you're going to 
>> update it to know that it's sending an obsolete field, your time 
>> would clearly be better spent updating it not to export that field 
>> any more.
> We have in mind a kind of syslog message sent from the exporter.

No.

Instead of wasting time adding a message to say "I'm still sending a 
deprecated IE", just change the deprecated IE to the new one.

Anyway, how is a 5, 10, 20... year old EP to know that it's sending 
deprecated IEs? It will be, because it hasn't been updated in all that 
time. However it won't be compliant with this draft because it has no 
way of knowing that what it's sending is deprecated!

So, what exactly are you trying to achieve here?


>>>     Simply changing the context in which an Information Element will be
>>>     used is insufficient reason for the definition of a new Information
>>>     Element.  For example, an extension of IPFIX to log detailed
>>>     information about HTTP transactions alongside network-level
>>>     information should not define httpClientAddress and httpServerAddress
>>>     Information Elements, preferring instead the use of
>>>     sourceIPv[46]Address and destinationIPv[46]Address.
>>>    
>>
>> I've got http through a tunnel, proxy or NAT, such that there are two 
>> source addresses and two destination addresses.
>> One src/dst pair is for http, the other belongs to the tunnel, proxy 
>> or NAT. What do you propose?
> what do you propose? ;-)

When the same IE appears multiple times in a message, we need a way to 
add context to each instance. eg, encapsulation, MPLS labels, and the 
example above.

I don't propose to solve that here today :-)


>>>     The best practice in Information Element creation is a conservative
>>>     one: don't create a new Information Element unlessyou  really need
>>>     it.
>>>    
>> Applications dealing with bidirectional interactions should use
>>
>> Of course you really need it. However, does the wider IPFIX community 
>> really need it?
> let's correct the sentence.  "... unless the IPFIX community really 
> needs it"

How do we know that? Even today, we create new IEs because we believe 
they will be useful in future. We don't ask the community to vote on how 
useful they are.


>>>     Non-flow information defining associations or key-value pairs, on the
>>>     other hand, are handled by IPFIX Options.  Here, the Information
>>>     Elements within an Options Template are split into Scope IEs which
>>>     define the key, and non-scope IEs which define the values associated
>>>     with that key.  Unlike Flows, Options are not necessarily scoped in
>>>     time; an Option is generally held to be in effect until a new set of
>>>     values for a specific set of keys is exported.  While Options are
>>>     often used by IPFIX to export metadata about the collection
>>>     infrastructure, they are applicable to any association information.
>>>        
>>
>> IIRC, there was some discussion about time-scoping IPFIX options and 
>> templates some years ago. eg, we can export a template, indicating 
>> that it will be valid from 6pm until midnight. Or pre-export an 
>> option, indicating that a new selectorAlgorithm will be in force from 
>> 6am.
> I don't recall the discussion, but I think the sentence is fine as it 
> includes "not necessarily"

I've no issue with the sentence; just recalling an old discussion that 
was related. I believe it was between Brian and Andrew.


>>> 8.  Defining Recommended Templates
>>>
>>>     New IPFIX applications SHOULD NOT, in the general case, define fixed
>>>     templates for export, as this throws away much of the flexibility
>>>     afforded by IPFIX.  However, fixed template export is permissible in
>>>     the case that the export implementation must operate in a resource
>>>     constrained environment, and/or that the application is replacing an
>>>     existing fixed-format binary export format in a maximally compatible
>>>     way.In any case, Collecting Processes for such applications SHOULD
>>>     support reordered Templates or Templates with additional Information
>>>     Elements.
>>>
>>>     An Internet-Draft clarifying the use of new Information Elements
>>>
>>>
>>>
>>> Trammell&  Claise         Expires April 4, 2011                [Page 14]
>>> 
>>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>>
>>>
>>>     SHOULD include any recommended Templates or Options Templates
>>>     necessary for supporting the application, as well as examples of
>>>    
>>
>> No it shouldn't, because implementers will blindly follow these and 
>> system specifiers will expect exactly these templates / options an no 
>> others, in order to be 100% compliant with the RFC / definition.
>>
>> Rather, the ID MUST specify which fields are required in the option / 
>> template, if any, and MAY give example options and templates, clearly 
>> labelling them as such.
> Like a remark above, we were targeting the predefined Options 
> Templates such as the one in the IPFIX and PSAMP protocols.

Even so, do you think implementers will a) blindly copy the drafts, or 
b) implement their own version (eg, with the fields in another order) ?

Worse, if someone does (b), there's no reason for it not to work. But I 
expect some collectors would reject it, or at least not recognise it as 
intended, because it didn't copy the RFC.


>>>     PSAMP packet reports (section 6.4) and extended packet reports
>>>     (section 6.5).  Recommended Options Templates are defined extensively
>>>     throughout the IPFIX documents, including in the protocol document
>>>     itself [RFC5101] for exporting export statistics; in the file format
>>>     [RFC5655] for exporting file metadata; and in Mediator intermediate
>>>     process definitions such as [I-D.ietf-ipfix-anon] for intermediate
>>>     process metadata.  The discussion in these examples is a good model
>>>     for recommended template definitions.
>>>    
>>
>> In your experience (or a quick poll?) do current IPFIX systems 
>> implement these exactly as specified, or does anyone implement them 
>> with the caveats described above (eg, in a different order, or with 
>> additional fields) ?
> no idea on this one.

As I said, a quick poll: ask the WG what they implement.
An interop would also answer this.


>>>        wlanSSID(146)<string>[v]
>>>    
>>
>> It's 147.
> Excellent catch.
> After all those years, I still impressed by your thorough reviews ;-)

Thank you :-)


>>>     IE.Due to the way Information Elements are represented in Options
>>>     Templates, all {scope} IESpecs must appear before any non-scope
>>>     IESpec.  The Flow Key Options Template defined in section 4.4 of
>>>     [RFC5101] in IESpec syntax is shown below:
>>>    
>>
>> Nonsense! That's only true when the IEs are being exported in an 
>> option on the wire, because that's how the protocol works.
>> However, when writing them down, they can be any way around that you 
>> like.
>>
>> eg, specifications written by people who are unfamiliar with the 
>> exact details of the export protocols, but who simply want to use our 
>> exporter, sometimes list fields in alphabetical or numerical order. 
>> As long as {scope} is clearly indicated at the relevant place, it's 
>> up to us as protocol experts to deal with the ordering detail.
> We can relax the sentence, but I'm still convinced the scope first 
> makes more sense.

It makes sense to us as protocol people. However, alphabetical or random 
order often makes more sense to those who simply want to export data, 
without knowing how the protocol actually works. Perhaps /recommend/ 
scope first.


P.