Re: [trill] Order of bits in TRILL bitmaps

[Mingui Zhang <[e-mail]>]

Hi Petr,

Please see my responses in line below.

>-----Original Message-----
>From: Petr Hroudný [mailto:[e-mail]]
>Sent: Thursday, August 21, 2014 7:39 PM
>To: Mingui Zhang
>Cc: [e-mail]
>Subject: Re: [trill] Order of bits in TRILL bitmaps
>
>Hi Mingui,
>
>
>thanks for your answer. I forgot to mention that I'm looking at ISIS packets on
>the wire using tcpdump.
>
>Here are the raw captures:
>
>
>TRILL-Version SubTLV:       0d 05 01 00 00 00 40

Here, the Type field is 0d->13. So the raw capture shows that it is the big-endian, i.e., the highest order bit is in the left most bit.

>
>
>So the capabilities bitmap is probably byte-wise reversed here?
>
>
>Enabled-VLANs SubTLV:    02 03 00 0a 01  -  only VLAN 10 enabled
>Enabled-VLANs SubTLV:    02 03 00 01 0b  -  VLANs 1,2 and 4 enabled
>
>
>Regarding the Enabled-VLANs: as the bitmap has to be at least 1 byte long, the
>RBridge needs to fill at least 8 bits in the bitmap, right?

Yes, it needs to fill at least one octet. So the two possibilities are:
1. If the highest-order bit is the left most bit, we have 1101 0000->0xD0
2. If the highest-order bit is the right most bit, we have 0000 1011->0x0B

The first one 0xD0 is correct. 

>
>
>So if the highest-order bit is the left most bit, the last byte of the SubTLV should
>be:
>
> 10000000 -> 0x80 with only VLAN 10 enabled
>
> 11010000 -> 0xD0 with VLANs 1,2 and 4 enabled
>

Correct.

>
>The actual values seen on the wire have the highest-order bit in the right most
>bit, so we see 0x01 and 0x0b in the SubTLV.

As we can see above, the capture is big-endian. 

As indicated by Tissa, please make sure the functions hton and ntoh is happening correctly. I read "The htons function takes a 16-bit number ....". But now, the example is of only 8 bits.
 
>
>
>Which order is the correct one?
>
>
>   Thanks, Petr
>
>
>
>
>
>
>
>2014-08-21 10:20 GMT+02:00 Mingui Zhang <[e-mail]>:
>
>
>	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:[e-mail]] On Behalf Of Petr Hroudny
>	>Sent: Thursday, August 21, 2014 2:38 PM
>	>To: [e-mail]
>	>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
>	>
>	>
>
>
>