Re: [trill] Order of bits in TRILL bitmaps

[Petr Hroudný <[e-mail]>]

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

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?

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

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.

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