Re: [trill] Order of bits in TRILL bitmaps

Looks like to me there is an endian issue here, you may want to check against whether hton and ntoh is happening correctly. Specially if the platform is of little endian form CPU. (Assuming implementation is packing bits correctly).

-----Original Message-----
From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Mingui Zhang
Sent: Thursday, August 21, 2014 1:20 AM
To: Petr Hroudný; trill@ietf.org
Subject: Re: [trill] Order of bits in TRILL bitmaps

Hi Petr,

This is an interesting issue! 

For the second two, 

from the figures in sections 2.2.4 & 2.3.1, we can see the bit Vector is encoded as the Most Significant Bit is the right most bit. So, the right value for FGL-safe is 0x40, 0x00, 0x00, 0x00. (It's strange that the implementation does not read as 0x00 0x00 0x00 0x02.)

For the first two, 

In the RFC, the bitmap is defined to have a variable length. If only the start VLAN ID is enabled, the bitmap always reads as 0x1 no matter it is encoded as the Most Significant Bit is the right most bit or the left most bit. So this example doesn't tell the difference. Let me use another example: suppose we need to encode a VLAN list 1, 2, 4. There are two possibilities:
1. If the highest-order bit is the left most bit, we have 1101->0xD 2. If the highest-order bit is the right most bit, we have 1011->0xB

The RFC does not explicitly point out the bitmap is encoded in a network order, so it should be encoded by default as that the highest order is the left most bit. So 0xD is the right answer. 

My 2 cents,
Mingui

>-----Original Message-----
>From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Petr Hroudny
>Sent: Thursday, August 21, 2014 2:38 PM
>To: trill@ietf.org
>Subject: [trill] Order of bits in TRILL bitmaps
>
>Hi all,
>
>
>I'm looking for the WG opinion about the correct order of bits in 
>bitmaps specified in RFC7176 sections 2.2.2 & 2.2.5 and 2.2.4 & 2.3.1.
>
>
>For the first two, the RFC says:
>
>
>   o  VLAN bit-map: The highest-order bit indicates the VLAN equal to
>      the start VLAN ID, the next highest bit indicates the VLAN equal
>      to start VLAN ID + 1, continuing to the end of the VLAN bit-map
>      field.
>
>I understand this as follows: if only the start VLAN ID is enabled, the 
>bitmap should have a value of 0x80.
>Nevertheless, I've seen an implementation, where the bitmap reads 0x01.
>
>Which one is correct?
>
>
>For the second two, the RFC says:
>
>   o  Capabilities and Header Flags Supported: A bit vector of 32 bits
>      numbered 0 through 31 in network order.
>
>I understand this as follows: if I want to set the FGL-safe bit (bit 
>1), the bitmap should read 0x40 0x00 0x00 0x00.
>
>Nevertheless, I've seen an implementation, where the bitmap reads 0x00, 
>0x00, 0x00, 0x40
>
>Which one is correct?
>
>
>As this might create a serious interop issues, I'm seeking for WG opinion on this.
>
>
>    Thanks, Petr
>
>

_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill