Subject: [ipfix] Slides from IETF presentation.

From: Mark Fullmer <[email-masked]>
Date: Tue, 18 Nov 2003 21:12:53 -0500

Stuart, could you please post your slides detailing the options for
extending the field ID space to include vendor extensions.

If my memory is correct you proposed an optional 32 bit vendor
ID which would either always be in the template or optionally
in the template based on a "magic" field type which indicates
a vendor extension.

After thinking about this for a few days I'd prefer the always
there version of your proposal.  I don't see any reason to save
a few bytes in the template at the expense of extra work in the
decode/encode process.  Also have you considered just using
a 32 bit vs. 16 bit field type with say the first 16 bits reserved
as a vendor ID?

mark

--
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: Ganesh Sadasivan <[email-masked]>
Date: Tue, 18 Nov 2003 19:25:53 -0800

> in the template based on a "magic" field type which indicates

Yes based on fixed ranges assigned to IETF defined and Vendor
defined  field types (some thing like {0-32767} for IETF defined
and {32768-65535} for vendor specified field types).

> decode/encode process. 

When there is a mixture of IETF defined and  Vendor specified fields
and we are using large number of fields in the templates, this would be
useful. But otherwise there are'nt any major advantages.
I don't know how much extra work is involved in encoding/decoding.
Could be as simple as :
if (field_type < IETF_DEFINED_MAX) { ..} else {..}

Or do you see something more worse?

I am ok either way.

> Also have you considered just using

We just wanted to give a 48 bit id for the field type.

Thanks
Ganesh

---

From: Mark Fullmer <[email-masked]>
Date: Tue, 18 Nov 2003 22:59:29 -0500

I'm okay with it either way, I'd just prefer one way to do the encodings
with 32 bit ID's.  I really doubt we'll see more than a couple of
vendor ID's other than IETF over the life of the protocol.

mark

---

From: Ganesh Sadasivan <[email-masked]>
Date: Wed, 19 Nov 2003 08:41:35 -0800

> vendor ID's other than IETF over the life of the protocol.

Speaking as a vendor,  I  can image the applicability of this protocol
to a wider range of vendor specific applications :)

-Ganesh

---

From: Mark Fullmer <[email-masked]>
Date: Wed, 19 Nov 2003 12:50:48 -0500

Each vendor ID (65535 of them) would get 65535 fields minus one for the
special variable length encoding scheme assigned to them.

We have maybe 10 or 20 vendors in this space and a small handful
of IETF assigned fields.  Ideally most of the fields would be defined
in the IETF vendor ID space.

I'm just missing why we would need a 48 bit name space...

mark

---

From: Ganesh Sadasivan <[email-masked]>
Date: Wed, 19 Nov 2003 12:12:43 -0800

> I'm just missing why we would need a 48 bit name space...

Just that it is more future proof. Maybe we can reduce to Vendor ID 16 
bits.
One thing to keep in mind is that having PSAMP using IPFIX export  is going
to add some more vendors too. But still 64k may be good enough.

-Ganesh

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 20 Nov 2003 14:05:37 +0000

I have put the slides at:

ftp://ftpeng.cisco.com/stbryant/IETF-58-IPFIX-VSIE.pdf

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 20 Nov 2003 14:42:11 +0000

> in the IETF vendor ID space.

Where is the vendor ID specified as 16 bit?

I just looked at http://www.iana.org/assignments/enterprise-numbers
and noted that they were just a list of numbers. I noted that
the last number is 18775, and hence that we are already a third
of the way through the space. Using a 32 bit value therefore
seemed prudent.

> I'm just missing why we would need a 48 bit name space...

It saves re-inventing the registry and means that we will never
run out.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 20 Nov 2003 15:11:34 +0000

> to add some more vendors too. But still 64k may be good enough.

We have already used a third of the 64K space (assuming that we
use enterprise numbers rather than start our own registry).

Stewart

---

From: Mark Fullmer <[email-masked]>
Date: Thu, 20 Nov 2003 10:44:36 -0500

Okay.  I wasn't aware of this registry.  32 bit vendor ID's make sense
then.

mark