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

yu.jinghai@zte.com.cn Mon, 13 February 2012 00:53 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 3E2F121F873D for <dc@ietfa.amsl.com>; Sun, 12 Feb 2012 16:53:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -89.968
X-Spam-Level:
X-Spam-Status: No, score=-89.968 tagged_above=-999 required=5 tests=[AWL=-1.640, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_73=0.6, 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 RPZzJknoj-jx for <dc@ietfa.amsl.com>; Sun, 12 Feb 2012 16:53:56 -0800 (PST)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id DBBF521F872D for <dc@ietf.org>; Sun, 12 Feb 2012 16:53:55 -0800 (PST)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690122734555; Mon, 13 Feb 2012 08:26:03 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 17547.122734555; Mon, 13 Feb 2012 08:53:42 +0800 (CST)
Received: (from root@localhost) by mse01.zte.com.cn id q1D0rfgu051546 for <dc@ietf.org>; Mon, 13 Feb 2012 08:53:41 +0800 (GMT-8) (envelope-from yu.jinghai@zte.com.cn)
Message-Id: <201202130053.q1D0rfgu051546@mse01.zte.com.cn>
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q1C7eTA6004656; Sun, 12 Feb 2012 15:40:29 +0800 (GMT-8) (envelope-from yu.jinghai@zte.com.cn)
In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD522A9445A1@EUSAACMS0703.eamcs.ericsson.se>
To: David Allan I <david.i.allan@ericsson.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
From: yu.jinghai@zte.com.cn
Date: Sun, 12 Feb 2012 15:40:15 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-12 15:40:31, Serialize complete at 2012-02-12 15:40:31
Content-Type: multipart/alternative; boundary="=_alternative 002A2C95482579A2_="
X-MAIL: mse01.zte.com.cn q1D0rfgu051546
X-MSS: AUDITRELEASE@mse01.zte.com.cn
Cc: "narten@us.ibm.com" <narten@us.ibm.com>, "dc@ietf.org" <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: Mon, 13 Feb 2012 00:53:57 -0000

Hi David£º
   In an Large L2 network£¬the MAC conflict is likely£¬especially when 
mutil-vlan interwork through supervlan.
in addition£¬the benefit is not only avoiding the MAC conflict but also 
getting more controlling of their DC¡£

fisher.
 

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

David Allan I <david.i.allan@ericsson.com> дÓÚ 2012-02-12 06:27:38:

> Hi Lizhong
> 
> VM MACs are administered, and only require uniqueness within a 
> customer VLAN. So as long as a single customer VLAN does not have 
> multiple administators, there should be no issue.
> 
> IMO a MAC conflict within a single VLAN administration is complete 
> incompetence, not somthing to kill ourselves trying to find a solution 
over!
> 
> my 2 cents
> Dave
> 
> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of 
> Lizhong Jin
> Sent: Thursday, February 02, 2012 6:47 AM
> To: narten@us.ibm.com
> Cc: yu.jinghai@zte.com.cn; dc@ietf.org
> Subject: Re: [dc] Requirement for a method to manage mac address in DC

> Hi Thomas,
> The VMs connected by SPB-M or NVO3/VXLAN/NVGRE will still reside in 
> one L2 network, and the VMs MAC will still conflict if have same MAC
> address. VM MAC confliction could not be mitigated or solved by 
> these mechanism if I understand correctly. 
> 
> Lizhong
> 
> -------------------------------------
> yu.jinghai at zte.com.cn writes:
> 
> 
> >
> >    I wonder whether it is necessary to manage mac address in DC.
> > As you know,VM's mac is randomly generated.
> > The risk of mac conflict is increasing with  the amount of VMs in DC.
> > If there is a method to auto manage and allocate mac address,the
> >    risk maybe avoid. 
> > That method may facilitate the operator to control network easily
> >    and other available benefits. 
> 
> One straightforward way to mitigate C-MAC conflicts is via
> encapsulations, whether through something like SPB-M or
> NVO3/VXLAN/NVGRE.
> 
> Do such approaches not address the problem sufficiently?
> 
> Thomas