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

Thomas Narten <narten@us.ibm.com> Thu, 02 February 2012 15:11 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 B1B8121F85A1 for <dc@ietfa.amsl.com>; Thu, 2 Feb 2012 07:11:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.054
X-Spam-Level:
X-Spam-Status: No, score=-109.054 tagged_above=-999 required=5 tests=[AWL=1.545, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 LiZ6rOMC+BQi for <dc@ietfa.amsl.com>; Thu, 2 Feb 2012 07:11:14 -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 0F75121F8598 for <dc@ietf.org>; Thu, 2 Feb 2012 07:11:08 -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>; Thu, 2 Feb 2012 10:11:08 -0500
Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 2 Feb 2012 10:11:05 -0500
Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 1831A38C807D for <dc@ietf.org>; Thu, 2 Feb 2012 10:11:03 -0500 (EST)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q12F9jsx269550 for <dc@ietf.org>; Thu, 2 Feb 2012 10:09:46 -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 q12F9id7030740 for <dc@ietf.org>; Thu, 2 Feb 2012 10:09:45 -0500
Received: from cichlid.raleigh.ibm.com (sig-9-65-196-49.mts.ibm.com [9.65.196.49]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q12F9hn2030590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2012 10:09:43 -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 q12F9em3009367; Thu, 2 Feb 2012 10:09:40 -0500
Message-Id: <201202021509.q12F9em3009367@cichlid.raleigh.ibm.com>
To: Lizhong Jin <lizho.jin@gmail.com>
In-reply-to: <CAH==cJynjN2HxMYh8w+0P0jKVMKWBoX-az=J=EqKX_w4E6GjCw@mail.gmail.com>
References: <CAH==cJynjN2HxMYh8w+0P0jKVMKWBoX-az=J=EqKX_w4E6GjCw@mail.gmail.com>
Comments: In-reply-to Lizhong Jin <lizho.jin@gmail.com> message dated "Thu, 02 Feb 2012 22:47:06 +0800."
Date: Thu, 02 Feb 2012 10:09:40 -0500
From: Thomas Narten <narten@us.ibm.com>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12020215-7182-0000-0000-000000A5E12E
Cc: yu.jinghai@zte.com.cn, dc@ietf.org
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 15:11:14 -0000

Lizhong Jin <lizho.jin@gmail.com> writes:

> The VMs connected by SPB-M or NVO3/VXLAN/NVGRE will still reside in one L2
> network,

But those L2 networks are generally scoped to only include the VMs of one
tenant/customer. So a) the number of VMs is smallish (not the entire
data center), and b) any collisions will have been caused by the tenant
and only impact the tenant (not other tenants).

I'm not saying address collisions are  never a problem, but the above
reduces the frequency and limits the impact.

> 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.

Overlay approaches hide client/customer MACs inside a second, outer
header. Thus, if two different tenants use the same VM MAC address,
that collision is not visible within the datacenter, because the data
center network only uses the addresses in the outer header.

Thomas