Re: [trill] Order of bits in TRILL bitmaps

Mingui Zhang <zhangmingui@huawei.com> Fri, 22 August 2014 03:35 UTC

Return-Path: <zhangmingui@huawei.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D501A6FF9 for <trill@ietfa.amsl.com>; Thu, 21 Aug 2014 20:35:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.569
X-Spam-Level:
X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_0Ifda56fiC for <trill@ietfa.amsl.com>; Thu, 21 Aug 2014 20:35:56 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409EE1A6FF8 for <trill@ietf.org>; Thu, 21 Aug 2014 20:35:56 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLN55432; Fri, 22 Aug 2014 03:35:54 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Aug 2014 04:35:53 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.78]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 22 Aug 2014 11:35:46 +0800
From: Mingui Zhang <zhangmingui@huawei.com>
To: =?utf-8?B?UGV0ciBIcm91ZG7DvQ==?= <petr.hroudny@gmail.com>
Thread-Topic: [trill] Order of bits in TRILL bitmaps
Thread-Index: AQHPvQr4J/OWExjMO0STwoGLyAz8aJvapXYQ///DRACAAYSCYA==
Date: Fri, 22 Aug 2014 03:35:46 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E76AAAE8E6@nkgeml512-mbx.china.huawei.com>
References: <CANi4_5fGtOVvC0nwqdoWXEv5AraQR_UY4NmYuaUYvpt5xjvQyQ@mail.gmail.com> <4552F0907735844E9204A62BBDD325E76AAAE6BB@nkgeml512-mbx.china.huawei.com> <CANi4_5fhMfUKLhuAy5gqe4jguBiw8DNYW=yL+LgFLpk=CPAuAA@mail.gmail.com>
In-Reply-To: <CANi4_5fhMfUKLhuAy5gqe4jguBiw8DNYW=yL+LgFLpk=CPAuAA@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.102.175]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/trill/NRy6ytFXt8oSEczP9hVY7PvGVZ4
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] Order of bits in TRILL bitmaps
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Aug 2014 03:35:58 -0000

Hi Petr,

Please see my responses in line below.

>-----Original Message-----
>From: Petr Hroudný [mailto:petr.hroudny@gmail.com]
>Sent: Thursday, August 21, 2014 7:39 PM
>To: Mingui Zhang
>Cc: trill@ietf.org
>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 <zhangmingui@huawei.com>:
>
>
>	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
>	>
>	>
>
>
>