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

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 24 Oct 2002 19:28:21 -0700

Hello Michael,

comments inline...

> -----Original Message-----
> From: Michael MacFaden [mailto:[email-masked]]
> Sent: Thursday, October 24, 2002 6:52 PM
> To: [email-masked]
> Subject: Re: [ipfix-req] list of issues - Reinaldo - 7 (or Carter -1)
> 
> 
> On Thu, Oct 24, 2002 at 07:04:53PM -0400, Carter Bullard wrote:
> >> 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.
> 
> 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.

We will have a standard set of type fields. All exporters and collectors
will have to comply with the minimum set described in the data model. That's
your interoperability. Blobs would be useful for certain
situations/deployment/scenarios.

When we go to a backoff we do not test all possible extensions of a
protocol, a recent example that I can give is SIP. We test the core
functionality. If you are interested in interoperating for instant messaging
or QoS then you test with some other specific vendors.

So I think it's the other way around than what you say. Interoperability and
extensibility should go together. Because if the protocol is not extensible,
THEN people will hack away the base specification to suit their customer
needs or some scenario and THEN we will have a non-interoperable protocol.

> 
> >I thought it was a MUST requirement to have vendor specific
> >blobs in IPFIX?
> 
> 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.

That's the problem I foresee. Imagine how many data types we will have in
the future. All the combinations possible with all the protocols that run
over IP. Maybe what a vendor or its customer wants for a certain scenario is
a blob that contains, for instance, the DSCP field + ECN + TCP window size.
For other deployment I might need the URL + the Cache header, etc, etc.
Extrapolate that to all possible combinations and you will see the profusion
of new fields IANA will have to standardize, the size of the parser, etc 

> 
> >> Take the Apple Airport (karlbridge) wireless bridge for example. 
> >
> >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.
> 
> 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
> 
> --
> 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 19:58:15 -0700

>of new fields IANA will have to standardize, the size of the parser, etc 

I do think we all agree the protocol must be extensible as per the
requirements, but just not on the the scope yet. Some of us take
a narrow view of what the protocol should report (IPv4, IPv6 headers)
others prefer a wider view (everything else).

These divergent views will have to be considered carefully in evaluating 
how extensible the protocol should actually be. Section 6.2 of the
requirements doc could then be updated to reflect the consensus. 

I will say it one last time and shut up. 

BLOBs hinder interoperability, BLOBs are bad.

There. Peace Out.
Mike MacFaden

--
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: Juergen Quittek <[email-masked]>
Date: Fri, 25 Oct 2002 17:35:59 +0200

Let's all have a look at our charter:

1. It starts with: "There are a number of IP flow information
   export systems in common use."

2. Later it says: "This group will select a protocol ...".

3. There is no mentioning of "This group will merge all
   protocols ...".
   Also there is no mentioning of "This group will design a
   protocol."

Consequently, we should go on with what we have started already:
selecting ONE of the candidate protocol.

If the BLOB discussion ends up with saying "Just selecting one
is a bad idea, we won't do it.", then we should stop our work and
ask for re-chartering.

However, I think, charter discussion was extensive and we made
good progress based on the current charter. I definitely want
to continue this.

    Juergen

---

From: [email-masked]
Date: Fri, 25 Oct 2002 11:43:15 -0400

> good progress based on the current charter. I definitely want

	I for one never expected to take the candidate
	protocol on an "as is" basis.

	If we decide blobs are bad then the candidate
	protocol needs to be modified accordingly.

	That applies to any other topic discussed as well.

	Paul

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 25 Oct 2002 19:00:16 +0200

Paul,

> 	That applies to any other topic discussed as well.

I do not have problems with giving recommendations to protocol
designers to change their protocol. But as I understood the blob
discussion, the idea was not to select one or the other protocol,
but to select several and carry them all in an opaque blob.
This is defintely more than modifying one of the protocols.

    Juergen

---

From: [email-masked]
Date: Fri, 25 Oct 2002 13:07:04 -0400

> This is defintely more than modifying one of the protocols.
	Sorry, my misunderstanding of your position. 
	We are in violent agreement!

	Paul

	P.S. - in the future saying something like "blobs bad" 	
	 	is more at my level :-)

---

From: Benoit Claise <[email-masked]>
Date: Mon, 28 Oct 2002 17:03:07 +0100

Just to refer to the charter one more time... IP _Flow Information_ Export
If we don't know what we export because this is not defined (read opaque 
BLOB)... then I think this WG failed to do its job.

Regards, Benoit.