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

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 6 Feb 2002 23:35:11 -0800

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: Ganesh Sadasivan <[email-masked]>
Date: Thu, 07 Feb 2002 11:21:39 -0800

Hello Reinaldo,
   BGP does advertisements and not negotiation. The neighbours settle
down for
   the least common set of advertised fields. 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.
  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. 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

Reinaldo Penno wrote:

>  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-----
>      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 maintopic 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
>      complexwhy 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
>