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

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Wed, 21 May 2003 16:34:37 -0400

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?

   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).

  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/

--
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 02:18:59 +0200

Jeff,

> 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.

> 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

-- 
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