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

["Kevin Zhang" <[e-mail]>]

Hi Benoit, 

Please see my comments, Thanks,

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.

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


> > 
> > 
> > > >
> > > >
> > > > 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/
> > > 
> > > 
> > 
> 
> ÿñޖ™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&ޙ¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ފ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