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

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

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. 


> >
> >
> > 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. 
  
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ýªÜ†+Þ