Re: [Pppext] [rbridge] TRILL, IS-IS, and System ID
Vernon Schryver <vjs@calcite.rhyolite.com> Thu, 02 June 2011 08:15 UTC
Return-Path: <vjs@calcite.rhyolite.com>
X-Original-To: pppext@ietfa.amsl.com
Delivered-To: pppext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D72E068B for <pppext@ietfa.amsl.com>; Thu, 2 Jun 2011 01:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raXVWa4ukEdv for <pppext@ietfa.amsl.com>; Thu, 2 Jun 2011 01:15:55 -0700 (PDT)
Received: from calcite.rhyolite.com (calcite.rhyolite.com [IPv6:2001:4978:230::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0A3E06B6 for <pppext@ietf.org>; Thu, 2 Jun 2011 01:15:53 -0700 (PDT)
Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.14.4/8.14.4) with ESMTP id p528Fex5029578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) env-from <vjs@calcite.rhyolite.com>; Thu, 2 Jun 2011 08:15:41 GMT
Received: (from vjs@localhost) by calcite.rhyolite.com (8.14.4/8.14.4/Submit) id p528FdXL029577; Thu, 2 Jun 2011 08:15:39 GMT
Date: Thu, 02 Jun 2011 08:15:39 +0000
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <201106020815.p528FdXL029577@calcite.rhyolite.com>
To: pppext@ietf.org
X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist
Cc: rbridge@postel.org, ginsberg@cisco.com, stbryant@cisco.com
Subject: Re: [Pppext] [rbridge] TRILL, IS-IS, and System ID
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jun 2011 08:15:56 -0000
I don't understand the second application of the Birthday Paradox in http://tools.ietf.org/html/draft-simpson-isis-ppp-unique-01 It is true that the probability that at least 2 of N random, uniformly distributed selections from the set of M numbers from 1 to M are the same is greater than 0.5 when N is greater than the square root of M. That justifies the first application of the Paradox in section 2. I don't understand the reasoning behind the claim in section 3: ] The probability ] of conflict is defined by a birthday attack of the order N/2**16; ] where N is the number of systems in the same IS-IS area. ] ] Also, many companies reuse the same MAC for different product lines, ] or different speeds or types of media. It is true that for a single OUI, a vendor can assigned 2**24 distinct non-multicast MAC addresses. My problems are that: - The square root of 2**24 is 4096 instead of 2**16. Where did 2**16 come from? - Companies making more than 2**24 devices have always been able to get additional OUIs. - The least significant 24 bits of the MAC addresses for a given OUI seen in a given network are often not uniformly distributed, which makes the Birthday Paradox inapplicable. If you buy many devices made by a single vendor, you might well get 'runs' of consecutive addresses. That can significantly reduce the likelihood of collision. - During the approximately dozen years that I was the MAC address czar for a computer vendor, I was aware of one or two cases of duplicate MAC addresses. They were cases where the people on the factory floor messed up and used re-used blocks of numbers that I had released instead of asking for another block. The resulting distributions of duplicate addresses going out the factory door or arriving at customer sites were not at all uniform, again making the Birthday Paradox the wrong model. - After decades of IEEE 48-bit MAC address assignments, it must be possible to measure the probability of 48-bit IEEE MAC address collisions. Handwaving about vendors too lazy to get additional OUIs and talk about broken, 1990 vintage Ethernet-FDDI bridges cannot justify solving a problem that can now be measured and found serious, non-existent, or somewhere between. It is necessary to collect 48-bit IEEE addresses and look for duplicates. If the probability of duplicate MAC addresses in an IS-IS area using TRILL is enough smaller than probability of other failures, then the problem 'MUST NOT' be solved. Vernon Schryver vjs@rhyolite.com
- [Pppext] TRILL, IS-IS, and System ID James Carlson
- Re: [Pppext] TRILL, IS-IS, and System ID Donald Eastlake
- Re: [Pppext] TRILL, IS-IS, and System ID William Allen Simpson
- Re: [Pppext] TRILL, IS-IS, and System ID Stewart Bryant
- Re: [Pppext] TRILL, IS-IS, and System ID Stewart Bryant
- Re: [Pppext] TRILL, IS-IS, and System ID James Carlson
- Re: [Pppext] TRILL, IS-IS, and System ID Stewart Bryant
- Re: [Pppext] TRILL, IS-IS, and System ID James Carlson
- Re: [Pppext] TRILL, IS-IS, and System ID Stewart Bryant
- Re: [Pppext] TRILL, IS-IS, and System ID William Allen Simpson
- Re: [Pppext] TRILL, IS-IS, and System ID James Carlson
- Re: [Pppext] [rbridge] TRILL, IS-IS, and System ID Les Ginsberg (ginsberg)
- Re: [Pppext] TRILL, IS-IS, and System ID William Allen Simpson
- Re: [Pppext] [rbridge] TRILL, IS-IS, and System ID William Allen Simpson
- Re: [Pppext] [rbridge] TRILL, IS-IS, and System ID Les Ginsberg (ginsberg)
- Re: [Pppext] [rbridge] TRILL, IS-IS, and System ID Vernon Schryver
- Re: [Pppext] [rbridge] TRILL, IS-IS, and System ID Vernon Schryver
- Re: [Pppext] TRILL, IS-IS, and System ID Stewart Bryant
- Re: [Pppext] TRILL, IS-IS, and System ID James Carlson
- Re: [Pppext] TRILL, IS-IS, and System ID Jari Arkko
- Re: [Pppext] [Isis-wg] TRILL, IS-IS, and System ID Christian Hopps