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