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

From: Paul Aitken <[email-masked]>
Date: Mon, 02 Sep 2013 19:45:32 +0100

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.

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 3 Sep 2013 06:51:18 +0000

Fine with me since it simplifies the interpretation (DEI=0 means green and DEI=1 means yellow).

By first bit do you mean least significant bit ?

Y(J)S

From: Paul Aitken [mailto:[email-masked]]
Sent: 02 September, 2013 21:46
To: IETF IPFIX Working Group; [email-masked]
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.

6.1.5.  boolean

   Section 6.1.1, with the value 1 for true and value 2 for false.

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.

---

From: Paul Aitken <[email-masked]>
Date: Tue, 03 Sep 2013 10:57:28 +0100

Yaakov,

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

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?

P.

> *From:*Paul Aitken [mailto:[email-masked]]
> *Sent:* 02 September, 2013 21:46
> *To:* IETF IPFIX Working Group; [email-masked]
> *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 
> 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
>
> 	
>
>

---

From: Andrew Feren <[email-masked]>
Date: Wed, 4 Sep 2013 17:50:06 -0400

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.

> Yes. If needs be we could add a figure something like so:

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.

> So, per 802.1Q-2011 Figure 9-1 (attached) :

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

>> #388 dot1qDEI and #389 dot1qCustomerDEI are defined as "boolean" 
>> their definitions do not correspond to that type.
>>
>> 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.
>>
>> 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.
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Wed, 04 Sep 2013 23:26:59 +0100

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

---

From: Andrew Feren <[email-masked]>
Date: Thu, 5 Sep 2013 08:43:01 -0400

> From his earlier reply, I suspect that may be option 1 : LSB = 0 or 1.

Works for me.

-Andrew

>> 1) send "the value": if DEI bit set (0x01) / unset (0x00) (looks a 
>> lot like least significant bit set/unset ;-)
>> 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.
>>