Subject: [IPFIX] Question about data types of some IEs

From: Hitoshi Irino <[email-masked]>
Date: Mon, 16 Oct 2006 09:36:33 +0900

Dear all,

I have a question and suggestion about data types of some IEs.

1.
  5.5.12.  tcpHeaderLength
  Abstract Data Type: unsigned16

TCP headers has 4 bit "Data Offset" field which has the number of 32 bit
words in the TCP header. Therefore, I think TCP header max size is 2^4*4
= 64 octets. Therefore I think that unsigned8 is sufficient for this IE.
Is there any reason that is unsigned16?

2.
  5.6.9.  mplsTopLabelTTL
  Abstract Data Type: unsigned32

According to 2.1. Encoding the Label Stack in RFC3032
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
|                Label                  | Exp |S|       TTL     | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

                     Label:  Label Value, 20 bits
                     Exp:    Experimental Use, 3 bits
                     S:      Bottom of Stack, 1 bit
                     TTL:    Time to Live, 8 bits

I think that unsigned8 is sufficient for this IE.
Is there any reason that is unsigned32?

3.
  5.4.30.  ipPayloadLength
  Abstract Data Type: unsigned64

totalLengthIPv4 is 16bit, payloadLengthIPv6 is 32bit for jumbo payload
(rfc2675). I think unsigned32 is sufficient for ipPayloadLength.
Why Does Abstract Data Type of this IE have unsigned64?

4.
   5.7.12.  mplsVpnRouteDistinguisher
   Abstract Data Type: octetArray

According to section 4.2 in rfc4364,
a VPN-IPv4 address consists of an 8-byte Route Distinguisher followed by 
a 4-byte IPv4 address.

Is unsigned64 sufficient for this IE?

According to page 7 of rfc4382,
MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION
SYNTAX  OCTET STRING(SIZE (0..256))

I think that Abstract Data Type of this IE should be "string", if this 
IE is in conformity to rfc4382.

5.
Can Exporter implementation be chosen which use fixed or variable length 
for IEs that have octetArray or string data type?  Is it correct?
Should Information model draft define which use fixed or variable for 
these IEs?

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories

_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Juergen Quittek <[email-masked]>
Date: Sat, 21 Oct 2006 15:21:05 +0200

Dear Irino-san,

Thanks for carefully checking the data types used in the
info model.  Please find replies to your comments inline.
For three IEs I followed your suggestion and replaced the
data type for the next version of the draft.

> = 64 octets. Therefore I think that unsigned8 is sufficient for this IE.

I agree.  Would anyone have problems with changing the type to unsigned 8?

> According to 2.1. Encoding the Label Stack in RFC3032

Also agreed. Any objections?

> Why Does Abstract Data Type of this IE have unsigned64?

Also agreed.  Would anyone complain if we changed it to unsigned32?

> a VPN-IPv4 address consists of an 8-byte Route Distinguisher
> followed by a 4-byte IPv4 address.
>
> I think that Abstract Data Type of this IE should be "string",
> if this IE is in conformity to rfc4382.

RFC 4364 defines the size of a route distinguisher as 64 bits
(8 octets) which exactly matches the current data type in the
info model.

However, you are right that the MIB module in RFC 4382 chooses
the SMI type for a route distinguisher to be an octet string
with up to 256 octets.  I do not understand why the in the MIB
module in RFC 4382 does not use a shorter array.

I sent this question to the editors of RFC 4382.
Let's hope they can help us.  Or can somebody on the list
answer this question?

> 5.
> Can Exporter implementation be chosen which use fixed or variable
> length for IEs that have octetArray or string data type?
> Is it correct?  Should Information model draft define which use
> fixed or variable for these IEs?

I think exporters should be free to choose between fixed or
variable length encoding of a particular IE.  I do not see a
good reason to restrict the use.  But I am open to discuss it
if you bring up a good reason.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 4342-115
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 4342-155
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

---

From: Juergen Quittek <[email-masked]>
Date: Sat, 21 Oct 2006 15:21:05 +0200

Dear Irino-san,

Thanks,

    Juergen

---

From: Hitoshi Irino <[email-masked]>
Date: Mon, 30 Oct 2006 17:49:00 +0900

Dear Juregen,

> data type for the next version of the draft.

Thank you.
I confirmed these changes in IPFIX-INFO-14

> (8 octets) which exactly matches the current data type in the

I am confused by this sentence. Current abstract data type is defined as
octetArray in IPFIX-INFO-14, RD is a 64 bit value, so I supposed it is
better to change unsigned64. Otherwise, I supposed to use 8 octets
octetArray, a description of this IE should specify that a size of this
IE is 8 octets.

> module in RFC 4382 does not use a shorter array.

