IETF Logo Mail Archive

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

Thomas Narten <narten@us.ibm.com> Thu, 02 February 2012 16:00 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 45A9421F85D4 for <dc@ietfa.amsl.com>; Thu, 2 Feb 2012 08:00:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.109
X-Spam-Level:
X-Spam-Status: No, score=-109.109 tagged_above=-999 required=5 tests=[AWL=1.490, 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 KPWX3Ug0dcVk for <dc@ietfa.amsl.com>; Thu, 2 Feb 2012 08:00:07 -0800 (PST)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBD621F85D6 for <dc@ietf.org>; Thu, 2 Feb 2012 08:00:06 -0800 (PST)
Received: from /spool/local by e1.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 11:00:05 -0500
Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e1.ny.us.ibm.com (192.168.1.101) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 2 Feb 2012 10:56:53 -0500
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 73FA66E80AD for <dc@ietf.org>; Thu, 2 Feb 2012 10:56:38 -0500 (EST)
Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q12FtDt7333414 for <dc@ietf.org>; Thu, 2 Feb 2012 10:55:14 -0500
Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q12FtCRJ024066 for <dc@ietf.org>; Thu, 2 Feb 2012 08:55:12 -0700
Received: from cichlid.raleigh.ibm.com (sig-9-65-196-49.mts.ibm.com [9.65.196.49]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q12FtBTO024025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2012 08:55:12 -0700
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 q12Ft7V5009551; Thu, 2 Feb 2012 10:55:08 -0500
Message-Id: <201202021555.q12Ft7V5009551@cichlid.raleigh.ibm.com>
To: Truman Boyes <tboyes@gmail.com>
In-reply-to: <CA+E6a662vDGq6AqcKh2zSUZ0-imRPF8oCa=kFX=WF1rGq8ty1g@mail.gmail.com>
References: <CAH==cJynjN2HxMYh8w+0P0jKVMKWBoX-az=J=EqKX_w4E6GjCw@mail.gmail.com> <201202021509.q12F9em3009367@cichlid.raleigh.ibm.com> <CA+E6a662vDGq6AqcKh2zSUZ0-imRPF8oCa=kFX=WF1rGq8ty1g@mail.gmail.com>
Comments: In-reply-to Truman Boyes <tboyes@gmail.com> message dated "Thu, 02 Feb 2012 10:50:00 -0500."
Date: Thu, 02 Feb 2012 10:55:07 -0500
From: Thomas Narten <narten@us.ibm.com>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12020215-6078-0000-0000-00000763AED3
Cc: yu.jinghai@zte.com.cn, 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 16:00:08 -0000

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

v2.23.0 | Report a Bug | By Email