Subject: [ipfix-arch] RE: IPFIX Architecture

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 6 Feb 2002 20:30:32 -0800

Hello Ganesh,

more on our thread...

:-----Original Message-----
:From: Ganesh Sadasivan [mailto:[email-masked]]
:Sent: Wednesday, February 06, 2002 8:06 PM
:To: Penno, Reinaldo [SC9:T327:EXCH]
:Cc: [email-masked]
:Subject: RE: IPFIX Architecture
:
:
:Hi Reinaldo,
:  See my responses inline  starting with [G].
:Thanks
:Ganesh
:
:Hello Ganesh/Folks
:
:my comments to Ganesh's comments.
:
:G:
:   Is the intention to make "capability negotiation" a MUST?
:   IMHO  the collector should accept whatever is
:   being exporterd by the exporter. In most of the cases (atleast
:   from a router point of view)  the collector is only an
:   intermediate box between the exporter and the final node that
:   interprets the export information. The job of the collector
:   from an information point of view would just be to grab all
:   that the exporter sends.
:   From an export protocol perspective, maybe it would make sense to
:   do some kind of negotiation. But here also with so much of
:   infrastructure existing already for reliability, security
:   etc the question is whether we want to come with a new model
:   or just concentrate on flow export.IMO there is no need for
:   negotiation.
:G:
:
:
:[Reinaldo] I basically disagree with this (and not because I wrote the
:capabilities section(;-)). Capability negotiation is very
:important part of the process. The capability negotiation will 
:negotiate
:the use existing protocols and methods, not new ones.
:
:[G] The existing protocols can be pre-setup in the exporter and
:collector by the administrator.
:There is whole suite of actions that needs to be done if one were to
:negotiate this operation.
:There is transport (TCP/SCTP/UDP), network layer (V4/V6),  maybe lower
:layers like
:MPLS, methods of authentication, security (ipsec, TCP MD5), etc. Yes we
:can build
:an automated system which detects all these narrows to the least common
:denominator,
:sets up all these stacks and performs the export. But I do not see
:anything extra we can
:achieve other than the added complexity. It This is not like a 
:data link
:protocol where one
:expects to negotiate and see the link up when a cable is plugged.

[Reinaldo] Well, first BGP also uses capability negotiation and it's not a
data link protocol. 

Second, between us, this administrator argument stuff is not really going to
fly. I can also instead of using IKE/PKI, pay somebody to enter all the
public-keys in world and retype every time them they are needed. IMO you are
not thiking outside the box here.

Third, the example I give on the text (LCP), fits this the IPfix model
really well since the endpoints have different needs and LCP is a protocol
negotiating parameters for the correct operation of another protocol (IPCP).

:
:More specifically "In most of the cases (atleast
:   from a router point of view)  the collector is only an
:   intermediate box between the exporter and the final node that
:   interprets the export information. "
:
:I disagree. Are you talking about some specific implementation?
:
:[G] No. A collection device is usually attached to multiple routers (I
:do not know about probes)
:There are some things like more aggregation that happens in the
:collector.
:This data gets fed  into analyzers which perform the final analysis.

Right, even then I still do not want to send useless and undecoded data. I
mean, if you assume the high bandwidth scenario that you mention, I also
antecipate a high volumen data, so the more focused the data, the least diak
space, the better and faster the analysis can de done.

Philosofically speaking, capability negotiation gives you the freedom tho
choose the system behavior amongst several choices.   I do not see from a
technical standpoint (and from a protocol evoution) a reason not to have it.
Through the capability negotiation you can say that you want for instance
LAP, Netflow or CRANE instead of IPix.

:
:And saying that he job of the collector from an information point of
:view would just be to grab all that the exporter sends it's
:not totally true. Maybe I want to use encryption, maybe I want to use
:TCP instead of SCTP, maybe I want to export overlapping
:flows..I do not want to send data that is not going to be useful or
:cannot be decoded properly. Maybe you have an specific
:implementaion in mind.
:
:[G] You can decide this by configuring the exporter to send 
:only what is
:required.

[Reinaldo] see above
:
:[G] Memory copy is only one issue. The memory buffering requirement to
:take care of
:even a single retransmission for high bandwidth router spans 
:10s to 100s
:of Megabytes.
:So TCP is out of question.
:In a network with reliability why add more task to the router processor
:by
:putting TCP?
:

So, based on your statement, should I assume that the only deployment
scenario acceptable would be where the collector and exporter are
co-located? I mean, you are saying that there is high bandwidth export data
and TCP is out of the quesion...Don't you think you are restricting things
too much here?

:
:[Reinaldo]. Again, are you talking about a specific implementation? I
:could use your own argument and say that this can be
:provided by the lower layers (TCP or SCTP). This is only a requirement
:for UDP.
:
:[G] This would help to have a consistent implementation across 
:transport
:protocols.

Consistent for who? For me putting a sequence number there is wasting space
and trying to mimic TCP/SCTP behavior. You have to decide if using functions
that the lower layers already provide is good or bad. You cannot choose them
selectively to fit your needs.

