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

From: "Reinaldo Penno"<[email-masked]>
Date: Thu, 14 Feb 2002 07:23:49 -0800

Hello,

Last I counted we had most people saying that it's useful but we should
tackle this later, except for Me, Kevin and Ram that would like to see it
now. K.C said it was nice, Paul and Mike that it was for after "IPfixv1" and
Benoit, Ganesh, Juergen and Will saying no.

So in terms of number of vendors (I agree with Benoit that the important
thing is the number of vendors adopting it) it seems there is an agreement
to investigate this problem at some point. We need then to choose the words
that reflect this position on the arch draft/req. Suggestions? 

Having said that I would like to clarify some points:

One is that the idea was never to have a "common provisioning protocol".
Provisioning seems a pretty heavy word. The in-band config would facilite
things like template negotiation associate with flow metering capabilities
and the like. So, in fact it would help configuring vendor specific features
like extended flow information, etc 

Second, the fact that "the meter will be built partially in hardware which
is costly. Here we can 
save a lot by reducing some functions. " is a implementation
issue...Somebody else cold say that their meter would be build on software
(a PC-appliance for instance) so they do not care. So trying to be fair with
all possible IPfix users, I think we should drop this specific point
altogether.

Now, as I said, I think Benoit had a good point on the adoption of such a
mechanism, ie, How many vendors would implement this in-band configuration.
If we can base the vendors on the people that work for them, I would say up
to this point 4-5 (not sure what percentage of companies that will really
build an IPfix collector or exporter this represents).

regards,

Reinaldo

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Thursday, February 14, 2002 6:24 AM
>To: Benoit Claise
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to
>draft-ietf-ipfix-reqs-00.txt
>
>
>
>I vote no in-band configuration in IPFIX V1.
>
>Benoit Claise wrote:
>> 
>> 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/
>
>--
>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 19:07:23 +0100

Reinaldo,

--On 14 February 2002 07:23 -0800 Reinaldo Penno <[email-masked]> wrote:

>
> Hello,
>
> Last I counted we had most people saying that it's useful but
> we should tackle this later, except for Me, Kevin and Ram that
> would like to see it now. K.C said it was nice, Paul and Mike
> that it was for after "IPfixv1" and Benoit, Ganesh, Juergen and
> Will saying no.

I share Paul's and Mike's position.

> So in terms of number of vendors (I agree with Benoit that the
> important thing is the number of vendors adopting it) it seems
> there is an agreement to investigate this problem at some point.
> We need then to choose the words that reflect this position
> on the arch draft/req. Suggestions?

This is the requirements discussion, not the architecture discussion.
So, there is the possibility of not having a in-band configuration
requirement, which still would in no way excludes in-band configuration
in the architecture.

There have been several arguments that there are too many MUSTs in
the requirements and I am currently looking for superfluous ones.
Most of the MUSTs were derived from the applications.

What application would necessarily require in-band configuration?

If we do not find a good argument here, my proposal is not to
mention in-band configuration in the requirements document.

    Juergen

> One is that the idea was never to have a "common provisioning protocol". Provisioning seems a pretty heavy word. The in-band config would facilite things like template negotiation associate with flow metering capabilities and the like. So, in fact it
> would help configuring vendor specific features like extended flow information, etc
>
> Second, the fact that "the meter will be built partially in hardware which is costly. Here we can
> save a lot by reducing some functions. " is a implementation issue...Somebody else cold say that their meter would be build on software (a PC-appliance for instance) so they do not care. So trying to be fair with all possible IPfix users, I think we
> should drop this specific point altogether.
>
> Now, as I said, I think Benoit had a good point on the adoption of such a mechanism, ie, How many vendors would implement this in-band configuration. If we can base the vendors on the people that work for them, I would say up to this point 4-5 (not
> sure what percentage of companies that will really build an IPfix collector or exporter this represents).
>
> regards,
>
> Reinaldo
>
>

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