Subject: RE: [ipfix-arch] RE: IPFIX Architecture

From: "Harrington, David" <[email-masked]>
Date: Thu, 7 Feb 2002 09:20:30 -0500

Hi,
 
I've seen working group after working group get hung up on the lower-level
transport layer issues with TCP versus UDP versus SCTP.
 
I recommend that IPFIX take the modular approach - identify a transport
"box" in the architecture, then use a separate document to specify different
possible transport mappings, and the specifics of things like retries can be
described in the transport mapping document. Defining the fact that there is
a box to handle transport issues let's the rest of the work continue without
everything being dependent on the resolution of the transport issue.
 
I strongly recommend keeping the transport parameters out of the IPFIX
message. The IPFIX message should be consistent no matter which transport is
being used. Having lots of "optional" or conditional things in the IPFIX
message will make it dramatically harder for the two ends of a communication
to interoperate in a useful manner. 
 
The goal is to set a "standard" so behavior is consistent and each side
knows how to do their part of the job. It can be a good thing to favor
flexibility over rigidity in software development, but standards development
is slightly different than software development, and the primary goal should
be interoperability - that requires clearly defining the expectations. It is
a GOOD thing to make the standard "rigid" so there is interoperability. 
 
dbh

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 2:35 AM
To: [email-masked]; Ganesh Sadasivan
Cc: [email-masked]
Subject: RE: [ipfix-arch] RE: IPFIX Architecture

Hello Will,
 
first of all I would like to say that  I do not think some of the stuff
proposed by Ganesh/You is the right approach. I'm not saying Netflow is good
or bad, I'm just do not think is the right think to do, no more no less. 
 
If you give me consistent arguments I can easily be convinced otherwise.
Other comments inline.
 
 ----Original Message-----
From: Will Eatherton [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 9:31 PM
To: Penno, Reinaldo [SC9:T327:EXCH]; Ganesh Sadasivan
Cc: [email-masked]
Subject: RE: [ipfix-arch] RE: IPFIX Architecture
Reinaldo,

The notation for who is speaking in this thread is making me dizzy, but I
would like to state in a different way what Ganesh is saying on the main
topic of this thread.  For the application of router export to a collector
we are saying that allowing UDP without required capability negotiation (as
an option) is important. 
 
why is important? 
 
1. As I said, you exchange a mere few packets and both ends agree that
Netflow will be the IPfix protocol (or LFAP, or Diameter, or whatever) and
you are done. What you are trying to propose is to make the IETF protocol
rigid under the "using experience gained from widely deployed protocols "
umbrella in order to fit an already deployed protocol of a single vendor.
Unfortunaltely I do not agree with that. 
 
2. Ganesh also mentioned that this is data link stuff, which I said it
wasn't true since BGP implements a similar mechanism (BTW proposed by
Cisco). 
 
3. Then he said we should have sequence number on the IPfix protocol under
the "would help to have a consistent implementation across 
transport " umbrella. My argument is that this is something to solve a
specific UDP related problem only, and unless there is a better reason then
the one above, no matter how you slide or dice it, we are wasting header
space. 
 
Also I don't understand the desire in this thread to dance tip-toe around
the fact that there is already a widely deployed export protocol used in the
application of routers export and we (in this case Ganesh) are giving you
the feedback based on experience one vendor has gained from experience with
that protocol.   
 
And I agreed to some of these stuff ! But unfortunately some of other
feedback is biased to how Netflow is implemented. As i said, I just do not
think some of the stuff proposed by Ganesh/You is the right thing to do, no
more no less. 
 
 We are seeing capability negotiation as complex  
 
why it's complex? You have similar functionality already working for BGP
today. You also have similar functionality working for PPP and OSPF also
today.

 , not a requirement, and are suggesting it should not be a MUST for IPFIX
unless it isnt the goal of IPFIX to be implemented on routers (is it a probe
spec only ?).  
 
huh? Anyway, I think what I'm proposing is fair for everybody since several
protocols can fullfill the IPfix requirements (Netflow, LFAP, CRANE,
Diameter).and make the negotiation phase independent of the protocol used
for the data flow.
 
regards,
 
Reinaldo

---

From: Michael MacFaden <[email-masked]>
Date: Thu, 7 Feb 2002 13:37:25 -0800

>possible transport mappings, and the specifics of things like retries can be

For an application to be successful in the real world, the application's 
requirements should dictate a primary transport.

To support multple transports while supporting the "same" application would
mean some functions must then also be moved to/from the application/transport.

This is complex and leads to less interoperablity than we have now with
proprietary protocols. 

To date, we have one hard requirement - use a flow controlled protocol.
So either we use TCP/SCTP or use UDP with a flow control function  
in the application itself.

Since we are not charted to do a "protocol" the choice is clear.

Mike MacFaden

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