Hi Patrick, that would be great if you would go into details. I am most interested in this as it directly effects our cloud platforms adoption of OpenStack and the subsequent networking blueprint we have designed (trying to get a hold of the networking blueprint Ewan is leading also).
Thank you, Aimon On 2/3/11 10:18 PM, Patrick Ancillotti wrote: > Aimon, > > You're correct of course for simply defining a customer per VLAN as > realistically we wouldn't hit 16M+ customers in any regional area as it > stands today ;) but there are other issues with QinQ at large scale, > especially with Layer 2 domains of the size that we're envisaging in the long > run... many of which we can go into detail if you want? > > For those interested in QinQ : http://en.wikipedia.org/wiki/802.1QinQ > > Thanks, > Patrick > > On 3 Feb 2011, at 23:45, Aimon Bustardo wrote: > >> Hi Patrick, by using 802.1QiQ aren't we increasing the total VLAN count >> to 4096*4096 (16277216) possible VLANS, each with the possibility of >> using the same /8 network? In which case he in table storage of MACs is >> the limiting factor. >> >> >> Aimon >> >> On 2/3/11 8:03 PM, Patrick Ancillotti wrote: >>> Hey Guys, >>> >>> I think Paul may have gotten a bit mixed up between VLAN and CAM tables on >>> switches. The VLAN part of an ethernet frame is 12 bits (0 - 4095) which >>> limits it accordingly. CAM tables however are a limit within switching gear >>> that lists the MAC addresses and their respective source and destination >>> ports. The lower end Cisco switches like the 2960 class switches have a >>> limit of around 8000 MAC addresses, whereas others higher in the stack such >>> as the 4948E class have limits upwards of 55000 MAC addresses, although >>> some vendors have CAM tables in the hundreds of thousands for even their >>> mid range switches. >>> >>> That said, VLAN's are extremely limited, even with QinQ (VLANs within >>> VLANs) when you're talking about 50 000 customers, or even 500 000 >>> customers in the same layer 2 domain, and in many cases using smaller layer >>> 2 domains creates unfortunately small service areas for capacity. >>> >>> For more info: >>> http://en.wikipedia.org/wiki/Virtual_LAN >>> http://en.wikipedia.org/wiki/CAM_Table >>> >>> Thanks, >>> Patrick >>> >>> On 3 Feb 2011, at 07:47, Paul Voccio wrote: >>> >>>> Diego, >>>> >>>> Due to our networking topology, having a vlan per customer isn't really >>>> feasible. Most switches are limited at 4k or 8k or even 32k. With more >>>> customers than these switches can reasonably accommodate, having a single >>>> vlan per customer either limits the portability within a cloud or limits >>>> the scale at which you can build your cloud. Open vSwitch will alleviate >>>> some of this pain, but until we get it in XenServer, we're somewhat stuck >>>> on flat networking. >>>> >>>> Paul >>>> >>>> On 2/3/11 4:20 AM, "Diego Parrilla Santamaría" >>>> <diego.parrilla.santama...@gmail.com> wrote: >>>> >>>>> Hi Monsyne, >>>>> >>>>> it's a very interesting topic and I'm curious about the reason why you >>>>> are using the Flat Networking set up. From the conversations in other >>>>> threads it seems the Service Providers prefer different networking >>>>> approaches: VLAN oriented basically. >>>>> >>>>> Regards >>>>> Diego >>>>> >>>>> - >>>>> Diego Parrilla >>>>> nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog >>>>> +34 649 94 43 29 >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon <mdra...@rackspace.com> >>>>> wrote: >>>>>> I am sorting out some possible implementations for the >>>>>> multi-tenant-accounting blueprint, and the related system-usage-records >>>>>> bp, >>>>>> and I just wanted to run this by anyone interested in such matters. >>>>>> >>>>>> Basically, for multitenant purposes we need to introduce the concept of >>>>>> an >>>>>> 'account' in nova, representing a customer, that basically acts as a >>>>>> label >>>>>> for a group of resources (instances, etc), and for access control (i.e >>>>>> customer a cannot mess w/ customer b's stuff) >>>>>> >>>>>> There was some confusion on how best to implement this, in relation to >>>>>> nova's project concept. Projects are kind of like what we want an >>>>>> account >>>>>> to be, but there are some associations (like one project per network) >>>>>> which >>>>>> are not valid for our flat networking setup. I am kind of >>>>>> straw-polling on >>>>>> which is better here: >>>>>> >>>>>> The options are: >>>>>> 1) Create a new 'account' concept in nova, with an account basically >>>>>> being >>>>>> a subgroup of a project (providers would use a single, default project, >>>>>> with >>>>>> additional projects added if needed for separate brands, or resellers, >>>>>> etc), >>>>>> add in access control per account as well as project, and make sure >>>>>> apis/auth specify account appropriately, have some way for a default >>>>>> account to used (per project) so account doesn't get in the way for >>>>>> non-multitenant users. >>>>>> >>>>>> 2) having account == nova's "project", and changing the network >>>>>> associations, etc so projects can support our model (as well as current >>>>>> models). Support for associating accounts (projects) together for >>>>>> resellers, etc would either be delegated outside of nova or added later >>>>>> (it's not a current requirement). >>>>>> >>>>>> In either case, accounts would be identified by name, which would be an >>>>>> opaque string an outside system/person would assign, and could >>>>>> structure to >>>>>> their needs (ie. for associating accounts with common prefixes, etc) >>>>>> >>>>>> -- >>>>>> >>>>>> -- >>>>>> -Monsyne Dragon >>>>>> work: 210-312-4190 >>>>>> mobile 210-441-0965 >>>>>> google voice: 210-338-0336 >>>>>> >>>>>> >>>>>> >>>>>> Confidentiality Notice: This e-mail message (including any attached or >>>>>> embedded documents) is intended for the exclusive and confidential use >>>>>> of >>>>>> the >>>>>> individual or entity to which this message is addressed, and unless >>>>>> otherwise >>>>>> expressly indicated, is confidential and privileged information of >>>>>> Rackspace. >>>>>> Any dissemination, distribution or copying of the enclosed material is >>>>>> prohibited. >>>>>> If you receive this transmission in error, please notify us immediately >>>>>> by >>>>>> e-mail >>>>>> at ab...@rackspace.com, and delete the original message. >>>>>> Your cooperation is appreciated. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~openstack >>>>>> Post to : openstack@lists.launchpad.net >>>>>> Unsubscribe : https://launchpad.net/~openstack >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~openstack >>>>> Post to : openstack@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~openstack >>>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> Confidentiality Notice: This e-mail message (including any attached or >>>> embedded documents) is intended for the exclusive and confidential use of >>>> the >>>> individual or entity to which this message is addressed, and unless >>>> otherwise >>>> expressly indicated, is confidential and privileged information of >>>> Rackspace. >>>> Any dissemination, distribution or copying of the enclosed material is >>>> prohibited. >>>> If you receive this transmission in error, please notify us immediately by >>>> e-mail >>>> at ab...@rackspace.com, and delete the original message. >>>> Your cooperation is appreciated. >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : openstack@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> -- >> Aimon Bustardo | Morph Labs | +1.310.625.0608 (mobile) | +1.310.437.4898 >> (office) | www.morphlabs.com | ai...@mor.ph >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of the > individual or entity to which this message is addressed, and unless otherwise > expressly indicated, is confidential and privileged information of Rackspace. > Any dissemination, distribution or copying of the enclosed material is > prohibited. > If you receive this transmission in error, please notify us immediately by > e-mail > at ab...@rackspace.com, and delete the original message. > Your cooperation is appreciated. > -- Aimon Bustardo | Morph Labs | +1.310.625.0608 (mobile) | +1.310.437.4898 (office) | www.morphlabs.com | ai...@mor.ph _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
