Re: [IPFIX] IPFIX: boolean, dot1qDEI and dot1qCustomerDEI

On 09/04/2013 06:26 PM, Paul Aitken wrote:
> 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.

Works for me.

-Andrew

>
> 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