I have same question.
When RD is described by string, I guess that the maximum string length 
of RD is 23 characters.
-----
0:2ByteASN:4Byte -> 0:65536:4294967296 -> 18 characters
maximum value of 2ByteASN is 65536,
maximum value of 4Byte is 4294967296
1:4ByteIPv4Address:2Byte-> 1:255.255.255.255:65536 -> 23 characters
maximum value of 4ByteIPv4Address is 255.255.255.255,
maximum value of 2Byte is 65536
2:4ByteASN:2Byte -> 2:4294967296:65536 -> 18 characters
maximum value of 4ByteASN is 4294967296,
maximum value of 2Byte is 65536
-----

> if you bring up a good reason.

I reconsidered my opinion, I agree that exporters should be free to
choose between fixed or variable length encoding of a particular IE.
On the other hand, I am afraid that collectors increase load by decoding
variable length IEs. Indeed, "The IPFIX Template mechanism is optimized
for fixed length Information Elements" is written in IPFIX-PROTO.
When a exporter treats a IE whose data type is octetArray but the data
size is steady, exporter will use fixed length encoding (for example
above mplsVpnRouteDistinguisher is octetArray IE, but the data size is 8
octets, the size is fixed (if this IE is in conformity to rfc4364)).

I think that the use should not be restricted, but I think definition of
IE should provide information about which prefer fixed or variable, and
provide minimum / maximum size length octetArray and string type IEs to
prevent confusion for implementation. (Similarly, I think definition of
IE should provide information whether the IE may be apply reduced size
encoding for integer and float type IEs.)

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549

---

From: Hitoshi Irino <[email-masked]>
Date: Mon, 30 Oct 2006 17:49:00 +0900

Dear Juregen,

Thank you.

I have same question.

---

From: Paul Aitken <[email-masked]>
Date: Mon, 30 Oct 2006 11:27:34 +0000

Hitoshi-san,

> I am afraid that collectors increase load by decoding variable length
> IEs.

Then collectors should be designed to decode this as efficiently as
possible.

> I think definition of IE should provide information about which 
> prefer fixed or variable, and provide minimum / maximum size length 
> octetArray and string type IEs to prevent confusion for 
> implementation.

Choice of fixed / variable length IEs depends on the values coming from
the monitoring process and whether the exporting process can encode them
more efficiently as a multitude of seperate templates, or as one
template using variable sizes IEs.

Probably fixed size IEs are prefered over needlessly using variable 
size, but variable size is preferred over needlessly creating a large 
number of templates.

Regarding IE size, currently, there is only one string type IE:
wlanSSID, which includes a size indication in its description:

    Description:
       The Service Set IDentifier From [email-masked] Mon Oct 30 06:34:09 2006
Date: Mon, 30 Oct 2006 11:27:34 +0000
From: Paul Aitken <[email-masked]>
To: Hitoshi Irino <[email-masked]>
Subject: Re: [IPFIX] Question about data types of some IEs
Cc: [email-masked]

Hitoshi-san,

> I am afraid that collectors increase load by decoding variable length
> IEs.

Then collectors should be designed to decode this as efficiently as
possible.

> I think definition of IE should provide information about which 
> prefer fixed or variable, and provide minimum / maximum size length 
> octetArray and string type IEs to prevent confusion for 
> implementation.

Choice of fixed / variable length IEs depends on the values coming from
the monitoring process and whether the exporting process can encode them
more efficiently as a multitude of seperate templates, or as one
template using variable sizes IEs.

Probably fixed size IEs are prefered over needlessly using variable 
size, but variable size is preferred over needlessly creating a large 
number of templates.

Regarding IE size, currently, there is only one string type IE:
wlanSSID, which includes a size indication in its description:

    Description:
       The Service Set IDentifier (SSID) identifying an 802.11 (Wi-Fi)
       network used.  According to IEEE.802-11.1999 the SSID is encoded
       into a string of up to 32 characters.

There are two array type IEs: paddingOctets, which needs no size, and
mplsVpnRouteDistinguisher, which is discussed in your mail.

I would be happy for mplsVpnRouteDistinguisher either to be changed to
unsigned64, or to remain as an array but include this text in its
description:

     According to section 4.2 in rfc4364, a VPN-IPv4 address
     consists of an 8-byte Route Distinguisher followed by a
     4-byte IPv4 address.

BTW, it doesn't discuss IPv6...

> (Similarly, I think definition of IE should provide information 
> whether the IE may be apply reduced size encoding for integer and 
> float type IEs.)

I disagree: this information should not be provided per IE, but only as
a general guideline - which you will already find in section 6.2 of
IPFIX-PROTO.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Paul Aitken <[email-masked]>
Date: Mon, 30 Oct 2006 11:27:34 +0000

Hitoshi-san,

    Description: