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:42:37 -0500

Hello Benoit,

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 your good points and issues. We are not thinking 
here exporter or collector configuraation 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 
with each and every  protocol. Flow information can be exchanged between
two endpoints if they know how to interpret the fields. 

Like SNMP every protocol defines the MIB what to be managed.

Typically, Management protocols are  provides mechanisms they do not describes each attributes
 of protocol, IT is the responsibility of each protocol define their attributes which are to be
managed and this more specific 
to details of the protocol.

So in principle we have MIB and management protocol two are logically separate entities.

Ok,its  a matter of  time and design team effort to put that. I do not think
it is waste of money or time.

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

I advice be patient and cool while you converse what i ask in the 
email and the statements in your email is not the correct way to 
communicate. What you replied is not the correct way to communicate, please
read the emails before you communicate.

>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: "Peter Ludemann" <[email-masked]>
Date: Thu, 14 Feb 2002 12:28:42 -0800

RE: in band configuration? RE: [ipfix-req] Proposed changes to
draft-ietf-ipfix-reqs-00.txtWhether or not we have in-band configuration, we
do need a mechanism for advertising the data that a device can deliver
(i.e., self-defining data). In terms of design and implementation,
supporting a simple negotiation ("Don't send me x." "OK, here's a revised
list of what I'm sending") isn't much more work.

If you configure a device with a MIB or CLI, how do you tell the receivers
about what data is being sent? How do you coordinate amongst thousands of
sending devices and dozens of receivers ... doing this by hand would be a
nightmare. (I'm not making up this scenario; but I can't give more details
because of confidentiality issues.)

There is a very pragmatic reason for having the receiver specify the fields
it doesn't want. Some fields are expensive (for example, we have a probe
which can look inside data streams and extract information such as URLs and
response codes; it can also compute performance metrics such as response
times ... when all of these are turned on, the performance can drop
significantly).

Having in-band configuration does not mean that a device needs to support
anything beyond advertising the data that it will send. For example, with
Kevin's CRANE proposal, the in-band configuration consists of:
- the device ("meter") advertises the records it can send
- the receiver requests restrictions on what is sent (which kinds of
records, which fields in those records)
- the device can ignore the restriction request

So, this configuration simply offers the possibility of optimization but
does not force the optimization.

This kind of configuration does not specify frequency of data delivery,
aggregation, filtering, etc. Currently, we do this out of band (with a CLI,
MIB, or registry file) because it does not raise the coordination issues
that data formats cause. We're thinking of a generic mechanism for doing
configuration inside the transfer protocol, but that's a future issue that
can easily be added to the existing protocol.

- peter
  -----Original Message-----
  From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Reinaldo Penno
  Sent: Thursday, February 14, 2002 7:24 AM
  To: [email-masked]; Benoit Claise
  Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
  Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to
draft-ietf-ipfix-reqs-00.txt

  Hello,

  Last I counted we had most people saying that it's useful but we should
tackle this later, except for Me, Kevin and Ram that would like to see it
now. K.C said it was nice, Paul and Mike that it was for after "IPfixv1" and
Benoit, Ganesh, Juergen and Will saying no.

  So in terms of number of vendors (I agree with Benoit that the important
thing is the number of vendors adopting it) it seems there is an agreement
to investigate this problem at some point. We need then to choose the words
that reflect this position on the arch draft/req. Suggestions?

  Having said that I would like to clarify some points:

  One is that the idea was never to have a "common provisioning protocol".
Provisioning seems a pretty heavy word. The in-band config would facilite
things like template negotiation associate with flow metering capabilities
and the like. So, in fact it would help configuring vendor specific features
like extended flow information, etc

  Second, the fact that "the meter will be built partially in hardware which
is costly. Here we can
  save a lot by reducing some functions. " is a implementation
issue...Somebody else cold say that their meter would be build on software
(a PC-appliance for instance) so they do not care. So trying to be fair with
all possible IPfix users, I think we should drop this specific point
altogether.

  Now, as I said, I think Benoit had a good point on the adoption of such a
