Subject: RE: [ipfix-eval] Juergen's conclusions

From: "Carter Bullard" <[email-masked]>
Date: Tue, 22 Oct 2002 11:16:36 -0400

Hey Juergen,
> Juergen's Conclusion
[snip]
> 
> Considering all this I would recommend to go for NetFlow v9. 
> If this is not accepted because NetFlow is considered as too 
> simple or lacking functionality, I would recommend using IDPR.
>

While I like the IPDR data representation strategy and formats,
I see IPDR as a data model, providing a format for communicating
flow activity reports that a probe can generate.  But I don't
see how IPDR is a transport protocol.

My opinion is that IPFIX MUST be able to transport IPDR data,
it MUST also be able to transport native NetFlow v[1-9] data
as well.  That to me indicates that the appropriate data model
is either a superset of all the candidates, so that IPFIX can
handle all the data types, or the transport protocol supports
an opaque data object, so that vendors can transport their
native records as blobs.  NetFlow doesn't support either
strategy.  IPDR may be able to be the superset, but its doesn't
support an opaque blob.

While vendors will assure us that their methods can be extended,
I won't feel comfortable making a choice until the vendors 
demonstrate how their methods can handle the requirements.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

[email-masked]
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

>     Juergen
> 
> --
> 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/
> 

--
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: "Tal Givoly" <[email-masked]>
Date: Tue, 22 Oct 2002 15:11:58 -0700

Carter & Juergen,

CRANE clearly addresses your issue. Not only are there types for BLOBs - in
case you want opaque data transport, but there is also the ability to extend
while still maintaining negotiable data structures. Objects are packed
according to client capabilities/desires. Client can always override complex
requirements of servers (server hints to the client whether he is interested
in specific attributes and client can use this hint or ignore it - to
achieve best efficiency).

In general, CRANE always prefer client simplicity/efficiency and
deployment/development efficiency over merely protocol simplicity. Protocol
simplicity doesn't usually lead to reliable, extensible, cost-effective
deployments and developments of integration but rather the opposite.

Integration simplicity (and therefore, to some degree, usability) is a
matter of resource consumption on device (cpu, memory, etc.) and good APIs
to allow to handle all use cases while overcoming real-world issues (such as
overload behavior, etc.) (also modeled as use cases).

NetFlow is obviously too simple as it doesn't allow for reliability at a
reasonable cost. It requires rather significant extensions to become such.

I defer to Jeff regarding IPDR's support for opaque BLOB, but as far as I
can tell, as it is based on XDR, it can, be extended to support both fixed
and variable length opaque BLOBs, if it doesn't already have this. However,
IPDR doesn't seem to expose all XDR's capabilities (e.g. arrays are not
exposed via IPDR), and therefore, perhaps this is but one of the things IPDR
doesn't allow.

Tal

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Carter Bullard
Sent: Tuesday, October 22, 2002 8:17 AM
To: 'Juergen Quittek'; [email-masked]
Subject: RE: [ipfix-eval] Juergen's conclusions

Hey Juergen,
[snip]

Carter

Carter Bullard
QoSient, LLC

[email-masked]
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

--
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: Jeff Meyer <[email-masked]>
Date: Tue, 22 Oct 2002 19:08:34 -0700

Hi,

   IPDR defines a data modelling capability.

   IPDR also defines a couple of serialization models.
(XML and compact).

   You can serialize to a file or you can serialize
over a network connection (for network connection,
only compact is supported).

   The former supports batch mode and the latter
supports more real time requirements (i.e. IP Flows).

   How IPDR streams over the network is described
in the specification at:

   http://www.ietf.org/internet-drafts/draft-meyer-ipdr-streaming-00.txt

   Note that the streaming model is NOT described as part
of IPDR's 3.1 specification.  But uses a minor extension
to the already defined compact format to enable both
trivial delivery and reliable delivery.

   The streaming model should be incorporated into
the next revision of IPDR.

   Transporting information equivalent to Netflow v1-9
is simply a matter of defining the appropriate
IPDR Service Definition.  The example service
definition in the appendix of the advocacy draft
should illustrate how other NFvX versions would
be modeled.

   The compact format definition of IPDR does support
a binary data type, but it is not exposed through
the data model at this point.  Since the protocol
already supports this, extending the datamodel to
allow for either the XML type "base64Binary" or
"hexBinary".  This use case had not come up with
the existing service definitions, but seems minor
to address.

Regards,

   Jeff Meyer

---

From: Jeff Meyer <[email-masked]>
Date: Tue, 22 Oct 2002 19:14:48 -0700

Hi,

   Regarding Tal's question about arrays and other
XDR capabilities...

   Some of this discussion occurred on earlier threads,
but I'll repeat:

   IPDR today defines records which are (in
database parlance) First Normal Form.  Meaning
that all the fields are of a primitive type
and none of the fields repeat.

   From a processing and storage perspective
FNF is quite desireable and should be encouraged.
NF data is FNF, as are the other Service definitions
created by IPDR to date.

   There is a proposed extension (backward compatable)
to IPDR to enable both substructures and repeating
fields (arrays) submitted w/in IPDR.  However it
is not required for IPFIX and (to repeat) should
be discouraged when FNF is sufficient.

Regards,

   Jeff Meyer

---

From: Benoit Claise <[email-masked]>
Date: Mon, 28 Oct 2002 14:55:48 +0100

Hi Carter,

>is either a superset of all the candidates, 
>
I thought this was the goal.

>so that IPFIX can
>strategy.  
If you speak about NetFlow in particular, this would not be a big deal 
to some data types in the data model. As many as you want to, I would say.

Regards, Benoit

>IPDR may be able to be the superset, but its doesn't
>support an opaque blob.
>