Subject: [ipfix-req] requirement draft: MAY/SHOULD/MUST be flexible?

From: Benoit Claise <[email-masked]>
Date: Thu, 25 Jul 2002 17:22:29 +0200

All,

I've been reading one more time  
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-04.txt, since 
we are approaching the WG last-call.
And I would like to get your opinions on the following topic.

It contains:

    6.2.  Data Model

       The data model describes how information is represented in flow
       records.

       The data model MUST be extensible for future attributes to be added.
       Even if a set of attributes is fixed in the flow record, the data
       model MUST provide a way of extending the record by configuration or
       for certain implementations.

       The data model used for exporting flow information _MAY be flexible_
       concerning the flow attributes contained in flow records. A flexible
       record format would offer the possibility of defining records in a
       flexible (customizable) way regarding the number and type of
       contained attributes.

But I'm thinking that, if we want a good IPFIX protocol, the data model 
MUST be extensible AND flexible.
My arguments, based on our expierence with Netflow, are:
- a flexible data model would reduce the bandwidth requirements for 
exporting the flow records (by exporting only the attributes the 
collector application is interested into). And we know that we can 
export a lot of flow records.
- if we data model is extensible but not flexible, each time we define a 
new attribute to be exported, we must change the DATA MODEL at the 
collector's side,  I.e. the new structure (or the set of attributes in 
the flow record) that the collector can now receive.
While if the data model is extensible and flexible, each time we define 
a new attribute to be exported, we just have to add the attribute to the 
INFORMATION MODEL at the collector's side; this is a lot easier!

Now, I'm not discussing the way to achieve this flexibility (TLV, 
Template, you name it...), as this discussion doesn't pertain to the 
requirement draft but to the architecture one.

What do you think?

Regards, Benoit.

--
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: Juergen Quittek <[email-masked]>
Date: Fri, 26 Jul 2002 15:20:19 +0200

--On 25 July 2002 17:22 +0200 Benoit Claise <[email-masked]> wrote:

> All,
>
> I've been reading one more time  http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-04.txt, since we are approaching the WG last-call.
> But I'm thinking that, if we want a good IPFIX protocol,
> the data model MUST be extensible AND flexible.
> - a flexible data model would reduce the bandwidth requirements
>   for exporting the flow records (by exporting only the attributes
>   the collector application is interested into). And we know that
>   we can export a lot of flow records.
> - if we data model is extensible but not flexible, each time we
>   define a new attribute to be exported, we must change the DATA MODEL
>   at the collector's side,  I.e. the new structure (or the set of attributes
>   in the flow record) that the collector can now receive. While if the
>   data model is extensible and flexible, each time we define a new attribute
>   to be exported, we just have to add the attribute to the INFORMATION MODEL
>   at the collector's side; this is a lot easier!
>
> Now, I'm not discussing the way to achieve this flexibility (TLV, Template,
> you name it...), as this discussion doesn't pertain to the requirement draft
> but to the architecture one.

I see your point. However, the flexibility requirement is about efficiency,
not about functionality, so maybe a MUST would be too strong?
What about choosing SHOULD?

Any other opinion?

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Tue, 30 Jul 2002 12:45:16 +0200

Juergen,

>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-04.txt, 
>> since we are approaching the WG last-call.
>> Template,

Yes this is a requirement for the IPFIX protocol to be efficient   :)

> Any other opinion? 

If there are no other opinions, I think a SHOULD is a good compromise!

Regards, Benoit.

---

From: Sebastian Zander <[email-masked]>
Date: Tue, 30 Jul 2002 14:13:17 +0200

Hi Juergen, Benoit,

if we make this a SHOULD or MAY I am afraid that we might end up with a
data model which is not flexible. I think the data model can be flexible
and still efficient. As Benoit said in certain cases it could be even
more efficient because of the flexibility. Therefore I support the MUST.

Cheers,

Sebastian

-- 
Sebastian Zander                         E-mail: [email-masked]
FhI FOKUS / Global Networking (GloNe)    Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  www.fokus.fhg.de/usr/sebastian.zander

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 30 Jul 2002 14:23:36 +0200

Sebastian,

Thank you for your comment. At the Yokohama session we planned to have
the next (and hopefully final) version of the requirements quite soon.
So if noone else speaks up soon, we will have it as a MUST.

   Juergen

---

From: [email-masked]
Date: Tue, 30 Jul 2002 11:03:47 -0400

I guess I don't see how it can be extensible and
inflexible. How can you add new fields without
having some way of sending them without breaking
older applications?

Paul

---

From: "Peter Ludemann" <[email-masked]>
Date: Tue, 30 Jul 2002 22:12:16 -0700

We can add new fields if the receiver just ignores fields that it doesn't
know about. Of course, this can't always be done, but it often can be.
(Similar to databases: adding new fields breaks queries that do "SELECT *"
but doesn't break queries that specify the fields explicitly).

We can also add new "templates" or "structs" (in the C sense) if the
receiver just ignores them (an ACK would simply mean that the data has been
received and processed [thrown away]).

We can even delete fields if the receiver is treats missing fields as "null"
and can handle them.

These issues are all outside the protocol; they simply refer to the way the
sender and receiver behave.

As to flexibility  vs efficiency: there's no reason why the protocol cannot
be both flexible and efficient. However, the notion of efficiency might need
to be tightened up a bit ... do we mean "size efficiency" or "processing
efficiency" on the sender or receiver? I think that the requirements should
be primarily processing efficiency on the sender (to minimize CPU overhead)
and - to the degree that this doesn't affect processing efficiency - size
efficiency. The reason for size efficiency is that a reliable connection
requires keeping the sent data until it is acknowledged [of course, the
implementation may choose to have timeouts and maximum memory restrictions
to handle situations of extended disconnections].

(For both size and processing efficiency, XML encoding would be a poor
choice. For processing efficiency, compression is probably a bad idea. There
are some subtleties here: e.g., for numbers, issues of big-endian and
little-endian should probably be resolved in favour of convenience of the
sender; the assumption being that the receiver has more CPU and can do
byte-swapping as needed rather than forcing everything into XDR form.)

- peter

> -----Original Message-----
> From: majordomo listserver [mailto:[email-masked]]On Behalf
> Of [email-masked]
> Sent: Tuesday, July 30, 2002 8:04 AM
> To: Benoit Claise
> Cc: Juergen Quittek; [email-masked]
> Subject: Re: [ipfix-req] requirement draft: MAY/SHOULD/MUST be flexible?
>
>
>