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

[Mallik Mahalingam <[e-mail]>]

Hi Thomas:

Yes, extending LAA [Locally Administered Address] is something that I discussed with David Black and few others in the past in the context of MAC address exhaustion. I did see some initial activity in IEEE on this, but I didn't get much time to spend on that activity and secondly, with the advent of encapsulation techniques, I am yet to find  if this even a real problem because the MAC address VM sees is hidden from the fabric.

Mallik

----- Original Message -----
From: "Thomas Narten" <[e-mail]>
To: "Andy Dockerty" <[e-mail]>
Cc: "Mallik Mahalingam" <[e-mail]>, "yu jinghai" <[e-mail]>, "Truman Boyes" <[e-mail]>, [e-mail], "Lizhong Jin" <[e-mail]>
Sent: Friday, February 3, 2012 5:45:18 AM
Subject: Re: [dc] 答复: Re:  Requirement for a method to manage mac address in DC

Andy Dockerty <[e-mail]> 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