Re: [IPFIX] tcpControlBits, ECN, and IE-DOCTORS

Brian,

Any IPFIX changes in the < 128 block should also be reflected in NFv9. 
If the change can't be in NFv9 for some reason, then a new IPFIX IE 
should be allocated.

If this isn't corrected then presumably IANA and the IPFIX expert 
reviewers would assume sole authority for changes in the < 128 block, 
which could have the undesirable effect of making IEs in this section 
incompatible with NFv9.

So short answer: yes, this should be corrected.

As a NFv9 expert, I'd be happy to see the ECE and CWR bits added to the 
existing IANA definition - although this means that CP can't know for 
sure what the 0-valued bits mean: they could be !ECE / !CWR, or they 
could be old implementations which mask out those bits. Hopefully the 
latter will disappear over time, so we can come to trust the bits.

P.


On 21/08/12 17:49, Brian Trammell wrote:
> Greetings, all,
>
> I note that the definition of IE 6, tcpControlBits, uses the RFC793 definition of the TCP Flags byte, ignoring the changes to the definition of this field made by RFC3168 (ECN). The "must be zero" language here has two unfortunate consequences: (1) it obliges MP implementors to mask the field by 0x3F to zero out bytes that may be set in headers due to ECN negotiation and (2) it makes it impossible to use compliant implementations to measure ECN negotiation.
>
> I have verified that the at least one shipping implementation of NetFlow V9 follows the IANA definition; it does indeed mask 0x3F, destroying ECN negotiation information. Yes, I know "nobody uses ECN" but recent active measurement efforts have shown increased default support for ECN negotiation; see e.g. Honda et al. in IMC 2011.
>
> I'd considered the right way to address this in view of the proposed IE-DOCTORS process; a change adding ECE and CWR to tcpControlBits would indeed appear to be eligible for an updated IE on first pass per section 5.2 (it harmonizes with an updated external reference (3168 updates 793, though the update happened before the definition of IPFIX); it also defines a previously reserved bit in an IE with flag semantics). However, tcpControlBits is in the magic lower 128 V9-compatible space; new IEs in this space require V9 expert approval, but changes (as yet) do not. Should this be corrected?
>
> Cheers,
>
> Brian
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

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