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

From: "Reinaldo Penno"<[email-masked]>
Date: Thu, 7 Feb 2002 15:29:37 -0800

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

1. Embedding a set of  protocols (netflow, crane, lfap) into IPFIX is 
    a bad idea.  
 
Nope, I'm embeding them into IPfix. Please refer to my write up.
 
 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!!  
 
So, why people did it for BGP, PPP, OSPF and others? Why not configure
everything by hand? Why we have IKE? Why not pay someone to type in all keys
in worlds in a on-demand basis everytime two systems want to use IPsec. 
 
Well, we do not even need networks. We just need big printers, truck loads
of papers and  a priority account with Federal Express.
  
3. "Negotiation" is a multistep process where 2 sides try to converge 
   as "advertisement" is just a  broadcast of capabilities.  
 
humpf...I'm not even going to comments on that. This seems to me a desperate
argument. 
 
 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. 

-----Original Message----- 
From: Ganesh Sadasivan [ mailto:[email-masked]
<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,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: Ganesh Sadasivan <[email-masked]>
Date: Thu, 07 Feb 2002 16:22:58 -0800

1. That's what I would say to you. Read your own draft before
    jumping into conclusion.
2. The way  BGP and OSPF does their advertisment is very different
    from your proposal. Please read the respective RFCs for
clarification.
    Compare that with your proposal and you can find what the diff. is
    between "negotiation" and "advertisement".

I am stopping here and let the group decide which direction it wants to
go.

Regards
Ganesh

Reinaldo Penno wrote:

>          a bad idea. Nope, I'm embeding them into IPfix. Please
>      refer to my write up.There is nothing that we achieve out of
>      this. One might
>         no need for an IPFIX framework.  2 . Automatically
>      finding which transport one need to send on is only one
>        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!! So, why people did it for BGP, PPP, OSPF and
>      others? Why not configure everything by hand? Why we have
>      IKE? Why not pay someone to type in all keys in worlds in a
>      on-demand basis everytime two systems want to use
>      IPsec. Well, we do not even need networks. We just need big
>      printers, truck loads of papers and  a priority account with
>      Federal Express.
>
>      humpf...I'm not even going to comments on that. This seems
>      to me a desperate argument. At this point I wish someone
>      else from the list also raised
>      Nevil, Dave, do you guys have any suggestions?Thanks
>      Ganesh
>
>      Reinaldo Penno wrote:
>
>     >         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:52:17 -0500

One more thing on this. I might also be better
to do a IPFIX V1 without negotiation and then look
at it again for V2 when we have a better idea for the
IPFIX protocol and the kinds of things that would
benefit from negotiation.

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/