Hi,
I just want to discuss a solution to solve MAC address scalability
issues in cloud data centres.
Just as I discussed with Mikael Abrahamsson, MAC address scalability
issues is not serious in internet data centres (IDC), but it is serious in
cloud data centres who providing (virtual) private data centres (vPDC) for
different tenants.
Due to limitations such as legal regulation, cultural barriers or
skilled experts distribution, one company (i.e. a tenant of vPDC service
provisioned by cloud service provider) have to distribute its staffs into many
geographically dispersed sites, those staffs get services from a data centre
near their office site. The cloud service provider provide vPDC service to
tenant, each tenant has its separate private IP network across sites(data
centres) and the IP network may overlap with another tenant's IP network, the
cloud service provider isolate those tenants through underlay, layer 2
technologies can be used as underlay, Layer3 NAT is another feasible but costly
and more complicated option.
It is very skilled and complicated for a tenant to design IP subnet per
vPDC site. The underlay will have to touch millions host addresses (IP
addresses or MAC addresses), but current and mid-term future hardware cannot
support that.
We need focus the issue, I support to adopt SARP as WG draft, at least
SARP is one try to solve that issue.
Best regards,
Hewen
-----Original Message-----
From: George, Wes [mailto:wesley.geo...@twcable.com]
Sent: Tuesday, October 08, 2013 10:20 PM
To: Zhenghewen; 'Thomas Narten'; 'Suresh Krishnan'
Cc: 'Internet Area'
Subject: RE: [Int-area] Call for adoption of draft-nachum-sarp-06.txt
> From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On
> Behalf Of Zhenghewen
> Hi Thomas,
>
> In real world, some operator has 80 data centres in the
> scope with the diameter of 1000KM, each data centre has average 1,500
> racks, each rack has average 20 servers, each servers has 20 VMs. That
> means that there are up to 48millions MAC entries. Even only 20% VMs
> generate traffic outside from local data centres, there are about 10M
> MAC entries.
[snip]
> Now, as we see, current FDB tables seem small, especially for cloud
> data centre. Usually high-speed switch or router only has limited table
> size, for example 128K or 512K MAC entries.
>
[snip]
> Some solutions to solve the issue will be valuable
[WEG] This is all very interesting theoretical math, but all it says to me is
what we've known for years - L2 MAC domains don't scale infinitely - whatever
the hardware capabilities, someone will come up with a theoretical case that
exceeds it by many orders of magnitude. Several of us have said that the
already extant solution is to shrink the L2 domain so that the number of MACs
necessary to track is much smaller. Yes, RFC 6820 discusses some problems with
that when it comes to VM mobility, but I'd argue that there are other solutions
to those problems that start looking increasingly attractive at this sort of
scale, including heavier use of DNS that is updated when a VM IP changes, etc.
You need to explain why your proposed solution is less complicated than simply
designing your VM infrastructure to be flexible enough that subnet changes
don't break things.
Wes George
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the sender
immediately and permanently delete the original and any copy of this E-mail and
any printout.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
