Re: [IPFIX] two issues for RFC5102bis

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