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

"Pat Thaler" <pthaler@broadcom.com> Thu, 02 February 2012 20:03 UTC

Return-Path: <pthaler@broadcom.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 C631721F864F for <dc@ietfa.amsl.com>; Thu, 2 Feb 2012 12:03:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.448
X-Spam-Level:
X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 I2lqIF46Rdei for <dc@ietfa.amsl.com>; Thu, 2 Feb 2012 12:03:45 -0800 (PST)
Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id A2D9F21F8624 for <dc@ietf.org>; Thu, 2 Feb 2012 12:03:45 -0800 (PST)
Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 02 Feb 2012 12:09:39 -0800
X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201
Received: from SJEXCHCAS01.corp.ad.broadcom.com (10.16.192.31) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Thu, 2 Feb 2012 12:01:14 -0800
Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by sjexchcas01.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Thu, 2 Feb 2012 12:01:14 -0800
From: Pat Thaler <pthaler@broadcom.com>
To: Mallik Mahalingam <mallik@vmware.com>, Truman Boyes <tboyes@gmail.com>
Thread-Topic: [dc] Requirement for a method to manage mac address in DC
Thread-Index: AQHM4byvDvGj89i9O0iaTRM/v/wgl5YqR0YAgAABboCAACiDgIAAEUYA//98MXA=
Date: Thu, 02 Feb 2012 20:01:13 +0000
Message-ID: <EB9B93801780FD4CA165E0FBCB3C3E6701D817@SJEXCHMB09.corp.ad.broadcom.com>
References: <CA+E6a66cxJoX3ahEt8E5uQgGoWoP269QXXpozKxN5k7PRw8J3w@mail.gmail.com> <1199197439.684939.1328210516419.JavaMail.root@zimbra-prod-mbox-3.vmware.com>
In-Reply-To: <1199197439.684939.1328210516419.JavaMail.root@zimbra-prod-mbox-3.vmware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.9.244.85]
MIME-Version: 1.0
X-WSS-ID: 6334320950419595025-01-01
Content-Type: multipart/alternative; boundary="_000_EB9B93801780FD4CA165E0FBCB3C3E6701D817SJEXCHMB09corpadb_"
Cc: Thomas Narten <narten@us.ibm.com>, yu jinghai <yu.jinghai@zte.com.cn>, "dc@ietf.org" <dc@ietf.org>, Lizhong Jin <lizho.jin@gmail.com>
Subject: Re: [dc] 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: Thu, 02 Feb 2012 20:03:46 -0000

Some work on managing MAC addresses of virtual devices in a Data Center may be worthwhile, though it isn’t clear to me whether such work would better fit in IETF or IEEE 802.

When virtualization ecosystem management entities are handing out addresses, there can be data centers with multiple such entities and one can’t count on them to coordinate their use of the address space. While each of them won’t hand out duplicate addresses to the set of VMs they manage, the addresses may be duplicated for VMs managed by different management entities. Sometimes this can be dealt with by manual assignment of ranges, but in a data center with multiple tenants, the tenants are unlikely to coordinate that. The potential duplicate addresses can in some cases be dealt with by mechanisms that keep the address space of the management entities separate such as: IVL (or other mechanisms that concatenate VLAN and MAC address for bridge learning) or layer 2 (e.g. PBB and TRILL) or layer 3 encapsulations.  But there could be some areas where a protocol for coordinating assignments to avoid duplication would help.
There have been discussions in the IEEE RAC about concerns regarding the use of MAC addresses from the global MAC address space for virtual devices; issues include potential for exhausting the global address space and that an address that looks like a global address is being used as a local address. Half the MAC address space is for local addresses, but there aren’t standardized mechanisms for managing addresses in that space.

<IEEE 802 Vice-Chair hat on> If work was done in the IETF on MAC address management/assignment, there should be close liaison with IEEE 802 and the IEEE RAC.

Pat

From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Mallik Mahalingam
Sent: Thursday, February 02, 2012 11:22 AM
To: Truman Boyes
Cc: Thomas Narten; yu jinghai; dc@ietf.org; Lizhong Jin
Subject: Re: [dc] Requirement for a method to manage mac address in DC

In a virtualized environment MAC addresses are not totally random generated.
There is some notion of Management-Entity(s)/controller(s) allocating the
MAC addresses for VMs and ensures that it does not assign the same MAC
address to two different VMs and this work only within the scope of that
management/controller administration. There are some exceptions of course
(a) MAC address exhaustion under a given OUI category  (b) manual
copy/cloning of VMs and powering on them using standalone management
entities (c) VMs that use MAC address override for legitimate reasons
[because else things like licensing software breaks].  There are some
mechanisms in place to address (a), but (b) and (c) requires co-operation at
the management-entity/controllers.

Mallik
________________________________
From: "Truman Boyes" <tboyes@gmail.com<mailto:tboyes@gmail.com>>
To: "Thomas Narten" <narten@us.ibm.com<mailto:narten@us.ibm.com>>
Cc: "yu jinghai" <yu.jinghai@zte.com.cn<mailto:yu.jinghai@zte.com.cn>>, dc@ietf.org<mailto:dc@ietf.org>, "Lizhong Jin" <lizho.jin@gmail.com<mailto:lizho.jin@gmail.com>>
Sent: Thursday, February 2, 2012 10:20:07 AM
Subject: Re: [dc] Requirement for a method to manage mac address in DC


On Thu, Feb 2, 2012 at 10:55 AM, Thomas Narten <narten@us.ibm.com<mailto:narten@us.ibm.com>> wrote:
Truman Boyes <tboyes@gmail.com<mailto:tboyes@gmail.com>> writes:

> The L2 separation between multiple tenants is true in most circumstances in
> DCs, but in commodity computing (ie. VPS, low cost dedicated servers, or
> co-location) there is a concern on IPv4 address exhaustion or waste, so
> machines/instances are grouped on single L2 segments. It is possible to
> have virtual MAC overlaps on these segments. Is this something that this
> group wishes to evaluate options to solve?
IMO, this is putting the cart before the horse.

Can we first get a sense for how big a problem this is in practice and
whether existing mitigation approaches are not sufficient?

I.e., is this a real problem causing significant pain today, or are
their other bigger "pain points" that we should be looking at?

Thomas

In the VPS/VM world,  I would say it's not a significant issue because there are single entities (Organizations) that manage the MAC addresses. Typically software would just increment the virtual MACs, and this does not require external protocols to ensure uniqueness. If there are many provisioning systems that manage VMs on the same network segment then they will need to keep their database in sync.

--
--truman


_______________________________________________
dc mailing list
dc@ietf.org<mailto:dc@ietf.org>
https://www.ietf.org/mailman/listinfo/dc