mechanism, ie, How many vendors would implement this in-band configuration.
If we can base the vendors on the people that work for them, I would say up
to this point 4-5 (not sure what percentage of companies that will really
build an IPfix collector or exporter this represents).

  regards,

  Reinaldo

  >-----Original Message-----
  >From: [email-masked] [mailto:[email-masked]]
  >Sent: Thursday, February 14, 2002 6:24 AM
  >To: Benoit Claise
  >Cc: [email-masked]; [email-masked]; [email-masked];
  >[email-masked]
  >Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to
  >draft-ietf-ipfix-reqs-00.txt
  >
  >
  >
  >I vote no in-band configuration in IPFIX V1.
  >
  >Benoit Claise wrote:
  >>
  >> Hi Ram and All,
  >>
  >> We've discussing the in-band configuration for a few times
  >without conclusions.
  >> I propose to use this thread to arrive to a rough consensus
  >and close the discussion one for all. Otherwise we're turning
  >in circles and loosing everybody's time!
  >> And if we can't get a consensus, the chairmen and area
  >directors will have to take a decision.
  >>
  >> > >Our charter tells us to "select a protocol by which
  >> > >IP flow information can be transferred" and I would
  >> > >prefer not to go beyond this.
  >> >
  >> > Transfer  of flow information may not refer only to
  >monitoring. I interpreted as
  >> > one  can monitor and then transfer ( exchange) flows
  >between endpoints . To do this one has
  >> > to  configure first what we are interested in - that means
  >configure, monitor and transfer
  >> > flows.
  >> >
  >> > I am not sure and would like to get clarify my doubt,
  >> >
  >> > 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
  >> 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.
  >>
  >> 3. How many vendors would implement this in-band configuration?
  >> Because at the end this is the final question. What's the
  >point to have a IETF protocol that no/not many vendors are
  >going to implement.
  >> Do you think that vendors will spend time and money to
  >developp again another configuration interface, next to CLI,
  >SNMP, XML, etc...?  And this just for an IPFIX protocol!
  >>
  >> And if there is a need for in-band configuration, then we
  >can think of IPFIX2.
  >> 5. From the charter, "select a protocol by which IP flow
  >information can be transferred" as Juergen said already. I
  >would not beyond this point.
  >> OK, you (Ramg) have a different view.
  >>
  >> 7. Email from Nevil Brownlee, Subject: [ipfix] Comments on
  >'goals of IPFX WG'
  >> http://ipfx.doit.wisc.edu/list/ipfix/archive/0388.html
  >>       2. IPFIX is *not* trying to standardise a flow meter,
  >i.e. a network
  >>       entity which measures flows - we already have RFCs
  >which do that,
  >>       e.g. those for RTFM (2720 .. 2724).  Existing widely-used
  >>       implementations can remain different, but might
  >perhaps be extended
  >>       to report flow information in the IPFIX lingua franca.
  >>
  >>       3. Instead, we recognise that network equipment
  >vendors already have
  >>       flow measurement systems implemented as part of their
  >equipment.
  >>       Our goal is to make the IPFIX flow information export system
  >>       so good technically that all vendors will be happy to implement
  >>       it, for the benefit of all users of the data.  A
  >useful side-effect
  >>       will be that IPFIX will make it easier to build and maintain
  >>       interoperable flow data collecting systems.
  >>
  >> As we're not supposed to standardise a flow meter, why would
  >we standardize its configuration? This email just expresses
  >that the exporter configuration is out of the scope of the charter.
  >>
  >> 8. Juergen's argument: "Please consider that the meter will
  >be built partially in hardware which is costly. Here we can
  >save a lot by reducing some functions.
  >> The data collector implemented by software can be much more flexible
  >> with less cost."
  >>
  >> Regards, Benoit.
  >>
  >> >
  >> > I can understand  currently most of network elements
  >configuration happens thro'   CLI or other mechanisms....
  >> >
  >> > Take for example SNMP is used only as monitoring tool and
  >but people are working on to making configuration
  >> > also thro' SNMP and seperate activity is going on in IETF
  >community itself.
  >> >
  >> >
  >> > Regards
  >> > Ramg
  >> >
  >> >
  >> >
  >> >
  >>
  >> --

---

From: Benoit Claise <[email-masked]>
Date: Mon, 25 Feb 2002 11:15:26 +0100 (CET)

Hi Peter,

> 
> > I don't call this above "content negotiation" but pure configuration.
> > You tell the exporter which fields to export by defining a template.
> 
> So, shall we have an argument about terminology? That's avoiding the point.
> 
> It's more important that we discuss the actual requirements. So far, I've
> seen arguments in favour of both content negotiation and in-band
> configuration but the only arguments I've seen against these seem to be "I
> don't like it" or "it's not in the charter". If I missed more substantive
> arguments, please send me a reference ... it would be nice to have something
> a bit more persuasive.
> 
> Benoit's statement begs the question: how is the template defined? If it's
> done out-of-band, that requires a separate element management system (unless
> you like entering CLI commands or SNMP values by hand). It makes a
> tightly-coupled sender-receiver difficult to handle (I'll give an example
> later).

As a reminder from Nevil
http://ipfix.doit.wisc.edu/list/ipfix/archive/0736.html

