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

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

Hello,

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

Are you proposing something like in the req. draft?
The exporter configuration is out of the scope of the initial version of IPFIX,
but could be investigated at a latter stage.

Regards, Benoit.
> 
> 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/
> >

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