Re: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05

Jari Arkko <jari.arkko@piuha.net> Fri, 18 September 2015 13:49 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8110C1B2BF1; Fri, 18 Sep 2015 06:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 dhkNMsDFu3xY; Fri, 18 Sep 2015 06:49:23 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id A317B1AD362; Fri, 18 Sep 2015 06:49:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7A2752CEE6; Fri, 18 Sep 2015 16:49:20 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNxuQ4q6gucB; Fri, 18 Sep 2015 16:49:19 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 2FD9A2CEA0; Fri, 18 Sep 2015 16:49:16 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_85E7512B-B21B-4B82-8CD8-7C285E6F0031"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.1
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <CAF4+nEEcz7fQLaXZSSGFrEECOfeLkhqUwrXbpjkxRnuybeefOA@mail.gmail.com>
Date: Fri, 18 Sep 2015 06:49:15 -0700
Message-Id: <F779EA16-6E52-46BA-A555-6485CCC7E459@piuha.net>
References: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com> <4552F0907735844E9204A62BBDD325E7871A2CFE@nkgeml512-mbx.china.huawei.com> <CAF4+nEGAnyBVrv=Rbc0gfDijYsjraBW62ugC1Rwo07e6PSg_NA@mail.gmail.com> <53C61587-9F97-4664-9F84-603199B46D3E@vigilsec.com> <EBCEEEC6-1184-420F-BC8E-D19444A0A54A@piuha.net> <CAF4+nEEcz7fQLaXZSSGFrEECOfeLkhqUwrXbpjkxRnuybeefOA@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/ow7YqDLRbBvIdj6Vn65ZI8QBrvs>
Cc: IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>, "draft-ietf-trill-pseudonode-nickname.all@ietf.org" <draft-ietf-trill-pseudonode-nickname.all@ietf.org>
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2015 13:49:25 -0000

Donald,

>> (Maybe this helps: I’m not actually sure why in a k-element set you order them based <something> mod k because that would seem to produce likely duplicates. Since your backup option in the case of duplicates is proper numeric sort, why just not do that and only that? E.g. "RBridges are sorted in byte string ascending order by their LAALP IDs, or if they are equal, by their System IDs considered as unsigned integers.” But it could also be that it is too early and I have not yet had enough Diet Coke…)
> 
> I believe the idea is to quasi-randomize the order. The DF election is
> per VLAN and a goal is to spread the multicast traffic across the
> RBridges in the active-active edge group.

It is a fine goal to randomise the order.

My only observation of the current setup is that if you randomise a
k-element group through "mod k” operation, you will likely have
some number of collisions in the result. I don’t know enough
about math to calculate the percentage. But for the sake of
argument, if k=2 it seems that the likelihood of collision is 50%.

And for every collision, your order becomes no longer random
but simply numerical order of the identifiers. In our degenerate
k=2 example it seems that in 50% of the cases you have a random
order and 50% of the cases you have numerical order. I’m sure
there would be other ways to randomise the order with less
collisions, if avoiding numerical order is important.

Jari