Open Stack

You misunderstood.  I was not talking about a new routing protocol.  I was
only talking about employing an existing routing protocol like BGP or OSPF.

Carl


On Fri, May 30, 2014 at 2:06 AM, jcsf <jcsf31459 at gmail.com> wrote:

> Carl,
>
>
>
> A new routing protocol is certainly of great interest.   Are you working
> with IETF or can you share more here?
>
>
>
> WRT:Nova Schedule - There still are requirements for the Schedule to
> taking into consideration network as a resource.   My focus is to figure
> out how to add network capabilities to the Scheduler’s algorithm while
> still maintaining clean separation of concerns between Nova and Neutron.
> We wouldn’t want to get back into the nova-network situation.
>
>
>
> John
>
>
>
>
>
> *From:* Carl Baldwin [mailto:carl at ecbaldwin.net]
> *Sent:* Friday, May 30, 2014 12:05 AM
> *To:* A, Keshava
> *Cc:* jcsf31459 at gmail.com; Armando M.; OpenStack Development Mailing List
> (not for usage questions); Kyle Mestery
>
> *Subject:* Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as
> input any consideration ?
>
>
>
> 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 <keshava.a at hp.com> 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:* jcsf31459 at gmail.com [mailto:jcsf31459 at gmail.com]
> *Sent:* Thursday, May 29, 2014 9:14 AM
> *To:* openstack-dev at lists.openstack.org; 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
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140530/d2aae063/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 30014 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140530/d2aae063/attachment.png>