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

From: Benoit Claise <[email-masked]>
Date: Thu, 14 Feb 2002 14:49:49 +0100 (CET)

Hi Ram and All,

We've discussing the in-band configuration for a few times without conclusions.
I propose to use this thread to arrive to a rough consensus and close the discussion one for all. Otherwise we're turning in circles and loosing everybody's time!
And if we can't get a consensus, the chairmen and area directors will have to take a decision.

Note: please let's try to concentrate on just one issue: in-band configuration and not capability negotiation and transport negotiation. One step at the time please.

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

What is the problem, you're asking?
There are actually no problems. I agree it would be the perfect world to have in-band configuration. But here are some arguments against the idea. Actually I even think a little bit further: the exporter configuration is out of the scope of this charter.

1. Do you want the working group to spend the time (the money) to developp a comon provisioning protocol, IF this is even possible to have an agreement on that accross the different vendor (probes and routers), which I think is impossible.

2. What would happen with proprietary features, which most likely will not be part of the IPFIX provisioning protocol. So anyway we will have to use a different way of provisioning the device, like CLI for example, next to IPFIX. This will bypass the use of IPFIX provisioning protocol.

3. How many vendors would implement this in-band configuration?
Because at the end this is the final question. What's the point to have a IETF protocol that no/not many vendors are going to implement.
Do you think that vendors will spend time and money to developp again another configuration interface, next to CLI, SNMP, XML, etc...?  And this just for an IPFIX protocol! 

4. SNMP is widely used. Why? because the S stands for simple.
And now, along the time, it has been evolving because there are new needs.
I would like to start with something Simple, that everybody agrees on.
And if there is a need for in-band configuration, then we can think of IPFIX2.
Why trying to have an ISO standard from version 1? ;)
You can give me a long list of nice idea about in-band configuration that I'm sure I would love to have in a perfect world but let's start with something Simple.
Don't forget that simplicity is the key for interoperability.
If not yet convinced: have you already compared Snmp and CMIP?

5. From the charter, "select a protocol by which IP flow information can be transferred" as Juergen said already. I would not beyond this point.
OK, you (Ramg) have a different view.

6. IPFIX stands for Flow Information eXport. So we have to standardize the export, not the configuration. So the direction:exporter -> collector and not the direction collector -> exporter. At least for version 1.

7. Email from Nevil Brownlee, Subject: [ipfix] Comments on 'goals of IPFX WG'
http://ipfx.doit.wisc.edu/list/ipfix/archive/0388.html
      2. IPFIX is *not* trying to standardise a flow meter, i.e. a network
      entity which measures flows - we already have RFCs which do that,
      e.g. those for RTFM (2720 .. 2724).  Existing widely-used
      implementations can remain different, but might perhaps be extended
      to report flow information in the IPFIX lingua franca.

      3. Instead, we recognise that network equipment vendors already have
      flow measurement systems implemented as part of their equipment.
      Our goal is to make the IPFIX flow information export system
      so good technically that all vendors will be happy to implement
      it, for the benefit of all users of the data.  A useful side-effect
      will be that IPFIX will make it easier to build and maintain 
      interoperable flow data collecting systems.

As we're not supposed to standardise a flow meter, why would we standardize its configuration? This email just expresses that the exporter configuration is out of the scope of the charter.

8. Juergen's argument: "Please consider that the meter will be built partially in hardware which is costly. Here we can save a lot by reducing some functions.
The data collector implemented by software can be much more flexible
with less cost."

Regards, Benoit.

>  
> 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: [email-masked]
Date: Thu, 14 Feb 2002 09:24:06 -0500

I vote no in-band configuration in IPFIX V1.