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

From: "Reinaldo Penno"<[email-masked]>
Date: Thu, 7 Feb 2002 13:13:54 -0800

Hello Ganesh,
 
please refer to my comments.

-----Original Message-----
From: Ganesh Sadasivan [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 11:22 AM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: [email-masked]; [email-masked]
Subject: Re: [ipfix-arch] RE: IPFIX Architecture

Hello Reinaldo, 
   BGP does advertisements and not negotiation. The neighbours settle down
for 
   the least common set of advertised fields.  
 
oh Come on man (;-). That's dictionary play. It does capability negotiation
through "advertisements" since in the BGP world peers send "advertisements"
to each other. If you look at  <http://www.ietf.org/rfc/rfc2842.txt>
http://www.ietf.org/rfc/rfc2842.txt it's going to be clear that they want to
settle down on a set of common optional parameters. You can call this
something else, I call it capability negotiation, but the purpose is the
same.
 
 But the most important point is that 
   only the attributes that pertain to the BGP are negotiated and nothing
outside its 
   framework like transport connection, authentication (TCP MD5) etc.  
 
okay. So if we settle down that, for instance, UDP is the protocol of choice
then we do not need to negotiate that. But if we do not settle for that, we
need something to tell me what's going to be the transport protocol since I
do not want to understand/icode/nterpret headers that I'm think are not
useful if, for instance, I implemented with TCP.
 
Also, I'm not advocating negotiating TCP options and things like that, it's
only the transport protocol used. Any TCP options are done through TCP
itself. The idea of CN is that in a heterogeneous network you only need to
configure what the peers are, you do not need to say "ohh this is anetflow
collector", this is a "CRANE exporter", "this is a IPfix v1 exporter", etc.
 
okay, let me backtrack a little bit. did you read my capability negotiation
write up?  I proposed it as a totally different phase disconnect to any data
flow. After the capability negotiation is done the connection is teared down
and the protocol of choice gets to work.

  They are configured in the neighbours  instead. 
   Extending this to IPFIX framework, the only set of attribs that may need
negotiation is 
   templates and this too is optional.  
 
There are other parameters, please refer to the write up. Wouldn't be nice
that instead of configuring netflow v1, v5, v9, etc to have this done
automatically and knowing why it worked or not? What I'm proposing is a
control communication completely orthogonal to the data communication. You
do not need to change, for instance, netflow at all.  It's not built in on
the protocol like BGP.
 
thanks,
 
Reinaldo
 
 Atleast in router case I do not see a need to do this. 
   BGP peers are not discovered or auto negotiated. They are configured
instead. 
   Negotiation is a great idea. But one has to look at the practical aspects
also:)    

Thanks 
Ganesh

---

From: Ganesh Sadasivan <[email-masked]>
Date: Thu, 07 Feb 2002 14:08:51 -0800

1. Embedding a set of  protocols (netflow, crane, lfap) into IPFIX is
    a bad idea. There is nothing that we achieve out of this. One might
   as well use just the protocol and not IPFIX. A box usually would
   adopt only one export protocol and if it knows the collector there is

   no need for an IPFIX framework.

2. Automatically finding which transport one need to send on is only one

   small piece of information to setup the connection. One has to know
   the dst port to send on, TCP options like MD5 etc which needs to
  be configured at both ends anyways. Adding another piece of CLI or
  so to tell use TCP/UDP/. is much more simpler than creating a
negotiation
  to do this. I really fail to understand what you gain in this whole
process
  of negotiating transport and such rather than the added complexity!!

3. "Negotiation" is a multistep process where 2 sides try to converge
   as "advertisement" is just a  broadcast of capabilities.

At this point I wish someone else from the list also raised
their opinion on this topic rather than we 2 debating with each other.
Nevil, Dave, do you guys have any suggestions?

Thanks
Ganesh

Reinaldo Penno wrote:

>  Hello Ganesh,please refer to my comments.
>
>         BGP does advertisements and not negotiation. The
>      neighbours settle down for
>         the least common set of advertised fields. oh Come on man
>      (;-). That's dictionary play. It does capability negotiation
>      through "advertisements" since in the BGP world peers send
>      "advertisements" to each other. If you look at
>      http://www.ietf.org/rfc/rfc2842.txt it's going to be clear
>      that they want to settle down on a set of common optional
>      parameters. You can call this something else, I call it
>      capability negotiation, but the purpose is the same.
>
>         only the attributes that pertain to the BGP are
>      negotiated and nothing outside its
>         framework like transport connection, authentication (TCP
>      MD5) etc. okay. So if we settle down that, for instance, UDP
>      is the protocol of choice then we do not need to negotiate
>      that. But if we do not settle for that, we need something to
>      tell me what's going to be the transport protocol since I do
>      not want to understand/icode/nterpret headers that I'm think
>      are not useful if, for instance, I implemented with
>      TCP.Also, I'm not advocating negotiating TCP options and
>      things like that, it's only the transport protocol used. Any
>      TCP options are done through TCP itself. The idea of CN is
>      that in a heterogeneous network you only need to configure
>      what the peers are, you do not need to say "ohh this is
>      anetflow collector", this is a "CRANE exporter", "this is a
>      IPfix v1 exporter", etc.okay, let me backtrack a little bit.
>      did you read my capability negotiation write up?  I proposed
>      it as a totally different phase disconnect to any data flow.
>      After the capability negotiation is done the connection is
>      teared down and the protocol of choice gets to work.
>         Extending this to IPFIX framework, the only set of
>      attribs that may need negotiation is
>         templates and this too is optional. There are other
>      parameters, please refer to the write up. Wouldn't be nice
>      that instead of configuring netflow v1, v5, v9, etc to have
>      this done automatically and knowing why it worked or not?
>      What I'm proposing is a control communication completely
>      orthogonal to the data communication. You do not need to
>      change, for instance, netflow at all.  It's not built in on
>      the protocol like BGP.thanks,ReinaldoAtleast in router case
>      I do not see a need to do this.
>         BGP peers are not discovered or auto negotiated. They are
>      configured instead.
>         Negotiation is a great idea. But one has to look at the
>      practical aspects also:) Thanks
>      Ganesh
>

---

From: [email-masked]
Date: Mon, 11 Feb 2002 09:46:45 -0500

I'll just restate my position. I think configuration 
in general should be done outside the protocol. The
only exception so far for me is allowing in-band the 
setting of fields reported.

It is a difficult point to argue because Reinaldo can
show all the nice things you can do with in-band negotiation,
which is true. But the devil and the hassle is in the details
which you don't see until implemention. By then it is too 
late to turn back.

For example, one of the things we configure is what ports
we want to collect flows on. Is that done in-band? Does
the collector tell the exporter? We also tell it the
pattern of flows to report on (done as an ACL). Is that
done in band? What happens if I'm talking to more than
one collector and I get conflicting requests?

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/