Subject: Re: [ipfix] export packet length - LAST CALL

From: [email-masked]
Date: Tue, 06 May 2003 11:56:06 -0400

There seems to be a consensus that having a length field
in the packet header is a good idea.

I would like to bring this issue to last call. Anyone
opposed please state your case one more time.

If this doesn't seem like the right process to close
out issues, suggestions are welcome.

Paul

Maurizio Molina wrote:
> 
> Hi all,
> I hope not to rise an issue already discussed in the WG. If yes, I
> apologise in advance.
> If an IPFIX export packet is carried over TCP, it's not unusual that it
> gets split across multiple TCP segments.
> At the collector side, on the contrary, the implementation of the
> parsing is much simpler if only full export packet are parsed.
> If the information about the WHOLE export packet were contained in the
> header, it would be simple to wait until all the bytes composing an
> export packets are read from the TCP socket before beginning the
> parsing.
> Unfortunately, this information isn't currently contained in  Netflow 9
> packet header (I suppose, due to Netflow's 9 "bias" towards UDP...).
> Therefore, a parsing implementation having to deal with this
> "fragentation" problem without this information needs to be much more
> complicated (e.g. getting step by step the lenght of each flow set, see
> if it's all there, parse it and go on....).
> In summary: if IPFIX has to be carried over tcp, having the length of
> the export packet in the packet header would be beneficial.
> Regards,
> Maurizio
> 
> --
> Maurizio Molina
> Research Staff member
> Network Laboratories Heidelberg
> NEC Europe Ltd.
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany.
> Tel. (49)6221 90511-18 Fax: (49)6221 90511-55
> e-mail: [email-masked]
> Web: www.ccrle.nec.de
> 
> --
> 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: "Tal Givoly" <[email-masked]>
Date: Tue, 6 May 2003 10:11:17 -0700

I support this and prefer that any length field be encoded in a simple form
(either 2 bytes or 4 bytes, but not "extendable").

Tal

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of [email-masked]
Sent: Tuesday, May 06, 2003 8:56 AM
To: Maurizio Molina
Cc: [email-masked]
Subject: Re: [ipfix] export packet length - LAST CALL

Paul

--
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: Mark Fullmer <[email-masked]>
Date: Tue, 6 May 2003 16:36:09 -0400

To close this issue I would like to see the length specified
(2 or 4 byte fixed header field).  If 2 bytes then is replacing the existing
count field okay.

And yes, I think closing some of the recently discussed open issues with last
call's is the right way to get things moving.

mark

---

From: Ganesh Sadasivan <[email-masked]>
Date: Tue, 06 May 2003 16:51:29 -0700

> in the packet header is a good idea.

Fully agreed.
-ganesh

---

From: Nevil Brownlee <[email-masked]>
Date: Wed, 7 May 2003 17:49:39 +1200

Hi all:

Following up on the latest round of discusisons:

1) Using Randy & Rob's WG issues tracking system sounds fine.

2) Running Last Calls after mailing list discussion is a good way to
   reach consensus (and thereby close) issues.

3) On 'extensibility' of theIPFIX protocol.  My take on this is that
   - We want an information model which can be extended by adding new
     attributes, and a protocol which can handle such new attributes,
     so we need to put some design effort in now to achieve that.
   - For reliability we agreed that the initial version of IPFIX has
     to work with only one-way transport, but that we need sufficient
     hooks to add reliability later on.
   Both these goals are clearly being worked on, that's great.  But
   we need to be careful to balance our development efforts so as
   to produce a good, simple protocol now, which can be extended as
   needed later - without unduly delaying our efforts to get the 
   initial version done fairly quickly.  "By the end of this year" to
   reach near-final drafts sounds about right to me ...

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

---

From: Maurizio Molina <[email-masked]>
Date: Wed, 07 May 2003 10:46:33 +0200

I also support the encoding of the packet length in the header as a non-extensible,
fixed header field. IMO it could be done in one of the 3 following ways,
which I list in my order of preference:

1) 2 bytes, additional to the current header
2) 2 bytes, replacing the 2 bytes Count header
3) 4 bytes, additional to the curent header

Maurizio

---

From: [email-masked]
Date: Wed, 14 May 2003 08:13:19 -0400

We have consensus that the length field is needed. Now we need
the details.

I would like to see the first 4 bytes of the message look like this... 

     0                   1                   2                   3 
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |      Version                  |         Length                | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Keeping or not keeping the counter field is, I think, a separate
issue.

Paul

Maurizio Molina wrote:
> > > opposed please state your  0                   1                   2                 
> > >