Subject: RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt

From: <[email-masked]>
Date: Thu, 14 Feb 2002 06:14:58 -0500

Hello,

See my inline comments.

>Our charter tells us to "select a protocol by which
>IP flow information can be transferred" and I would
>prefer not to go beyond this.

Transfer  of flow information may not refer only to monitoring. I interpreted as  
one  can monitor and then transfer ( exchange) flows between endpoints . To do this one has
to  configure first what we are interested in - that means configure, monitor and transfer 
flows. 
 
I am not sure and would like to get clarify my doubt, 

If we have in-band management what is the problem? It's is a good choice whether
there is no flaw and it is good to control from one place to do both configure and manage the network
elements. If we provide proper security mechanism and ensure that the devices gets
the proper commands  similar to CLI then  what's the problem ?
 
I can understand  currently most of network elements configuration happens thro'   CLI or other mechanisms.... 

Take for example SNMP is used only as monitoring tool and but people are working on to making configuration
also thro' SNMP and seperate activity is going on in IETF community itself.

Regards
Ramg

--
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: Juergen Quittek <[email-masked]>
Date: Thu, 14 Feb 2002 18:45:17 +0100

Hi Ram,

--On 14 February 2002 06:14 -0500 [email-masked] wrote:

> Transfer  of flow information may not refer only to
> monitoring. I interpreted as one can monitor and then
> transfer ( exchange) flows between endpoints .
> To do this one has to configure first what we are
> interested in - that means configure, monitor and transfer
> flows.

No one doubts that we have to configure the device.
However, I do not understand how you imply from the term
"transfer IP flow Information" that transferring
configuration information in the opposite direction
is included.

    Juergen

> If we have in-band management what is the problem?
> It's is a good choice whether there is no flaw and it is
> good to control from one place to do both configure and
> manage the network elements. If we provide proper security
> mechanism and ensure that the devices gets the proper
> commands similar to CLI then what's the problem ?

I think Benoit already listed a several reasons. My major
one is complexity. It is really hard to specify a protocol
with all state transitions clearly and it is even harder
to implement it without (or almost without) bugs.

A general system design rule is that you cannot build
complex things from scratch. More complex systems should
be build upon the experience with less complex ones.
So, let's first build a simpler IPFIX without in-band
configuration and if this works fine and gets accepted,
then let's think about sophisticated ways of configuration
including in-band, out-of-band special protocol, COPS/SPPI
SNMP/SMI, etc.

>
> I can understand  currently most of network elements
> configuration happens thro'   CLI or other mechanisms....
>
> Take for example SNMP is used only as monitoring tool
> and but people are working on to making configuration

Yes, and I appreciate this and contribute to it now and then.
But why is this an agrument for in-band configuration? If
you suggest to have an IPFIX-MIB module, then we can argue
about that.

---

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

Hi Ram,
  What does inband configuration mean? I'm taking just a few ..
   1. Defining an observation point : Eg. The collector now has to say let the set of
       interfaces {a,b,..} belong to this observation point. So now the collector needs
       to know what kind of interfaces these are, their characteristics, whether they
       are groupable etc. All these rules have to be fed into the collector and these mostly
       would be vendor dependent.Boxes from  different vendors exhibit different
       characteristics for these groupings.
   2. Defining a metering process: Metering process can be defined at different levels
       at the time of observing the packets or after aggregating. There are a wide variety
       of metering mechanisms that are adopted today in terms of metering. In many cases
       the sequences in which metering is done is very important especially in the hardware
       switching platforms. Is the collector expected to know all these intricate details of a
       platform and send an in-band configuration message? Or are the existing products
       to be re-engineered to suit IPFIX protocol?

Thanks
Ganesh