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

[Benoit Claise <[e-mail]>]

Hi Kevin,


>
>
> > -----Original Message-----
> > From: Benoit Claise [mailto:[e-mail]]
> > Sent: Thursday, February 14, 2002 12:39 PM
> > To: [e-mail]; [e-mail]; [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to
> > draft-ietf-ipfix-reqs-00.txt
> >
> >
> > Hi Kevin,
> >
> > >
> > > My comments are inserted, thanks.
> > >
> > > Kevin
> > >
> > > > -----Original Message-----
> > > > From: majordomo listserver
> > [mailto:[e-mail]]On Behalf
> > > > Of Benoit Claise
> > > > Sent: Thursday, February 14, 2002 10:09 AM
> > > > To: [e-mail]
> > > > Cc: [e-mail]; [e-mail];
> > > > [e-mail]
> > > > Subject: Re: in band configuration? RE: [ipfix-req] Proposed
> > changes to
> > > > draft-ietf-ipfix-reqs-00.txt
> > > >
> > > >
> > > > Ramg,
> > > >
> > > > >
> > > > > >> 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.
> > > > >
> > > > > You yourself is convinced to have single point configuration
> > > > and control thr' inband
> > > > > management. I can see some of your good points and issues. We
> > > > are not thinking
> > > > > here exporter or collector configuration split or where to
> > > > place the functionality etc.
> > > > > If there is a  real potential problem then we should consider
> > > > this as part of charter
> > > > > rather than just postponing IPFIX version1 ... version 2.... etc....
> > > >
> > > > But the entire issue, I don't see which problem we are trying to
> > > > solve by having in-band configuration,
> > > > except that it could be a nice feature to have.
> > > >
> > >
> > > I would underscore the fact that exporters might be probes and
> > midboxes that need to support more data collection functionality.
> > Without some form of configuration, preferably in-band, their
> > applications will be significantly limited.
> >
> > Obviously, we want to be able to configure an exporter. For
> > example, just to configure what the template should be.
> This I totally agree with you, template configuration/negotiation is the minimum the IPFIX should support. And it should be done in-band as this is an integral part of a flow export protocol.

Don't make me say what I haven't said.
My view is: CLI (or any other means) configuration. No inband configuration within IPFIX.
And no negotiation. But again, this should be another thread.

>
>
> > The only conclusion that this thread draw is: in or out-of-band,
> > I mean CLI configuration of the exporter or the exporter, via the
> > IPFIX protocol, must be able to configure the exporter.
> I am not very clear about this point.  Could you clarify? I assume in-band configuration refers to configuration through IPFIX control messages.

Not in my mind. see my point above

Regards, Benoit

>
>
> > >
> > >
> > > > >
> > > > >
> > > > > There is always a debate one can make whether to consider all
> > > > the problems at forehand
> > > > >  or do incremental activity. I do not want to get into that.
> > > > >
> > > > > >
> > > > > >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.
> > > > > >
> > > > >
> > > > > Flow information protocol is extensible and we cannot deal
> > in defining
> > > > > flows for each  each and every  protocols. Flow information can
> > > > be exchanged between
> > > > > two endpoints if they know how to interpret the fields which
> > > > may be vendor specific.
> > > >
> > > > The information model must be extensible. Agreed, but this is a
> > > > different issue than inband
> > > > configuration.
> > > > BTW, In Ganesh and I's draft, the collector will be able to
> > > > decode a template, even if it doesn't know
> > > > anything about some specific fields.
> > > >
> > >
> > > Through template negotiation/acknowledgement, the correct
> > context can be set at the IPFIX end-points.  This will ensure
> > correct interpretation of received data by the collector.  The
> > periodic template refreshing scheme is less robust as losses of
> > the template information will put the collector on hold.  For
> > some applications that require real-time information collection,
> > this means the flow information will be delayed at least another
> > refreshing cycle.
> >
> > This is not correct but I would come back on that in other thread, later.
> > Negotation is something else that the group will have to find a
> > rough consensus on..
> > I propose to just concentrate on one issue at the time, if we
> > want to be efficient: in or out-of-band configuration. No
> > worries, the thread for negotation would follow!
> >
> Agree
>
> > Regards, Benoit.
> >
> > >
> > > The CRANE protocol
> > http://www.ietf.org/internet-drafts/draft-kzhang-crane-protocol-02
> > .txt uses template negotiation to achieve flexibility and
> > extensibility of flow information export. Very little contraints
> > are imposed on what can be exported. The template negotiation
> > typically happens once during set-up to allow the IPFIX
> > end-points to sync. on a set of templates.  The actual flow
> > information is transfered in its native form accompanied by a
> > template ID. I believe this is a nicer approach.
> > >
> > > > >
> > > > >
> > > > > With  SNMP also every protocol defines the MIB and uses SNMP to
> > > > exchange the
> > > > > information.
> > > > >
> > > > >
> > > > > Typically, Management protocols are  provides mechanisms how to
> > > > exchange and not what to exchange.
> > > > > The latter thing is more addressed by MIB which is a generic to
> > > > represent attributes which are to
> > > > > be managed.
> > > >
> > > > Agreed. I don't recall writing something which goes against that
> > > > principle.
> > > >
> > > > >
> > > > >
> > > > > So in principle we have MIB and management protocol two are
> > > > logically separate functional entities.
> > > >
> > > > Same remark
> > > >
> > > > >
> > > > >
> > > > > Ok,its  a matter of  time and design team effort to put that,
> > > > we should not leave any items
> > > > > which are essential candidates.
> > > > >
> > > > >
> > > > > >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.
> > > > > >
> > > > > See my previous comments.
> > > > >
> > > > > >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?
> > > > > >
> > > > >
> > > > > I agree that we start with simple, that does not mean that  we
> > > > should  complete
> > > > > in hurry without addressing the other issues.
> > > > >
> > > > > My advice is that be patient and cool when you  reply. What i
> > > > asked is more of
> > > > > clarification but your reply is not on those lines.
> > > > >
> > > > >
> > > > >
> > > > > >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.
> > > > >
> > > > > We are not talking version of IPFIX in our charter and it may be
> > > > > your assumption.
> > > >
> > > > No assumption here, I'm only trying to find a consensus.
> > > > So instead of just saying NO, I'm proposing the following:
> > > > if there is a really a need (a real potential problem, according
> > > > to your own words), it's time to give
> > > > your technical arguments.
> > > > If not, let's investigate this nice-to-have feature later, maybe
> > > > in version 2.
> > > >
> > > > Regards, Benoit
> > > >
> > > >
> > > >
> > > > --
> > > > Help        mailto:[e-mail] and say "help" in
> > > > message body
> > > > Unsubscribe mailto:[e-mail] and say
> > > > "unsubscribe ipfix" in message body
> > > > Archive     http://ipfix.doit.wisc.edu/archive/
> > > >
> > > >
> > >
> >
> >


--
Help        mailto:[e-mail] and say "help" in message body
Unsubscribe mailto:[e-mail] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/