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

yu.jinghai@zte.com.cn Fri, 03 February 2012 06:11 UTC

Return-Path: <yu.jinghai@zte.com.cn>
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 0D95A21F858E for <dc@ietfa.amsl.com>; Thu, 2 Feb 2012 22:11:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -91.608
X-Spam-Level:
X-Spam-Status: No, score=-91.608 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MSGID_FROM_MTA_HEADER=0.803, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 DYhhVwlIkJEu for <dc@ietfa.amsl.com>; Thu, 2 Feb 2012 22:11:17 -0800 (PST)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8C121F8595 for <dc@ietf.org>; Thu, 2 Feb 2012 22:11:15 -0800 (PST)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690122734555; Fri, 3 Feb 2012 13:44:42 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 19199.122734555; Fri, 3 Feb 2012 14:10:47 +0800 (CST)
Received: (from root@localhost) by mse01.zte.com.cn id q136B1Bg074377 for <dc@ietf.org>; Fri, 3 Feb 2012 14:11:01 +0800 (GMT-8) (envelope-from yu.jinghai@zte.com.cn)
Message-Id: <201202030611.q136B1Bg074377@mse01.zte.com.cn>
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q1368nce070985; Fri, 3 Feb 2012 14:08:50 +0800 (GMT-8) (envelope-from yu.jinghai@zte.com.cn)
In-Reply-To: <1199197439.684939.1328210516419.JavaMail.root@zimbra-prod-mbox-3.vmware.com>
To: Mallik Mahalingam <mallik@vmware.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
From: yu.jinghai@zte.com.cn
Date: Fri, 03 Feb 2012 14:08:39 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-03 14:08:51, Serialize complete at 2012-02-03 14:08:51
Content-Type: multipart/alternative; boundary="=_alternative 0021C69948257999_="
X-MAIL: mse01.zte.com.cn q136B1Bg074377
X-MSS: AUDITRELEASE@mse01.zte.com.cn
Cc: Thomas Narten <narten@us.ibm.com>, Truman Boyes <tboyes@gmail.com>, dc@ietf.org, Lizhong Jin <lizho.jin@gmail.com>
Subject: [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 06:11:19 -0000

Hi Mallik:
        I learned about that Xen generate MAC address by an algorithm base 
the timestamp.
I don't know well about other virtualization platform.
        As you say that:  
> 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.
 
why does it work only within the scope of that management/controller 
administration?
How do VMs get the MAC addresses?
Could you please elaborate?


>-----------------------------------------<
¨q¡Ð¨r¡è¡¡¡¡¡¡¡¡¡¡     Innovation change 
                          the world 
¨q¨q ¡Ð¨r        ¡ñ¨q¡ð¨r¡¡ 
¨t ----¨s       /¨€¡Å¨€\ ¡¡
~~~~~~~~~~~~~~~~~¡Ç~~¡Ç~~~~~~~~~~~~~~~~~
           My nickname: Fisher Yu
>----------------------------------------<

Mallik Mahalingam <mallik@vmware.com> дÓÚ 2012-02-03 03:21:56:

> 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>
> To: "Thomas Narten" <narten@us.ibm.com>
> Cc: "yu jinghai" <yu.jinghai@zte.com.cn>, dc@ietf.org, "Lizhong Jin"
> <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> 
wrote:
> Truman Boyes <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
> https://www.ietf.org/mailman/listinfo/dc