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

From: "Reinaldo Penno"<[email-masked]>
Date: Fri, 15 Feb 2002 11:45:39 -0800

Hello,

I'm not sure who said that part about middleboxes, but it's a good point.
There are devices out there related to middleboxes, probes, OPES, CDI with
great flexibility and indirectly we are making a rigid architecture in
regards to inband/CN thinking about the least functionality. That's why in
order to make it fair for everybody I proposed to put in-band and/or CN as a
SHOULD in the architecture document. I think this is further justified by
the fact that we have several vendors already interested on this
functionality.

Since it's a SHOULD vendors not interested can just ignore it. We make it as
Peter/Kevin proposed in a way that vendors that do not implement it can
silent igonre that message. 

I'm not sure if the "not now" argument is okay, because I'm not sure there
will be a later. We can finish with the charter deliverables and WG might be
closed. 

So, once more I propose that we put this as a SHOULD, people interested work
on it and we make sure that vendors that do not want to support it can just
ignore the configuration/advertisement. 

thanks,

Reinaldo

>-----Original Message-----
>From: Robert Lowe [mailto:[email-masked]]
>Sent: Friday, February 15, 2002 8:30 AM
>To: Benoit Claise
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes
>todraft-ietf-ipfix-reqs-00.txt
>
>
>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.
>> 
>> 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.
>
>> > 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!
>
>--
>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/
>