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

[AshwoodsmithPeter <[e-mail]>]

This numbering of layers was useful way back when but its starting to get worn out and confusing. Probably simpler if people just name the layer by layer encapsulations they are talking about especially in a technical discussion.

Eg:

MACinVXLANinIPV4inMAC
MACinTRILLinMAC
MACinMAC
MACinMPLSinMPLS
Yada yada ..

Peter


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Donald Eastlake
Sent: Saturday, February 04, 2012 2:15 PM
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,

On Fri, Feb 3, 2012 at 1:51 PM, Pat Thaler <[e-mail]> wrote:
> Donald,
>
> Everything has to be somewhere.

"remember: no matter where you go... there you are" The Adventures of
Buckaroo Banzai Across the 8th Dimension...

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

Yes. Exactly the same form of proof that proves that TRILL switches
are above layer 2 also proves that TRILL switches are below layer 3.

> not working in the layer 3 addressing domain so they are in layer 2.

No. TRILL Data packets are routed by TRILL switches using the TRILL
nickname address space. I do not know what the basis is of your
assertion that TRILL nicknames are not layer 3 addresses but I don't
believe they are layer 2 addresses.

> 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 disagree the TRILL is a sublayer of Layer 2. It is fairly easy to
order devices as to relative layer based on peering although, like
with anything else, if you apply a sufficiently strong magnifying
glass you can find some odd glitches and corner case:

Repeater < Prov. Bridge < Cust. Bridge < TRILL Switch < L3 Router

In my opinion, the arguments that TRILL is in Layer 2 or Layer 3 are
in exact equipoise. I do not agree that anything on or inside the
border betwen Layer 2 and Layer 3 should be classified as 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

TRILL routers

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

I agree that it does not matter much to the point under discussion. I
just didn't want people to be confused about the true nature of TRILL
switches.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> 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