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

["Pat Thaler" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Donald Eastlake
Sent: Friday, February 03, 2012 10:18 AM
To: Pat Thaler
Cc: Thomas Narten; [e-mail]; 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 <[e-mail]> 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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

>  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: [e-mail] [mailto:[e-mail]] On Behalf Of Mallik
> Mahalingam
> Sent: Thursday, February 02, 2012 11:22 AM
> To: Truman Boyes
> Cc: Thomas Narten; yu jinghai; [e-mail]; 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" <[e-mail]>
> To: "Thomas Narten" <[e-mail]>
> Cc: "yu jinghai" <[e-mail]>, [e-mail], "Lizhong Jin"
> <[e-mail]>
> 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 <[e-mail]> wrote:
>
> Truman Boyes <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dc
>
>
>
>
> _______________________________________________
> dc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dc
>