Keshava, How much of a problem is routing prefix fragmentation for you? Fragmentation causes routing table bloat and may reduce the performance of the routing table. It also increases the amount of information traded by the routing protocol. Which aspect(s) is (are) affecting you? Can you quantify this effect?
A major motivation for my interest in employing a dynamic routing protocol within a datacenter is to enable IP mobility so that I don't need to worry about doing things like scheduling instances based on their IP addresses. Also, I believe that it can make floating ips more "floaty" so that they can cross network boundaries without having to statically configure routers. To get this mobility, it seems inevitable to accept the fragmentation in the routing prefixes. This level of fragmentation would be contained to a well-defined scope, like within a datacenter. Is it your opinion that trading off fragmentation for mobility a bad trade-off? Maybe it depends on the capabilities of the TOR switches and routers that you have. Maybe others can chime in here. Carl On Wed, May 28, 2014 at 10:11 PM, A, Keshava <[email protected]> wrote: > Hi, > > Motivation behind this requirement is “ to achieve VM prefix aggregation > using routing protocol ( BGP/OSPF)”. > > So that prefix advertised from cloud to upstream will be aggregated. > > > > I do not have idea how the current scheduler is implemented. > > But schedule to maintain some kind of the ‘Network to Node mapping to VM” > .. > > Based on that mapping to if any new VM getting hosted to give prefix in > those Nodes based one input preference. > > > > It will be great help us from routing side if this is available in the > infrastructure. > > I am available for review/technical discussion/meeting. > > > > > > Thanks & regards, > > Keshava.A > > > > *From:* [email protected] [mailto:[email protected]] > *Sent:* Thursday, May 29, 2014 9:14 AM > *To:* [email protected]; Carl Baldwin; Kyle Mestery; > OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as > input any consideration ? > > > > Hi keshava, > > > > This is an area that I am interested in. I'd be happy to collaborate > with you on a blueprint. This would require enhancements to the > scheduler as you suggested. > > > > There are a number of uses cases for this. > > > > > > John. > > > > Sent from my smartphone. > > *From: *A, Keshava > > *Sent: *Tuesday, May 27, 2014 10:58 AM > > *To: *Carl Baldwin; Kyle Mestery; OpenStack Development Mailing List (not > for usage questions) > > *Reply To: *OpenStack Development Mailing List (not for usage questions) > > *Subject: *[openstack-dev] [neutron][L3] VM Scheduling v/s Network as > input any consideration ? > > > > Hi, > > I have one of the basic question about the Nova Scheduler in the following > below scenario. > > Whenever a new VM to be hosted is there any consideration of network > attributes ? > > Example let us say all the VMs with 10.1.x is under TOR-1, and 20.1.xy are > under TOR-2. > > A new CN nodes is inserted under TOR-2 and at same time a new tenant VM > needs to be hosted for 10.1.xa network. > > > > Then is it possible to mandate the new VM(10.1.xa) to hosted under TOR-1 > instead of it got scheduled under TOR-2 ( where there CN-23 is completely > free from resource perspective ) ? > > This is required to achieve prefix/route aggregation and to avoid network > broadcast (incase if they are scattered across different TOR/Switch) ? > > > > > > > > > > Thanks & regards, > > Keshava.A > > > > > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
