Subject: RE: [ipfix-req] list of issues - Reinaldo - 7 (or Carter -1)

From: "Carter Bullard" <[email-masked]>
Date: Thu, 24 Oct 2002 19:04:53 -0400

> Michael MacFaden sez (Thursday, October 24, 2002 6:17 PM)
> 
> As I have stated before, I would hope that IPFIX
> does not become generic data mover protocol. 
> If our data model can not represent what is to be sent, 
> then that data should be transferred over some other generic protocol 
> such as http, ftp or scp.

That of course doesn't help support vendor differentiation.
There are flow probes available that report flow jitter in
every record. LFAP doesn't have a data element for jitter,
so if there wasn't support for a blob, there would be no way to
transport this important metric.  I'm sure that you're
not serious in suggesting that we use HTTP to fetch the
jitter metric for each IPFIX flow record that is received.

I thought it was a MUST requirement to have vendor specific
blobs in IPFIX?

> 
> My reasoning for this is from previous experience with SNMP 
> deployments. In SNMP there is the OCTET STRING datatype. It 
> often gets abused to provide a way to move blobs since you 
> don't need to train an engineer on the protocol, 
> it's data model and how to version the thing. 
> 
> Take the Apple Airport (karlbridge) wireless bridge for example. 
> It uses SNMP and OCTET STRING blobs for configuration.
> Users have to spend too time reverse engineering how use the 
> thing with standard tools http://www.icir.org/fenner/airport/ 
> thanks to blobs.

But at least they are using SNMP, instead of say, Appletalk.
That says more for SNMP's utility than you want to give it
credit for.  I'm sure apple's configuration application doesn't
have any problems configuring the box.

Carter

--
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: Michael MacFaden <[email-masked]>
Date: Thu, 24 Oct 2002 18:51:47 -0700

>That of course doesn't help support vendor differentiation.

I believe the goal is to standardize what is common 
practice *today* and that the result is *interoperable*.
I think generic BLOBS simply impede interoperable collectors
from doing anything even remotely useful with the delivered data.

>I thought it was a MUST requirement to have vendor specific

I read the requirement the one could add specific type/values
from predefined datatypes or possibly extended datatypes.

So if one were to ship a something like a raw ipv4 header or 
some packet slice, it must have a specific datatype 
associated with it that defines what it is clearly.

>have any problems configuring the box.

The "utility" you speak of simply breaks interoperability. 
The same amount of reverse engineering would have had to be 
done using AppleTalk, IPX or any other dumb transport
and will have to be redone when the vendor changes the firmware. 

Mike MacFaden