Re: [IPFIX] TCP flags?

Andrew,

>> Another possibility was to add a new IE for the uppermost bits. In 
>> some cases the two IEs could be exported alongside each other, so the 
>> 16 bits would be in order (although that need not always be the case).
>
> I don't like the option of a new IE for just the high bits.  If we 
> must create a new IE I think we should go all the way and take option 
> 3.  Exporting the an IE for the high bits and the existing IE adjacent 
> to each other is cute, but seems like a lot of complexity for no real 
> gain.
>
> One other question.  With this option would the semantics of the 
> existing IE change if both IEs are exported or would the ECE and CWR 
> bits just remain ambiguous?

I guess all the bits would be defined. However, I like this less than 
option 2 or 3.


>>> Assuming I got the above correct here are my thoughts.
>>>
>>> If we are going to make the changes for option 1 we might as well go 
>>> all the way to option 2.  We've covered this before, but having 
>>> separate data types for different integer lengths is pretty much 
>>> pointless since the size is always exported in the template.  From a 
>>> collector stand point I pretty much have to respect the length in 
>>> the template so increasing this to a unsigned 16 is no real work for 
>>> me.
>>
>> What I said before: changing the size doesn't actually change the 
>> type. Fundamentally we only have signed and unsigned, in various 
>> sizes. If we'd recognised this years ago, we wouldn't need the 
>> "reduced size encoding" rule; collectors would just accept whatever 
>> the templates tell them.
>>
>>
>>> The only real difference I see between options 2 and 3 is that the 
>>> reduced size encoding for option 2 will always be ambiguous for two 
>>> bits.  I don't yet have an opinion on how big a deal that is. Can we 
>>> increase the size of the current TCP flags and deprecate the export 
>>> of the reduced size encoding?
>>
>> That could work. However, existing implementations would continue to 
>> export 8 bits, where the top 2 bits are ambiguous.
>
> That is true regardless of what option we ultimately decide on.
>
>>
>>
>>> I currently have a very slight preference for option 2 (with or 
>>> without deprecating reduced size encoding), but there is still a 
>>> quite, but persistent, voice in the back of my head saying option 3 
>>> is "the right thing".
>>
>> Is it possible that some collectors might break if they receive a 
>> field with a different size from what 5102 / IANA says? eg, there was 
>> a problem with old versions of wireshark where it had built-in 
>> expectations of field sizes, and couldn't cope with the change of 
>> sampler ID from 8 bits to 16 bits to 32 bits.
>
> This is a more general issue for wireshark than just sampler ID. Any 
> IE sent with reduced size encoding was liable to blow things up.  8 
> and 4 byte decodes were implemented for some IEs where people had run 
> into both encodings.  Other sizes would still have caused issues.  I 
> ran into this about a month ago for an IE specified as unsigned64, but 
> with a decode expecting unsigned32. It appears that the latest dev 
> branch of wireshark is better about this, but I haven't really looked 
> to see how complete the fixes are.
>
>
>> If that might be the case, then a new IE is indicated. OTOH, if 
>> nobody knows of such a possibility, then (2) might work equally as well.
>
> I can only speak for my implementation and I don't see 2 as a 
> problem.  However, as you pointed out implementations like wireshark 
> are known to have had issues with similar changes in the past.  That 
> said I'm not sure how much weight I give to wireshark's IPFIX 
> implementation.  Last time I looked wireshark didn't handle other 
> protocol details like template IDs that change after an exporter reboot.

Wireshark's dissector has improved, but I think it needs completely 
rewritten by someone who's actually familiar with netflow and IPFIX.


> I still like option 2, but could be persuaded that 3 is the better option.

+1

Does anyone object to option 2?

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