Subject: [IPFIX] modifying existing IEs

From: Paul Aitken <[email-masked]>
Date: Tue, 29 Mar 2011 14:02:17 +0100

Brian,

You talked about modifying existing IEs.

Suppose an IE modification doesn't break existing collectors.
However, existing collectors don't know about the modification.

eg, an additional value in an enumerated IE.

How do we determine what level of support a particular IPFIX device 
provides for that IE?
eg, if I say my EP supports IE.nnn, and you say your collector does - 
yet they may not be 100% interoperable.

Do we need version control at the individual element level, so we can 
discuss "version n" of IE.nnn ?

Thanks,
P.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 29 Mar 2011 17:34:33 +0200

Hi, Paul,

This was a point on the open issues slide, but was trying to speed through things today so it got missed...

So, do we need IE versions? In my opinion, yes: otherwise we can't change "future reserved" values in flags or code table IEs. I'd suggest a new column in the registry, initialized to 0 for existing IEs. If these are essentially code tables linked to subregistries, then the subregistries should probably have version numbers themselves.

A second question: what about an IANA Registry version - a serial number incremented by one on each modification, deprecation, or addition? The case for this is less clear for me.

Thoughts?

Best regards,

Brian

On Mar 29, 2011, at 3:02 PM, Paul Aitken wrote:

> How do we determine what level of support a particular IPFIX device provides for that IE?
> eg, if I say my EP supports IE.nnn, and you say your collector does - yet they may not be 100% interoperable.
> 
> Do we need version control at the individual element level, so we can discuss "version n" of IE.nnn ?
> 
> Thanks,
> P.

---

From: Paul Aitken <[email-masked]>
Date: Tue, 29 Mar 2011 17:34:13 +0100

Brian,

>  So, do we need IE versions? In my opinion, yes: otherwise we can't
>  change "future reserved" values in flags or code table IEs.

We can, though there won't be any reference point for us to indicate 
exactly what we support.

>  I'd suggest a new column in the registry, initialized to 0 for
>  existing IEs. If these are essentially code tables linked to
>  subregistries, then the subregistries should probably have version
>  numbers themselves.

OK.

>  A second question: what about an IANA Registry version - a serial
>  number incremented by one on each modification, deprecation, or
>  addition? The case for this is less clear for me.

Agreed:  if I add export of a new IE, or add new values in an existing 
IE, thus creating a new registry version,
then I'd be obliged to bring all my exports up to date in order to 
comply with the version I just made.

That may not be necessary, desirable or even possible.

P.

> > provides for that IE? eg, if I say my EP supports IE.nnn, and you
> > say your collector does - yet they may not be 100% interoperable.
> >
> > Thanks, P.

---

From: Paul Aitken <[email-masked]>
Date: Tue, 29 Mar 2011 17:34:17 +0100

Brian,

OK.

P.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 30 Mar 2011 10:20:39 +0200

Hi, Paul,

a couple of points inline...

On Mar 29, 2011, at 6:34 PM, Paul Aitken wrote:

> Brian,
> 
> > This was a point on the open
>       issues slide, but was trying to speed
> 
> 
>       > through things today so it got missed...
> 
> 
>       > 
> 
> 
> We can, though there won't be any reference point for us to indicate exactly what we support.

Unless the registry contains _every_ version of each IE. But then there would still be no _runtime_ support for this... 
> Agreed:  if I add export of a new IE, or add new values in an existing IE, thus creating a new registry version,
> then I'd be obliged to bring all my exports up to date in order to comply with the version I just made.
> 

Hm. Good point. Okay, so the consensus of two would be "versioned IEs, versioned subregistries referenced by IEs, no versioned registry"...

Cheers,

Brian