Re: [IPFIX] IPFIX: boolean, dot1qDEI and dot1qCustomerDEI
Paul Aitken <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
Andrew, I think it depends a lot on what was already implemented - or perhaps, on what we suspect may already have been implemented, given that we can't possibly expect to know them all. In practice, I suspect that only Yaakov Stein has implemented these fields so far... so I'd be happy to be guided by whatever he did. From his earlier reply, I suspect that may be option 1 : LSB = 0 or 1. P. On 04/09/13 22:50, Andrew Feren wrote: > Hi Paul, all, > > I think some clarification is needed, but I'm not sure what the right > answer is. > > I see at least three valid readings of the combination of boolean, > flags, and "The value of the 1-bit Drop Eligible Indicator (DEI) field" > > 1) send "the value": if DEI bit set (0x01) / unset (0x00) (looks a lot > like least significant bit set/unset ;-) > This is what the initial correction seems to assume. > > > 2) semantics "flags": if DEI bit set (0x10) / unset (0x00). > This is the interpretation that including pcp would require > > > 3) strict data type "boolean": if DEI bit set (0x01) / unset (0x02). > This is a variation on option 1 where boolean was interpreted strictly. > > 1 and 2 can be viewed as the same except for which bit gets flipped. > > > On 09/03/2013 05:57 AM, Paul Aitken wrote: >> Yaakov, >> >>> Fine with me since it simplifies the interpretation (DEI=0 means >>> green and DEI=1 means yellow). >>> >>> By first bitdo you mean least significant bit? >>> >> >> Yes. If needs be we could add a figure something like so: >> >> 0 1 2 3 4 5 6 7 >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> | Reserved | DEI | >> +-----+-----+-----+-----+-----+-----+-----+-----+ > > This is option 1 and is compatible with 3 as long as reserved bit 6 is > never used. Option 2 only ever sets bit 7 to 0, but does change bit 3 > in the reserved area. > >> >> Although if we were defining this again, it might be more useful to >> retain the DEI position, and potentially include the PCP bits. >> >> So, per 802.1Q-2011 Figure 9-1 (attached) : >> >> 0 1 2 3 4 5 6 7 >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> | PCP | DEI | Reserved | >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> >> However I suspect that this is incompatible with current >> implementations, so the change is not possible? > > This is a total change as this is no longer just dot1qDEI. > > I'm slightly in favor of option 1, but ultimately I simply don't want > to receive an identical value from different exporters which I am > expected to interpret differently. > > > -Andrew > > >> >> P. >> >> >>> *From:*Paul Aitken [mailto:[email protected]] >>> *Sent:* 02 September, 2013 21:46 >>> *To:* IETF IPFIX Working Group; [email protected] >>> *Cc:* Yaakov Stein >>> *Subject:* IPFIX: boolean, dot1qDEI and dot1qCustomerDEI >>> >>> Dear IPFIX experts, >>> >>> While reviewing IANA's IPFIX registry, I noticed that although IEs >>> #388 dot1qDEI and #389 dot1qCustomerDEI are defined as "boolean" >>> their definitions do not correspond to that type. >>> >>> As a reminder, RFC5101bis says: >>> >>> 6.1.5. boolean >>> >>> The boolean data type is specified according to the TruthValue in >>> [RFC2579]. It is encoded as a single-octet integer per >>> Section 6.1.1,with the value 1 for true and value 2 for false. >>> Every other value is undefined. >>> >>> >>> (for consistency with MIB truthValue). >>> >>> So a boolean IE cannot capture a bit field such as the DEI required >>> by #388 and #389. I checked the other boolean IEs, and they're fine. >>> >>> To correct this, I propose that #388 and #389 be changed from >>> "boolean" to "unsigned8", in line with all the other flags fields: >>> >>> 388 >>> >>> >>> >>> dot1qDEI >>> >>> >>> >>> boolean >>> unsigned8 >>> >>> >>> >>> flags >>> >>> >>> >>> current >>> >>> >>> >>> >>> The first bit of this octet is the value of the 1-bit Drop Eligible >>> Indicator (DEI) field of the VLAN tag as described in 802.1Q-2011 >>> subclause 9.6. In case of a QinQ frame, it represents the outer >>> tag's DEI field and in case of an IEEE 802.1ad frame it represents >>> the DEI field of the S-TAG. Note: in earlier versions of 802.1Q the >>> same bit field in the incoming packet is occupied by the Canonical >>> Format Indicator (CFI) field, except for S-TAGs. >>> The remainder of this octet is reserved for future use. >>> >>> 389 >>> >>> >>> >>> dot1qCustomerDEI >>> >>> >>> >>> boolean >>> unsigned8 >>> >>> >>> >>> flags >>> >>> >>> >>> current >>> >>> >>> >>> >>> In case of a QinQ frame, the first bit of this octet it represents >>> the inner tag's Drop Eligible Indicator (DEI) field and in case of >>> an IEEE 802.1ad frame it represents the DEI field of the C-TAG. >>> The remainder of this octet is reserved for future use. >>> >>> >>> >>> Feedback? >>> >>> 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