Subject: [trill] Order of bits in TRILL bitmaps

From: Petr Hroudný <[email-masked]>
Date: Thu, 21 Aug 2014 08:37:46 +0200

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

---

From: Mingui Zhang <[email-masked]>
Date: Thu, 21 Aug 2014 08:20:23 +0000

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:[email-masked]] On Behalf Of Petr Hroudny
>Sent: Thursday, August 21, 2014 2:38 PM
>To: [email-masked]
>Subject: [trill] Order of bits in TRILL bitmaps
>
>Hi all,
>
>
>I understand this as follows: if only the start VLAN ID is enabled, the bitmap
>should have a value of 0x80.
>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
>
>

---

From: Petr Hroudný <[email-masked]>
Date: Thu, 21 Aug 2014 13:38:44 +0200

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 <[email-masked]>:

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

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Thu, 21 Aug 2014 15:47:58 +0000

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:[email-masked]] On Behalf Of Mingui Zhang
Sent: Thursday, August 21, 2014 1:20 AM
To: Petr Hroudný; [email-masked]
Subject: Re: [trill] Order of bits in TRILL bitmaps

Hi Petr,

For the second two, 

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

My 2 cents,
Mingui

>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.
>
>
>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 0x00, 
>0x00, 0x00, 0x40
>
>Which one is correct?
>
>

_______________________________________________
trill mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 21 Aug 2014 14:45:47 -0400

Hi Petr,

> Nevertheless, I've seen an implementation, where the bitmap reads 0x01.

The default in the IETF is big-endian. so the high order bit of a byte
is 0x80. I believe that if you send that byte on Ethernet, you will
see seven zeros followed by a one because that media sends the low
order bit first. In any case, I think 0x80 is correct.

> I understand this as follows: if I want to set the FGL-safe bit (bit 1), the
> bitmap should read 0x40 0x00 0x00 0x00.
>

The "network order" used in the IETF for a 32 bit field is to send
send bytes from left to right. This bit vector is like (well, it is
the same size) a IPv4 address which is also described as having 32
bits numbered from 0 through 31 (see Figure 4 of RFC 791). If you send
the loopback address (127.0.0.1), the "127" byte gets sent first and
the "1" byte last. On a serial media, the "127" byte might be
0b11111110 (how I believe it is on Ethernet) or 0b01111111, but it is
still the first byte transmitted.

So I would say 40-00-00-00 is correct.

> As this might create a serious interop issues, I'm seeking for WG opinion on

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 22 Aug 2014 03:35:46 +0000

Hi Petr,

Please see my responses in line below.

>From: Petr Hroudný [mailto:[email-masked]]
>Sent: Thursday, August 21, 2014 7:39 PM
>To: Mingui Zhang
>Cc: [email-masked]
>thanks for your answer. I forgot to mention that I'm looking at ISIS packets on
>the wire using tcpdump.
>

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.

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

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.
 
>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:
>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
>
>
>0x00,