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

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

Hi Kevin,

> 
> My comments are inserted, thanks.
> 
> Kevin
> 
> > -----Original Message-----
> > From: majordomo listserver [mailto:[email-masked]]On Behalf
> > Of Benoit Claise
> > Sent: Thursday, February 14, 2002 10:09 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked]
> > 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.
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.
> 
> 
> > >
> > >
> > > 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!

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:[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: "Kevin Zhang" <[email-masked]>
Date: Thu, 14 Feb 2002 12:52:08 -0500

Hi Benoit, 

Please see my comments, Thanks,

Kevin

> From: Benoit Claise [mailto:[email-masked]]
> Sent: Thursday, February 14, 2002 12:39 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to
> > > From: majordomo listserver 
> [mailto:[email-masked]]On Behalf
> > > Of Benoit Claise
> > 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.

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

---

From: Robert Lowe <[email-masked]>
Date: Fri, 15 Feb 2002 10:30:06 -0600

Benoit Claise wrote:

The lurker opinion poll (no vote)... ;-)

In-band configuration -- not now.
Negotiation -- limited (but that discussion is promised to follow).

Benoit, I think this was a very perceptive comment.  It seems we are
at times confusing the two.

-Robert

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

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 18 Feb 2002 11:36:00 +0100

Hi Kevin,

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

> 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