Re: [dc] Requirement for a method to manage mac address in DC
"Pat Thaler" <pthaler@broadcom.com> Fri, 03 February 2012 18:52 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 EFA5921F85D8 for <dc@ietfa.amsl.com>; Fri, 3 Feb 2012 10:52:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level:
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 8Qh83UeJeIO3 for <dc@ietfa.amsl.com>; Fri, 3 Feb 2012 10:52:13 -0800 (PST)
Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 11CD821F85CE for <dc@ietf.org>; Fri, 3 Feb 2012 10:52:13 -0800 (PST)
Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 03 Feb 2012 11:01:32 -0800
X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A
Received: from SJEXCHCAS02.corp.ad.broadcom.com (10.16.192.37) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 3 Feb 2012 10:51:57 -0800
Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by sjexchcas02.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 3 Feb 2012 10:51:36 -0800
From: Pat Thaler <pthaler@broadcom.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Thread-Topic: [dc] Requirement for a method to manage mac address in DC
Thread-Index: AQHM4byvDvGj89i9O0iaTRM/v/wgl5YqR0YAgAABboCAACiDgIAAEUYA//98MXCAAgQrgP//f8aQ
Date: Fri, 03 Feb 2012 18:51:37 +0000
Message-ID: <EB9B93801780FD4CA165E0FBCB3C3E6701E7ED@SJEXCHMB09.corp.ad.broadcom.com>
References: <CA+E6a66cxJoX3ahEt8E5uQgGoWoP269QXXpozKxN5k7PRw8J3w@mail.gmail.com> <1199197439.684939.1328210516419.JavaMail.root@zimbra-prod-mbox-3.vmware.com> <EB9B93801780FD4CA165E0FBCB3C3E6701D817@SJEXCHMB09.corp.ad.broadcom.com> <CAF4+nEFMuBZ+90AqM2F-ZAbAFWB8Mf76c0_hAEqitV3Z4JmvyA@mail.gmail.com>
In-Reply-To: <CAF4+nEFMuBZ+90AqM2F-ZAbAFWB8Mf76c0_hAEqitV3Z4JmvyA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.9.244.118]
MIME-Version: 1.0
X-WSS-ID: 6332F0833DS21950967-02-01
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Narten <narten@us.ibm.com>, "dc@ietf.org" <dc@ietf.org>, yu jinghai <yu.jinghai@zte.com.cn>, Truman Boyes <tboyes@gmail.com>, Lizhong Jin <lizho.jin@gmail.com>, Mallik Mahalingam <mallik@vmware.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: Fri, 03 Feb 2012 18:52:14 -0000
Donald, Everything has to be somewhere. By your argument, TRILL bridges aren't layer 3 devices either because they aren't peering with the routers in your slides. They are below layer 3 - not working in the layer 3 addressing domain so they are in layer 2. It is just that layer 2 has some sublayers of peered devices. Long before TRILL and PBB, there were Ethernet repeaters which were also layer 2 devices and didn't peer with switches. Provider bridges, provider backbone bridges and TRILL all work at different sublayers in layer 2. I also don't see how that matters to the content of this discussion. Whether one considers TRILL bridges to be at some new layer 2.5 or not or even at layer 3 doesn't matter to the point that they provide isolation between the address spaces of tenants. That isolation only applies if any traffic between those tenants goes through a layer 3 devices that removes the original MAC addresses from the frame. Regards, Pat -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Donald Eastlake Sent: Friday, February 03, 2012 10:18 AM To: Pat Thaler Cc: Thomas Narten; dc@ietf.org; yu jinghai; Truman Boyes; Lizhong Jin; Mallik Mahalingam Subject: Re: [dc] Requirement for a method to manage mac address in DC Hi Pat, Please see below: On Thu, Feb 2, 2012 at 3:01 PM, Pat Thaler <pthaler@broadcom.com> wrote: > 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. Sorry to be nit-picky, but TRILL is not a layer 2 encapsulation. It is provably above layer 2. In my opinion, the best way to tell if a device of type X is at a higher layer, at the same layer, or at a lower layer, than a device of type Y is to look at peering. Generally speaking, layer 2 devices are transparent to TRILL and TRILL switches peer through layer 2 devices, just like layer 3 routers peer with each other through layer 2 devices. On the other hand, TRILL switches look like end stations to and block peering between layer 2 devices, just like layer 3 routers look like end stations and block peering between layer 2 devices. See attached slides. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > 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> > 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 > > > > > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc >
- [dc] 答复: RE: Requirement for a method to manage m… yu.jinghai
- Re: [dc] Requirement for a method to manage mac a… Truman Boyes
- Re: [dc] Requirement for a method to manage mac a… Thomas Narten
- Re: [dc] Requirement for a method to manage mac a… Lizhong Jin
- Re: [dc] Requirement for a method to manage mac a… Thomas Narten
- [dc] Requirement for a method to manage mac addre… yu.jinghai
- [dc] 答复: Requirement for a method to manage mac a… fu.xihua
- Re: [dc] Requirement for a method to manage mac a… Alexander Vainshtein
- Re: [dc] Requirement for a method to manage mac a… Thomas Narten
- Re: [dc] Requirement for a method to manage mac a… Truman Boyes
- Re: [dc] Requirement for a method to manage mac a… Mallik Mahalingam
- Re: [dc] Requirement for a method to manage mac a… Pat Thaler
- [dc] 答复: Re: Requirement for a method to manage m… yu.jinghai
- Re: [dc] 答复: Re: Requirement for a method to mana… Mallik Mahalingam
- Re: [dc] 答复: Re: Requirement for a method to mana… Andy Dockerty
- Re: [dc] 答复: Re: Requirement for a method to mana… Thomas Narten
- Re: [dc] 答复: Re: Requirement for a method to mana… Mallik Mahalingam
- Re: [dc] Requirement for a method to manage mac a… Donald Eastlake
- Re: [dc] Requirement for a method to manage mac a… Pat Thaler
- Re: [dc] Requirement for a method to manage mac a… David Allan I
- Re: [dc] Requirement for a method to manage mac a… Donald Eastlake
- Re: [dc] 答复: Re: Requirement for a method to mana… Joel jaeggli
- Re: [dc] Requirement for a method to manage mac a… AshwoodsmithPeter
- Re: [dc] Requirement for a method to manage mac a… Linda Dunbar
- Re: [dc] Requirement for a method to manage mac a… David Allan I
- Re: [dc] Requirement for a method to manage mac a… Stewart Bryant
- Re: [dc] Requirement for a method to manage mac a… Thomas Narten
- Re: [dc] Requirement for a method to manage mac a… Truman Boyes