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

From: <[email-masked]>
Date: Thu, 14 Feb 2002 09:55:54 -0500

Hello Benoit,

I am sorry once again, my system has some problem , emails slipped out my hands before completing it.
I just fixed this now.

Thanks for pointing me the charters quote. See my inline comments.
 
>
>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.

I was discussing only configuration and not other aspects , see inline comments.

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

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. 

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.
 
So in principle we have MIB and management protocol two are logically separate functional entities.

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.

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/

---

From: Benoit Claise <[email-masked]>
Date: Thu, 14 Feb 2002 16:09:18 +0100

Ramg,

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

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

> The latter thing is more addressed by MIB which is a generic to represent attributes which are to

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

> We are not talking version of IPFIX in our charter and it may be

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

---

From: "Kevin Zhang" <[email-masked]>
Date: Thu, 14 Feb 2002 11:42:54 -0500

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

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. 

> BTW, In Ganesh and I's draft, the collector will be able to 
> decode a template, even if it doesn't know

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.

> ��ޖ���[h�f���h���z�ݢ+��+��njwlk/�zZ��y��Ơy��I칻�&ޙ�����j:+v���w���"��"���v�vƲ��칻�&ފ�������,j��܀��b��m����*_�ݢ+��+��n��܆+