Subject: RE: [ipfix] extensibility of the ipfix protocol

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Wed, 21 May 2003 17:46:58 -0700

Sebastian,

  I'd agree that making the extensibility model more explicit is desireable.
  
  I'm still unclear on when or why one would extend information into the
header
vs. extending the data template sent itself.  I view the Option template as
flagging "pseudo-flow records" which have a set of attributes which carry
information other than actual flow details, e.g. configuration info or
counters.

  But isn't the combination of having Extensible Flow Records (for "real"
data) and Extensible Option Records (for "other" data) sufficient to move
any form of data the exporter wants to export?

  I guess this is what Mark was saying.  So I'd agree to that.

  I would see the same "Information Model" and extension model being used
for both Flow Record and Options.

  So to clarify, the header is fixed.  There is a distinction between flow
records and "other" data transmitted by the exporter.  And a common way
of defining how attributes which appear in either flow or option records
will be used.

  I'm not sure on why the "Scope" options should be treated differently
than any other attribute which may appear in an Option Record (Section 6.1)
in NFv9 specification.  Seems like things would be simpler and just as
effective if there were just a "Scope" attribute which could appear in
Option records.  In this case an Options template would be identical
to a Flow Template except it would have a FlowSet id of 1 vs. 0.

  Does that work?

Regards,

  Jeff Meyer

-----Original Message-----
From: Sebastian Zander [mailto:[email-masked]]
Sent: Wednesday, May 21, 2003 5:19 PM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: [email-masked]
Subject: Re: [ipfix] extensibility of the ipfix protocol

Jeff,

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> Sebastian,
> 
>   One of the issues of talking about extensibility in the generic sense is
> that it creates the temptation to specify generality without any driving
> use case.  "Someone may want to ..." seems like a slippery slope in
bounding
> requirements.
> 
>   In particular the case (1) extending fields in the header sounds
dubious.
> 
>   Since IPFIX is about getting flow records from the exporter to the
> collector,
> what is the purpose of allowing arbitrary header extensions?

The purpose is to send information per packet which is associated to or
necessary for using the rest of the information contained in the packet. For
me its pretty obvious that you need such an extension mechanism. And as Mark
pointed out this is already supported by the use of option templates.

netflow certainly meets the extensibility reqs but the netflow drafts do
*not*
a good job IMO in explaining its extensibility compared to e.g. what
Diameter
does. Instead of letting the reader guess the ipfix draft should have more
verbage.

>    In case (2), I'd certainly recommend option (b), making an explicit
> separation of namespaces (in this case integer values) by using unique
> vendor ids as independent "namespace authorities" seems like common sense.
> SNMP's been doing this for years, and Diameter is also following this
> convention as you point out.
> 
>   As for case (3), my understanding is that explicit type information in
> the payload/template itself did not achieve consensus.   This does mean
> that the numeric id (and optional vendorId) needs some concept of type,
> in a supporting document.  Having each attribute specify its type by
> reference to a type space defined in the base IPFIX Information Model
> is the way to go here (in my opinion).

Yeah, but the protocol draft must be aligned somehow to the information
model draft e.g. where are the types defined, where is the encoding
defined...

Cheers,

Sebastian

>   When a vendor extends the set of attributes, chosing a well defined
> type would be preferred to inventing a new type.  If the vendor cannot
> resist the overwhelming temptation to create new types, it can be 
> defined in their own information model.
> 
> 
> Regards,
> 
>   Jeff Meyer
> 
> -----Original Message-----
> From: Sebastian Zander [mailto:[email-masked]]
> Sent: Tuesday, May 06, 2003 6:55 PM
> To: [email-masked]
> Subject: [ipfix] extensibility of the ipfix protocol
> 
> 
> Hi,
> 
> although extensibility is mandatory by the requirements there hasn't
> been a lot discussion on how to do it and the chosen candidate protocol
> doesn't say much about extensibility. So here are my thoughts about
> extensibility.
> 
> The protocol specification must define how the protocol can be extended.
> 
> I see the following (but there may be more) ways of extending the
> protocol:
> 
> 1. Extending the fixed packet header
> This would allow to add new header fields without changing the
> protocol specification.
> 
> A bit (X) could be stolen from version to indicate the presence of
> extension header(s). Extension header(s) follow the fixed header if
> X=1. Extension header(s) consists of type, length and value.
> 
> 2. Extending the attribute/field space
> This is certainly needed. It could be done at least in two ways:
> a) A flat number space where numbers are specified in extension
>     RFCs and registered by IANA. A nice thing would a dynamic
>     space where numbers are not defined by IANA but could be negotiated
>     out of band (see payload type in the RTP specification). Such a
>     space could also be used as safe playground.
> b) A number space which is defined in extension RFCs (IANA) and the
>     possibility of using vendor specific attributes by having an optional
>     vendor ID field in the template specification. The vendor ID would
>     be IANA assigned but the vendor then could use its private field ID
>     space (see the Diameter Base protocol specification). Adds more
>     complexity and overhead to the protocol but could be very useful
>     when the protocol becomes widely adopted and a lot of extensions
>     are done.
> 
> 3. Extending the type space (if there are types at all)
> Probably there won't be much need to extent this because the protocol
> specification could do a good job of specifying all the basic types.
> If this really needs to be extended it would be probably done with a
> revised protocol specification.
> 
> Comments? Opinions?
> 
> Cheers,
> 
> Sebastian
> 

-- 
Sebastian Zander                         E-mail: [email-masked]
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany
www.fokus.fraunhofer.de/usr/sebastian.zander

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Sebastian Zander <[email-masked]>
Date: Thu, 22 May 2003 03:49:53 +0200

Jeff,

comments below

>   I guess this is what Mark was saying.  So I'd agree to that.

I also agree

> to a Flow Template except it would have a FlowSet id of 1 vs. 0.

I must admit that i don't 100% understand how scope is supposed to work.
The example in 10.4 and 10.5 seems somewhat flawed. The draft says there are
N scope fields and N option fields. Must the number of scope fields be equal
to the number of option fields? If yes this seems to waste lots of space if the
scope does not change (and it is not the case in the example). If not (probably
the authors meant M and N) the question is how to map the scope fields to the
options fields when there is more than 1 scope field (seems impossibe)?

Making scope another attribute sounds somewhat good. However has scope some
kind of grouping functionality or must it explicitly appear before each option?
Can scopes be combined such as e.g. this option is per interface vs. this option
is per template per interface? I think my questions are about grouping because
scope seems to have some kind of grouping function...

Cheers,

Sebastian

-- 
Sebastian Zander                         E-mail: [email-masked]
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  www.fokus.fraunhofer.de/usr/sebastian.zander