Subject: RE: [ipfix] Forming consensus on IPFIX default protocol

From: "Carter Bullard" <[email-masked]>
Date: Fri, 14 Nov 2003 22:52:17 -0500

Randall,
   I think you need to point out which Cisco
routers currently transport Netflow over SCTP.
Are there any?

Carter

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]] On Behalf Of
Randall Stewart (cisco)
Sent: Friday, November 14, 2003 8:11 PM
To: MEYER, JEFFREY D (HP-Cupertino, ex1)
Cc: 'Danny McPherson'; ipfix wg; Jim Bound
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
Jeff:

Some comments.

>Danny,
>
>  Thanks for the additional information.  Sorry I couldn't personally
attend
>the IETF, but dollars for travel are tight in our neck of the woods.
>
>  I certainly agree with your sentiment around UDP.  Regardless of IETF
>policy, I suspect this will dominate for some time.
>
>  The one concern is the "implement what you like aspect".  The decision
>dictates the mandatory support of SCTP, which is fine if you're running on
>Linux, but is much more problematic on other platforms.  There are key
>differences between deploying kernel space and user space implementations.
>And although a user space implementation of SCTP is readily available it
>effectively allows only one process to use SCTP, because all IP traffic
>which is targeted at the SCTP IP protocol id is targeted to a single user
>space process.
>
>
First this is totally untrue. The very first SCTP user space implementation
employed a deamon with inter-process communication. This is a very
workable arrangment if you want to use a user space library and it
prevents just such a situation.

>  As a product developer who needs to address customer's desires to run on
>Linux, HP-UX, Solaris and Windows, this mandatory aspect raises serious
>concerns, this is doubled when we are talking about Java based collectors.
>
>
>
Jim Bound of HP has told me that HP DOES have a kernel implementation of
SCTP.

A gentlemen (whom I can't name) has assured me that SUN will attend the
next bakeoff (June of 2004) and bring an implementation that will support
all extensions, is kernel based and is downloadable as a binary module from
the SUN web site.. A module that may not yet have all the extensions will
be available by the end of the year. So for sun you can at least use SCTP
after doing a pkg-add within two months.

Java is not a problem either. We use Java internally and already have a shim
that does the collection for UDP to avoid using the Java sockets layer since
the developer considered it inefficent... (or so I am told)... to change
to SCTP
is a minor tweak to his shim (a few lines of code). This is very dooable
since
Java after all is extensible and easy to work with :->

BSD of course has the KAME version that can be added.

The only vendor that does not yet have a core kernel stack is M$ .. but
there
are stacks for sale on M$... Which would mean purchasing it and going
through an installer.. Something anyone that has added anything to a M$
machine is familiar with [slide to the bottom and hit the accept key to
the legal garbage, and then press next repeatedly :-D].

Now sometime soon.. when I get back home next week  I will get a
web page up listing in one place everywhere SCTP is available and who
has it.

It will be on

www.sctp.org

>  In an ideal world all platforms would have SCTP out of the box and Java
>would have a nice object oriented class of sockets which supports it.  This
>is not the world today, nor do I expect it to be the world for some time.
>
>
>
Adding a package to a box to get SCTP in is not hard. On a sun box doing
a

pkg_add sctp-package

does not take a lot of effort... and it is all coded to the sockets api
just like
linux, just like BSD... not sure about the HP version.. I have added
Jim Bound who might be able to answer more specific details.

Jim, can you help Jeff out? He seems to be unaware that you have
a SCTP kernel version at HP?

>  If we're all willing to wink and agree that we're really just going to
use
>UDP for the forseeable future, and that the choice of SCTP is really
>targeted at some distant nirvana-esque future, then I guess it doesn't
>matter what is chosen.  This seems to be the status of Diameter today
>(although the wink is around TCP vs. SCTP).
>
>
This is all just nonsense. You can get SCTP if you want it. Does it show up
in every box yet, no. Can you get it for every box if you really want
it, yes.

Deployment arguments are not the sound basis for engineering decisions. We
decide the best transport for the protocol and use it, especially when
you can
find SCTP available in all major O/S flavors.. it may take you a little more
work.. aka "pkg_add xxx". But having to do a few extra steps for some of
the O/S's is not a reason to NOT make the right technical decision!

R

>  If however we want to deal with the brutal reality of the playing field
>today and define a protocol which can be readily realized on any number of
>platforms, then the only choice (given IETF constraints) is TCP.  As Stuart
>Smally says, "Denial ain't just a river in Egypt."
>
>
>

>Regards,
>
>  Jeff Meyer
>
>-----Original Message-----
>From: majordomo listserver [mailto:[email-masked]]On Behalf
>Of Danny McPherson
>Sent: Wednesday, November 12, 2003 9:34 PM
>To: ipfix wg
>Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>
>
>
>I saw lots of folks raise their hand when the "How many
>folks would like to see SCTP be the default" (~twice as many
>as opposed to TCP) question was asked and a great number
>of those were NOT Cisco employees -- not that it's even a
>relevant argument here as we're all individuals!
>
>I've never liked the hand-raising thing much anyways, and
>I'd prefer "humming" or nothing at all in the meeting, but
>nonetheless...
>
>As a large consumer of flow information in my day job, I
>suspect UDP will be all that matters in the near term (for
>a number of presumably obvious reasons), and when folks are
>ready to make a change SCTP does have some appealing
>attributes.
>
>And of course, you're always welcome to implement anything
>you'd like...
>
>-danny
>
>On Nov 12, 2003, at 6:09 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>
>
>
>>Nevil,
>>
>>  I guess I haven't heard anyone other than Cisco strongly supporting
>>SCTP,
>>but
>>then again that was my impression for NFv9 vs. the other candidates.  I
>>guess
>>will just sit back and let John Chambers do the driving...
>>
>>
>
>
>--
>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/
>
>
>

--
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

--
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: Nevil Brownlee <[email-masked]>
Date: Mon, 17 Nov 2003 07:22:16 +1300

> routers currently transport Netflow over SCTP.

You've raised a good point here, namely that the IETF works with rough
consensus and *running code*.  The thing about having *running code* is
that one is talking about a known quantity, not just speculation.

For example, although we clearly need to support TCP as an IPFIX transport
protocol, *no-one has yet provided the text to go into the IPFIX protocol
draft, section 5.1.*  Those who are implementing a TCP collector or exporter
clearly have the strongest interest in setting out how IPFIX should be mapped
to TCP - it's way past time when they sent in the text they'd like to see
there.  

Just to hammer the point - the goal of an IETF Working Group is to produce
documents.  That's what we need to be doing at this point.

When we have some implementation experience with IPFIX using both TCP and
SCRP we'll be in a better position to (at last) decide which will be the
mandatory-to-implement default.  And, of course, we'll be able to do some
imter-operability testing.

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: "Randall Stewart (cisco)" <[email-masked]>
Date: Sun, 16 Nov 2003 16:38:06 -0600

>SCRP we'll be in a better position to (at last) decide which will be the
Nevil:

I think you mean SCTP not SCRP..  :->

And as I said, its in process internally  :-D

R

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sun, 16 Nov 2003 16:36:27 -0600

>routers currently transport Netflow over SCTP.

Carter:

It is in process right now.. I am not in a position to tell
you the release and train.. but we have folks working on it.

R

---

From: Benoit Claise <[email-masked]>
Date: Wed, 19 Nov 2003 16:19:41 +0100

Nevil and Carter,

>that one is talking about a known quantity, not just speculation.
We are currenlty working on a SCTP-PR/NetFlow version 9 prototype.
We're targetting the first week on January.

Regards, Benoit.