Re: [spb-isis] 802.1aq SPB 3rd Interop

Peter Ashwood-Smith <> Wed, 21 September 2011 09:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0090821F8B82 for <>; Wed, 21 Sep 2011 02:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.185
X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LRqStYVp9+AK for <>; Wed, 21 Sep 2011 02:52:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7030221F8B80 for <>; Wed, 21 Sep 2011 02:52:18 -0700 (PDT)
Received: from (usaga03-in []) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Wed, 21 Sep 2011 04:54:46 -0500 (CDT)
Received: from LapPSmith ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <> for; Wed, 21 Sep 2011 04:54:45 -0500 (CDT)
Date: Wed, 21 Sep 2011 05:54:41 -0400
From: Peter Ashwood-Smith <>
In-reply-to: <002901cc4b58$d5de1b50$>
Message-id: <001501cc7844$7dc89b70$>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acw1EjtzZcSwj3hbSr6x/xQD/Tlr+gAr7qHwAATZ8WAAMFp1cAAK4mVwAB4tQnADiqaD0AF8kiZwCzrqMWA=
Subject: Re: [spb-isis] 802.1aq SPB 3rd Interop
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The members of this list will discuss the requirements, functionality and extensions to ISIS to support 802.1aq." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Sep 2011 09:52:19 -0000

Thought it would be useful to share some of the results of the SPB topology
digest computations since clearly we all have to get the same results for
proper interop and the topolgy digest should be tested in the next interop.

So here is a trivial topolgoy and the digest that I compute for it. No
guarantee its correct but would like to compare to somebody else.... Panos?

So two nodes, with a single link between them with symmetric link costs of
10. Both nodes with a BridgePriority of 0 and using MTID 0.

Node A has BridgeIdentifier = 4455.6677.0101     
Node B has BridgeIdentifier = 4455.6677.0102     

The A to B adjacency formatted as per 28.4.6 (high bridge id, low bridge id
...) and then the 16 byte MD5 as computed using the code in the appendix of
RFC 1321.

ADJ A->B    [00004455667701020000445566770101000000000a00000a]
MD5 of ADJ  [2f3af493059e68f92792719ccbe949ef]

Since the link metric is the same in both directions, the B-A data is the
same and therefore the MD5 for B->A is the same. Now according to 28.4.6 we
should add both directions it means the same MD5 value gets added twice to
the topology digest.

ADJ B->A    [00004455667701020000445566770101000000000a00000a]
MD5 of ADJ  [2f3af493059e68f92792719ccbe949ef]

This is the resulting full digest field according to Figure 28-1. You can
see the edge count (2), the zeros , the 20 byte sum of the two MD5 values
above and the other flags as per 28.4

TOPDIGEST [000200020000000000000000000000005e75e9260b3cd1f24f24e33997d293de]