++ Configuration: protocol
   - Randy, 20 Feb: reminder, out of scope 
   [I skipped the other people's comments]

As the configuration is out of scope, data negotation (as you call it in the rest of your email below) or configuration negotation (as I call it) must follow the same path -> out of scope.

Regards, Benoit.

> 
> Both content negotiation and in-band configuration should be required but in
> the trivial sense that the device must respond to the request for content
> change or configuration but the response can be "I refuse to change the
> content" or "your configuration request is rejected". This is easy to
> implement; and it allows other devices to do the content negotiation or
> in-band configuration that they want. [Similarly, I would like a MIB to be
> required, at minimum to get configuration, performance, and other "out of
> band" data; and it could also (optionally) be used to set configuration
> values.]
> 
> If we don't put these features into the standard, some people will add them
> anyway and we won't have a standard any more.
> 
> Sometimes configuration at the device (or via an element management system)
> is the best way to do things. But sometimes the receiver must be involved;
> or the sender and receiver need to be configured together. In-band content
> negotiation and configuration simplify this.
> 
> Here is one scenario. Consider collecting layer 3/4 data (e.g., collecting
> details of individual FTP or HTTP connections) exporting the sessions in
> "slices" (e.g., giving the progress every 30 minutes). From this, a nice
> histogram of protocol usage by time of day can be generated.
> 
> But now we want more details around the busy times (e.g., 5 minutes slices)
> but less details at other times [to save space in the database]. This can
> easily be done via in-band configuration -- after all, the collector is
> connected directly to the data receiving and processing system; but would be
> much more complex using an element management system, which isn't designed
> for changing things so dynamically. Going further  with this example, we
> want do dynamically drill-down to find busy URLs and FTP sites but not to do
> this all the time because of performance issues and because of data space
> considerations. This could be done without in-band configuration, but it
> would be much nastier. (This example is taken from experience with a data
> collection system that was inserting over 100 million records a day into a
> database ... clearly, being able to limit the amount of data is very
> important and can have significant impact on the cost of the deployment.)
> 
> In this scenario, we sometimes want to do in-band configuration and
> sometimes want to do other configuration (so, there is something to Benoit's
> remark). As I've mentioned elsewhere, I think that data negotiation is the
> more important of the two, because of the need to coordinate template
> information amongst multiple (failover) receivers; but in-band configuration
> is also useful and allows a simpler deployment.
> 
> (Again, based on our experience, ease-of-deployment is a very important
> consideration, unless you enjoy long meetings in large airless rooms with
> representatives from a dozen different departments.)
> 
> In general, I believe that "perfection is reached, not when there is no
> longer anything to add, but when there is no longer anything to take away"
> (Antoine de Saint-Exupery). But in-band content negotiation and
> configuration are not very complex (we've implemented them, anyway), are
> sufficiently useful to be included, and would lead to "standard extension"
> if we don't include them.
> 
> - peter
> 
> ----
> Peter Ludemann           [email-masked]
> Chief Architect          +1.408.330.5732
> XACCT Technologies, Inc.
> 2900 Lakeside Drive      Santa Clara, CA 95054
>

---

From: "Reinaldo Penno"<[email-masked]>
Date: Mon, 25 Feb 2002 13:53:00 -0800

Hello Ganesh/Peter,

comments inline..

>From: Ganesh Sadasivan [mailto:[email-masked]]
>Sent: Monday, February 25, 2002 10:13 AM
>To: Peter Ludemann
>Cc: Benoit Claise; [email-masked]; Gilby, Christian
>[SC9:0000:EXCH]
>Peter Ludemann wrote:
>> Benoit Claise [mailto:[email-masked]] wrote Tuesday, 
>February 19, 2002
>> 2:46 AM:
>>
>       to be re-engineered to suit IPFIX protocol?
>   3. If there are 'n' exporters trying to export to a 
>collector, choosing the
>least common
>      fields among all the exporters to define a common 
>template of export from

This would be one option. The other option would be the exporter use a
different template for each collector, in order to make the most of their
implementation.

>the
>      collector is not an easy task. Say the collector decides 
>on a template,
>common to all
>      exporters and now a new exporter joins which cannot 
>support this set what
>is the
>      collector's policy now? The choice of policies  varies 
>greatly with
>applications
>      that finally use this data. This has to be coupled with 
>the understanding
>of how
>      metering is done at the exporter.
> 4. In the routers, whose main job is to route the packets 
>with performance and
>     forwarding features as the top priority,  making 
>decisions as to which stack
>
>     to setup (TCP/SCTP) for export, what security protocol 
>should be used,
>     dynamically decide what  templates/fields to 
>accept/reject, dynamically
>modify
>     the export timers, export rate, start peeking deeper into 
>a packet which may
>
>     affect the performance, though ideally achievable is too 
>much an overhead.
>     I tend to beleive that each service provider would be 
>interested in defining
>
>     these decisions for the routers in their own way and 
>generalising any such
>     behavior may not add much value, other than adding more 
>complexity. It is
>    fairly trivial still to use expect scripts and cron jobs 
>to achieve the
>same;)

This argument is okay for traditional routers (for a lack of a better word).
The possible users for the IPfix protocol are PC-probes, more intelligent
edge routers, routers that offer middlebox services, IPservices switches,
etc

Deciding on a protocol that has the least functions just to accomodate a
single type of equipment is not the way to go. As we said before, we can
this part of the protocol optional. 

We are impacting the possible users of IPfix by asking them to downgrade how
feature rich their equipment can be. We are also asking for people to make
their own extensions and go away from the standard. I think the IETF should
think a little bit outside of the box here.

regards,

Reinaldo

>Thanks
>Ganesh