Re: [IPFIX] two issues for RFC5102bis

Benoit,

Perhaps you're right; it's already too late.

Thanks,
P.


On 16/01/12 16:41, Benoit Claise wrote:
> Paul,
>
> Thanks for your email.
> These two open issues are related.
> See my reply in line.
>> Dear IPFIX experts,
>>
>> Two issues for RFC5102bis:
>>
>>
>> Firstly, can we recognise that unsigned8, unsigned16, unsigned32, and 
>> unsigned64 aren't different types; they're simply different lengths 
>> of the same type. Accordingly, we should use a single "unsigned" type.
>>
>> Similarly for signed.
>>
>> Else, when using reduced size encoding to export unsigned64, the 
>> implication is that the _type_ changes? Clearly this isn't the case.
>>
>> The encoding of float32 and float64 differs, so these should remain 
>> as different types.
> Andrew Johnson reminded me that RFC 5101 states that you can RLE a 
> float64 down to a float32
> So no distinction between unsigned and float is required in this 
> discussion.
>
> I'm thinking about the implications of such a change, i.e,
>     unsigned8, unsigned16, unsigned32, and unsigned64 become unsigned
>     signed8, signed16, signed32, and signed64 become signed
>     float 32, float34 become float
> What about the backward compatibility?
> It means that we have to obsolete all IEs in IPFIX IANA whose type is 
> unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, 
> signed32, signed64, float32 or float64, right? And then reassigned 
> those to unsigned, signed, or float.
> Is this realistic?
>
> Trying to evaluate the gain now ... I'm not convinced. Yes it's 
> cleaner from a protocol point of view but is it enough?
> Somehow, I like it to see ipClassOfService = unsigned8. Without it, I 
> would need to rely on the description to discover (or read) this 
> information.
>
>     "For IPv4 packets, this is the value of the TOS field in
>     the IPv4 packet header.  For IPv6 packets, this is the
>     value of the Traffic Class field in the IPv6 packet header."
>
>>
>>
>> Secondly, the info model should not specify the field size since 
>> sizes are specified in the template.
>>
>> There was one argument that the maximum length must be specified for 
>> collector database design. 
> Yes, that was discussed in the past.
>> This is only an issue if differently-sized fields are stored in the 
>> same database - eg, the database field is only 8 bits wide, and is 
>> suddenly required to store a 16- or 32-bit wide field. This may only 
>> be an issue in an IPFIX aggregator.
> Why? I see this as a generic problem for any collector.
> Example: a big fat router, with only one line card. You could encode 
> in the ingress interface as unsigned8, as optimized by the Exporting 
> Process.
> The collector receives the first template record, and designs its 
> database with an key of size 8.
> Then you add more line cards, while the router is still exporting, 
> suddenly the Exporting Process must export an ingress interface= 
> unsigned16
> Then you add virtual interfaces, and you need ingress interface = 
> unsigned32
>>
>> If this is a real issue, then the infomodel should specify the 
>> maximum length for each field, rather than confusing this with the 
>> field type.
> Maybe, it should have been cleaner if we had done this from day one 
> for all types, but isn't it a little bit too late?
>
> Note the max length is specify in the description  (even if I found 
> one or two entries where it's not done) for octetArray and string:
>     mplsVpnRouteDistinguisher, octetArray  -> "The maximum length of 
> this Information Element is 256 octets"
>     messageMD5Checksum, octetArray -> "This Information Element has a 
> fixed length of 16 octets."
>     wlanSSID, string, "the SSID is encoded into a string of up to 32 
> characters."
>     ...
>
> Note for the IE-doctors: always specify the IE max length, for the 
> collector database design.
>
> Regards, Benoit.
>>
>>
>> Thanks,
>> P.
>> _______________________________________________
>> IPFIX mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ipfix
>>
>>
>

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix