Re: [IPFIX] IPFIX at IETF 89, London

Dear all,

As technical contributor, I send my view on the two drafts from Paul:

The equivalent-ies draft is targeted at several use cases and with some of them I see need for discussion. I would have no problem with a standard that restricted to be only applied if an exporter changes the IE identifier without any other technical change, for example, after registering an enterprise-specific IE at IANA with a new number. But if this feature is used for other use cases as listed in the draft, I see a lot of issues that should be investigated. Two example issues are (1) exporters declaring "similar" IEs to be equivalent and (2) conflicting equivalence declarations from different exporters. There are more issues like these. Most of them can reduced to the core problem that the draft only defines a message format and not under which condition two IEs may or must not be decl
 ared equivalent.

For the unobserved-fields draft I see similar issues. The semantics is not fully clear and the same holds for implications on collectors. Does unobserved mean: I did not observe the IE, because there was no instance in any observed packet, because observation failed, because there is no instrumentation to observe the IE, or for any other reason. These are all different use case and there are more of them, maybe with more subtle differences, that need discussion.

My conclusion is, that I see both drafts addressing valid issues, but not as drafts to be finished soon. The both drafts look like good candidate an "experimental" RFCs, because "equivalence" of measurements and "unobserved" flow properties are concepts that may need time and operational experience to define them well.

Cheers,
    Juergen

> -----Original Message-----
> From: Benoit Claise [mailto:[email protected]]
> Sent: Dienstag, 11. Februar 2014 01:50
> To: Paul Aitken; Nevil Brownlee; Andrew Feren; IPFIX Working Group
> Cc: [email protected]; [email protected]
> Subject: Re: [IPFIX] IPFIX at IETF 89, London
> 
> Paul,
> 
> At this point, I will be listening to the chairs to see  ...
>      if this is really "interesting",
>      if there is enough support from the IPFIX community,
>      if there is enough discussion on it,
>      and if this work could be done in the decent time.
> 
> (*) I guess that I'm so much involved in IPFIX that I have strong opinions
> about your drafts. That's the price you pay for an AD who knows IPFIX by
> heart.
> 
> Regards, Benoit
> > Benoit,
> >
> >>> I've presented these ideas in previous WG meetings, where the
> >>> consensus was to wait for the next re-charter.
> >> Consensus, sure?
> >
> > Yes: the work was interesting, but not relevant to the current
> > charter. So, bring it up at the next recharter - which hasn't happened
> > yet.
> >
> >
> >> I checked the meeting minutes and I don't see that.
> >> What I recall is that two different proposals were discussed
> >> (draft-aitken-ipfix-equivalent-ies and draft-inacio-ipfix-penie-00),
> >> with no clear winner.
> >
> > Sure; each of these drafts has different merits. It would be up to the
> > WG to decide on the best solution.
> >
> > Look, here's a real problem in IPFIX which has resulted in not one but
> > *two* different drafts trying to solve it in different ways. Do you
> > propose to ignore it?
> >
> > P.
> > .
> >

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