:
:[G] I did not mean the negotiation part:) The exporter sends collector
:the template format.

The capabilities negotiated (which include template negotiation) can be
renegotiated at any time.

cheers,

Reinaldo

---

From: "Will Eatherton" <[email-masked]>
Date: Wed, 6 Feb 2002 21:30:32 -0800

RE: IPFIX ArchitectureReinaldo,

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.

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.  We are seeing capability negotiation as complex, 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 ?). Last time I read the intro to IETF there was weight put into using experience gained from widely deployed protocols as templates for specifications.

Will

  -----Original Message-----
  From: majordomo listserver [mailto:[email-masked]]On Behalf Of Reinaldo Penno
  Sent: Wednesday, February 06, 2002 8:31 PM
  To: Ganesh Sadasivan
  Cc: [email-masked]
  Subject: [ipfix-arch] RE: IPFIX Architecture

  Hello Ganesh, 

  more on our thread... 

  [Reinaldo] Well, first BGP also uses capability negotiation and it's not a data link protocol. 

  Second, between us, this administrator argument stuff is not really going to fly. I can also instead of using IKE/PKI, pay somebody to enter all the public-keys in world and retype every time them they are needed. IMO you are not thiking outside the box here.

  Third, the example I give on the text (LCP), fits this the IPfix model really well since the endpoints have different needs and LCP is a protocol negotiating parameters for the correct operation of another protocol (IPCP).

  : 

  Right, even then I still do not want to send useless and undecoded data. I mean, if you assume the high bandwidth scenario that you mention, I also antecipate a high volumen data, so the more focused the data, the least diak space, the better and faster the analysis can de done.

  Philosofically speaking, capability negotiation gives you the freedom tho choose the system behavior amongst several choices.   I do not see from a technical standpoint (and from a protocol evoution) a reason not to have it. Through the capability negotiation you can say that you want for instance LAP, Netflow or CRANE instead of IPix.

  : 

  [Reinaldo] see above 
  : 

  So, based on your statement, should I assume that the only deployment scenario acceptable would be where the collector and exporter are co-located? I mean, you are saying that there is high bandwidth export data and TCP is out of the quesion...Don't you think you are restricting things too much here?

  : 

  Consistent for who? For me putting a sequence number there is wasting space and trying to mimic TCP/SCTP behavior. You have to decide if using functions that the lower layers already provide is good or bad. You cannot choose them selectively to fit your needs.

  : 

  The capabilities negotiated (which include template negotiation) can be  renegotiated at any time. 

  cheers, 

  Reinaldo

---

From: "K.C. Norseth" <[email-masked]>
Date: Wed, 6 Feb 2002 23:05:46 -0700

RE: IPFIX ArchitectureFolks,

|----- Original Message -----
|From: Will Eatherton
|To: Reinaldo Penno ; Ganesh Sadasivan
|Cc: [email-masked]
|Sent: Wednesday, February 06, 2002 10:30 PM
|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.
|
|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.  We are seeing capability negotiation as complex, 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 ?). Last time I read the intro to IETF there was weight put into using
experience gained from |widely deployed protocols as templates for
specifications.

We definitly want to build on past experience. A lot of us have implemented
NetFlow as well as other protocols.  Each of us can tell success stories as
well as horror stories of trying to implement them.  We all can see places
to improve - Templates, protocols, error management, whatever.

Our goal is an open standard, not a propritary standard.  As we build the
IPFIX standard, we want it to be a standard that everyone can say is the
best and can say it is everyones. I want the results of this WG to be
specifications so well written that we don't have to worry that we have
reverse-engineered every aspect, because every aspect of the standard is
clear-cut.  If we have a questionable topic, it needs to be clarified.  If
there is a question of scope, I would love to see it addressed.

K.C.

|Will
|
|
|-----Original Message-----
|From: majordomo listserver [mailto:[email-masked]]On Behalf Of
Reinaldo Penno
|Sent: Wednesday, February 06, 2002 8:31 PM
|To: Ganesh Sadasivan
|Cc: [email-masked]
|Subject: [ipfix-arch] RE: IPFIX Architecture
|

Hello Ganesh,
more on our thread...

:

--
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: "Will Eatherton" <[email-masked]>
Date: Wed, 6 Feb 2002 21:30:40 -0800

Will

  -----Original Message-----
  From: majordomo listserver [mailto:[email-masked]]On Behalf Of Reinaldo Penno
  Sent: Wednesday, February 06, 2002 8:31 PM
  To: Ganesh Sadasivan
  Cc: [email-masked]
  Subject: [ipfix-arch] RE: IPFIX Architecture

  Hello Ganesh, 

  more on our thread... 

  : 

  : 

  [Reinaldo] see above 
  : 

  : 

  : 

  cheers, 

  Reinaldo

---

From: [email-masked]
Date: Fri, 08 Feb 2002 11:50:37 -0500

I'll have to second that. We need to be careful here not
to define the best unused protocol ever. Configuration 
is a nasty issue and I believe we can come up with
a useful first cut IPFIX protocol without much in terms
of inband configuration.