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

From: Juergen Quittek <[email-masked]>
Date: Thu, 02 Nov 2006 23:50:04 +0100

Dear Irino-san,

--On 30.10.06 17:49 +0900 Hitoshi Irino wrote:

> Dear Juregen,
>
> Juergen Quittek wrote:
>> 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.
>
> Thank you.
> I confirmed these changes in IPFIX-INFO-14
>
>>> 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.
>>
>> 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.
>
> 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.

Sorry. This statement is wrong.
As last minute change I used octetArray instead of unsigned64.
This is still fine for the current definition in RFC 4364 but also
matches the specification in RFC 4382 that is cited above.
The octetArray in our info model corresponds to the SMIv2 OCTET STRING.

>> 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 have same question.

I checked with the authors.  They just did not see a reason to limit
the size to 8 octets and rather preferred to be open to extensions
or future formats of route distinguishers.  I followed their
recommendation for the info model.

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

I did not yet consider encoding as text string.
In the MIB module it's an octet string that matches our
octetArray.

>>
>> 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.
>
> 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.)

So far, the mplsVpnRouteDistinguisher is the only info element of type
octetArray (except for the padding IE). In RFC 4382 no recommendation
about the 8 octet encoding was given. Would it really be necessary to
state "please encode an 8 octet identifier in an octetArray of size 8?

Thanks,

    Juergen

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

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

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 02 Nov 2006 23:50:04 +0100

Dear Irino-san,

Thanks,

    Juergen

---

From: Hitoshi Irino <[email-masked]>
Date: Fri, 03 Nov 2006 14:00:07 +0900

Dear Juergen,

> The octetArray in our info model corresponds to the SMIv2 OCTET STRING.

I understand the reason of using octetArray by your explanation.

> state "please encode an 8 octet identifier in an octetArray of size 8?

It is not necessary to describe "please encode an 8 octet identifier in 
an octetArray of size 8". But I want the description of this IE to 
explains "The size of mplsVpnRouteDistinguisher is 8 octets accroding to 
RFC4364. The octetArray is adopted to correspond to the SMIv2 OCTET 
STRING which is a data type of MplsL3VpnRouteDistinguisher in RFC4382, 
and to be open to future extensions."

Regards,
Hitoshi Irino

---

From: Hitoshi Irino <[email-masked]>
Date: Fri, 03 Nov 2006 14:00:07 +0900

Dear Juergen,

Regards,
Hitoshi Irino

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 03 Nov 2006 15:59:41 +0100

Dear Irino-san,

--On 03.11.06 14:00 +0900 Hitoshi Irino wrote:
> an octetArray of size 8". But I want the description of this IE to explains
> "The size of mplsVpnRouteDistinguisher is 8 octets accroding to RFC4364.
> The octetArray is adopted to correspond to the SMIv2 OCTET STRING which
> is a data type of MplsL3VpnRouteDistinguisher in RFC4382, and to be open
> to future extensions."

I see.  I think this is a good idea.  I will add it to the list of issues
for the next revision of the draft.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 03 Nov 2006 15:59:41 +0100

Dear Irino-san,

Thanks,

    Juergen