Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 20 Feb 2002 02:22:42 -0800

Hello Fred,

comments inline..

>-----Original Message-----
>From: Fred True [mailto:[email-masked]]
>Sent: Wednesday, February 20, 2002 12:15 AM
>To: ipfix
>Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments
>on the Architecture Draft)
>
>
>Folks,
>
>A colleague of mine pointed me to the current discussion on 
>expanding the
>Cisco netflow protocol to allow better management of export 
>configuration,
>and I thought I'd add my $0.02.  

The discussion wasn't related to Netflow. It was related to IPfix.

I've read over most of the threads I
>could find, but please let me know if I'm missing the gist of what has
>been proposed, or forgive me if I'm not aware of the full 
>context of the
>discussion.
>
<snip>...<snip>

>
>On the point of managing netflow data collection, I gather that the
>proposal is to modify the netflow export protocol to be 
>bi-directional, so
>that a collector can send configuration messages to the routers rather
>than relying on the current CLI commands.  

Again, we were not talking about Netflow per se. 

I don't understand 
>the point of
>this.  Aside from requiring a whole lot of new development on the IOS
>side, 

right, right, I imagine this is what it boils down to...

I don't think any of us who manage routers really want a new
>paradigm for speaking to them, complete with requirements for 
>reliability,
>low overhead, security, etc.

hum...I think I disagree. I know other people that work in big SPs that
would disagree also. If CLI was so "easy" in a complex network such products
weren't being made.
http://www.cisco.com/warp/public/779/servpro/operate/csm/nemnsw/vpn/prodlit/

"Q. What are the key benefits of the Cisco VPN Solution Center for service
providers? 

A. The Cisco VPN Solution Center can help service providers to improve time
to market for new value-added VPN services, improve the quality of their
networks, reduce operational costs, reduce total cost of ownership, and
focus on business management and higher-level service-management
activities." 

Of course if you are not interest in cost and/or spend your days in some lab
I imagine that this is not a compelling reason.

>
>What we've asked for in the past (and have not yet convinced them to
>implement) is to have a netflow configuration MIB.  Everyone 
>can deal with
>SNMP, it's reliable and allows authentication, it allows you to read or
>write configuration info, and it's easy to create lightweight 
>SNMP clients
>on the collector (or management workstation) side to control the
>configuration, even in near-real-time (so, for example, you could tune
>your sampling rate based on observed data).  It seems to me 
>that leaving
>the plans for v9 netflow export alone and using SNMP for 
>dynamic netflow
>configuration would be the most expedient and architecturally sound
>solution.

We are talking about dozens of exporters possible talking to dozens of
collectors with different levels of compliance. How do you intend to do that
with SNMP? 

Having said that, I think a IPfix MIB is not a bad idea.

regards,

Reinaldo

---

From: Fred True <[email-masked]>
Date: Wed, 20 Feb 2002 16:30:48 -0500 (EST)

Reinaldo,

> would disagree also. If CLI was so "easy" in a complex network such products

Well let me be more clear: I was not advocating CLI - in fact quite the
reverse.  What I'm saying is that there are other extant protocols or
methods that can be used to accomplish collector-to-router communication
and configuration management.  SNMP seems like a decent choice to me, for
the reasons I stated, but I am sure there are other options.  What I don't
think we need, though (as someone who works with a very large ISP,
especially in the area of measurement and instrumentation) is a brand new
paradigm specific to Netflow or IPFIX.

I don't specifically know what IPFIX is proposing that is different than
Netflow or packet header sampling (can someone point me to the proposal?);
but if we are dealing with some type of router based traffic measurement,
the configuration parameters, even in extreme cases, are fairly
straightforward.  You set interfaces you want to monitor, filters (using
whatever syntax is appropriate for the router), aggregation schemes,
sampling rates or methods, collection destinations, etc.

From our point of view, we are already managing thousands of devices with
SNMP.  There are an abundance of tools for dealing with SNMP: everything
from commerical products with correlation across many layers of devices to
Perl modules for developers or prototypers.

> collectors with different levels of compliance. How do you intend to do that

What's so difficult about that?  We plan to deal with hundreds, not dozens
(in fact we currently deal with more than dozens).  If there is a
published MIB, even if there are several versions across different
devices, I don't see the scaling problem.  Just make sure the tools you
run on your collectors are portable, and know how to speak to the
available versions via simple inquiries.

The point I *can* see is that if this is to be supported across many
vendors, it would be nice to have a standard syntax for things like
filters, sampling parameters, etc.  Is that what IPFIX intends?

-fred

--
Fred True				"My name is Ozymandias, King of Kings:
Internet and Network Systems Research	 Look on my works, ye Mighty,
AT&T Labs-Research, Florham Park, NJ	 and despair!"
[email-masked]					-P. B. Shelley

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