Re: [dc] 答复: Re: Requirement for a method to manage mac address in DC

Thomas Narten <narten@us.ibm.com> Fri, 03 February 2012 13:46 UTC

Return-Path: <narten@us.ibm.com>
X-Original-To: dc@ietfa.amsl.com
Delivered-To: dc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4321F8610 for <dc@ietfa.amsl.com>; Fri, 3 Feb 2012 05:46:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.526
X-Spam-Level:
X-Spam-Status: No, score=-109.526 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8x2=0.246, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWi8CnoufAUa for <dc@ietfa.amsl.com>; Fri, 3 Feb 2012 05:46:45 -0800 (PST)
Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id E2EB221F8621 for <dc@ietf.org>; Fri, 3 Feb 2012 05:46:44 -0800 (PST)
Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <dc@ietf.org> from <narten@us.ibm.com>; Fri, 3 Feb 2012 08:46:43 -0500
Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 3 Feb 2012 08:46:41 -0500
Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 2E8926E804D for <dc@ietf.org>; Fri, 3 Feb 2012 08:46:41 -0500 (EST)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q13DjORG2998428 for <dc@ietf.org>; Fri, 3 Feb 2012 08:45:24 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q13DjMJj027467 for <dc@ietf.org>; Fri, 3 Feb 2012 08:45:23 -0500
Received: from cichlid.raleigh.ibm.com (sig-9-76-142-174.mts.ibm.com [9.76.142.174]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q13DjKLd027261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Feb 2012 08:45:21 -0500
Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q13DjISB004903; Fri, 3 Feb 2012 08:45:19 -0500
Message-Id: <201202031345.q13DjISB004903@cichlid.raleigh.ibm.com>
To: Andy Dockerty <andyd@juniper.net>
In-reply-to: <008A37CB-C9B0-46FD-8190-C5C8BA6BD6BC@juniper.net>
References: <1495751257.716820.1328253325254.JavaMail.root@zimbra-prod-mbox-3.vmware.com> <008A37CB-C9B0-46FD-8190-C5C8BA6BD6BC@juniper.net>
Comments: In-reply-to Andy Dockerty <andyd@juniper.net> message dated "Fri, 03 Feb 2012 18:26:23 +1100."
Date: Fri, 03 Feb 2012 08:45:18 -0500
From: Thomas Narten <narten@us.ibm.com>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12020313-7182-0000-0000-000000AAE445
Cc: yu jinghai <yu.jinghai@zte.com.cn>, dc@ietf.org, Truman Boyes <tboyes@gmail.com>, Mallik Mahalingam <mallik@vmware.com>, Lizhong Jin <lizho.jin@gmail.com>
Subject: Re: [dc] 答复: Re: Requirement for a method to manage mac address in DC
X-BeenThere: dc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Data Center Mailing List <dc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dc>, <mailto:dc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dc>
List-Post: <mailto:dc@ietf.org>
List-Help: <mailto:dc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dc>, <mailto:dc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2012 13:46:45 -0000

Andy Dockerty <andyd@juniper.net> writes:

> I am aware that there are concerns about "OUI address space", that
> not withstanding, the creation of an OUI space analogous with
> RFC1918 address space, coupled with the extension of OUI
> registration may offer an option to ensure organizational or locally
> significant MAC uniqueness....

RFC 1918 space is shared in the sense that anyone can use it as they
see fit. Different organizations use the same space, so if you
merge/join to organizations you risk having collisions. Even within an
organization, assignments must be done in such a way as to avoid
collisionss. RFC1918 space is defined to have local scope only, i.e.,
not be globally unique.

Seems to me that MAC addrs satisfy that property already, via
appropriate use of the "local" bit.

So when you suggest creation of an "OUI space analagous with RFC1918
space", do we not already have that?

Thomas