neutron

Bug #1458890
Comment #31

Comment 31 for bug 1458890

Revision history for this message

Jian Wen (wenjianhn) wrote on 2015-07-21: Re: [Bug 1458890] Re: Add segment support to Neutron

#31

@Robert, "WIth the network segment construct (which are not intended
to be exposed to end users ), there is also a need for some scheduling
logic around placement and addressing of instances on an appropriate
network segment based on availablity and capacity."
AFAIK, both Nova and ML2 doesn't support the above feature now.

A Related blueprint:
Add availability_zone support for API and DB
https://review.openstack.org/#/c/183369/

On Tue, Jul 21, 2015 at 5:06 AM, Robert Kukura
<email address hidden> wrote:
> This bug was just brought to my attention on IRC, and I haven't read the
> comments yet, but a quick search shows no mention of the existing
> multiprovider extension, or of ML2, which implements multi-segment L2
> networks using this extension. ML2 also implements hierarchical port
> binding, which can dynamically manage segments within a rack or at any
> level of a network hierarchy. Are these potentially relevant? In what
> ways are they inadequate?
>
> --
> You received this bug notification because you are subscribed to
> neutron.
> Matching subscriptions: Quantum
> https://bugs.launchpad.net/bugs/1458890
>
> Title:
> Add segment support to Neutron
>
> Status in neutron:
> Triaged
>
> Bug description:
> This is feedback from the Vancouver OpenStack Summit.
>
> During the large deployment team (Go Daddy, Yahoo!, NeCTAR, CERN,
> Rackspace, HP, BlueBox, among others) meeting, there was a discussion
> of network architectures that we use to deliver Openstack. As we
> talked it became clear that there are a number of challenges around
> networking.
>
> In many cases, our data center networks are architected with a
> differientation between layer 2 and layer 3. Said another way, there
> are distinct network "segments" which are only available to a subset
> of compute hosts. These topolgies are typically necessary to manage
> network resource capacity (IP addresses, broadcast domain size, ARP
> tables, etc.) Network topologies like these are not possible to
> describe with Neutron constructs today.
>
> The traditional solution to this is tunneling and overlay networks
> which makes all networks available everywhere in the data center.
> However, overlay networks represent a large increase in complexity
> that can be very difficult to troubleshoot. For this reason, many
> large deployers are not using overlay networks at all (or only for
> specific use cases like private tenant networks.)
>
> Beacuse Neutron does not have constructs that accurately describe our
> network architectures, we'd like to see the notion of a network
> "segment" in Neutron. A "segment" could mean a L2 domain, IP block
> boundary, or other partition. Operators could use this new construct
> to build accurate models of network topology within Neutron, making it
> much more usable.
>
> Example: The typical use case is L2 segments that are restrained
> to a single rack (or some subnet of compute hosts), but are still part
> of a larger L3 network. In this case, the overall Neutron network
> would describe the L3 network, and the network segments would be used
> to describe the L2 segments.
>
>
> WIth the network segment construct (which are not intended to be exposed to end users ), there is also a need for some scheduling logic around placement and addressing of instances on an appropriate network segment based on availablity and capacity. This also implies a means via API to report IP capacity of networks and segments, so we can filter out segments without capacity and the compute nodes that are tied to those segments.
>
> Example: The end user chooses the Neutron network for their
> instance, which is actually comprised of several lower level network
> segments within Neutron. Scheduling must be done such that the
> network segment chosen for the instance is available to the compute
> node on which the instance is placed. Additionally, the network
> segment that's chosen must have available IP capacity in order for the
> instance to be placed there.
>
>
> Also, the scheduling for resize, migrate, ... should only consider the compute nodes allowed in the "network segment" where the VM is placed.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/neutron/+bug/1458890/+subscriptions

--
Best,

Jian

A Related blueprint:
Add availability_zone support for API and DB
https://review.openstack.org/#/c/183369/

On Tue, Jul 21, 2015 at 5:06 AM, Robert Kukura
<1458890@bugs.launchpad.net> wrote:
> This bug was just brought to my attention on IRC, and I haven't read the
> comments yet, but a quick search shows no mention of the existing
> multiprovider extension, or of ML2, which implements multi-segment L2
> networks using this extension. ML2 also implements hierarchical port
> binding, which can dynamically manage segments within a rack or at any
> level of a network hierarchy. Are these potentially relevant? In what
> ways are they inadequate?
>
> --
> You received this bug notification because you are subscribed to
> neutron.
> Matching subscriptions: Quantum
> https://bugs.launchpad.net/bugs/1458890
>
> Title:
>   Add segment support to Neutron
>
> Status in neutron:
>   Triaged
>
> Bug description:
>   This is feedback from the Vancouver OpenStack Summit.
>
>   During the large deployment team (Go Daddy, Yahoo!, NeCTAR, CERN,
>   Rackspace, HP, BlueBox, among others) meeting, there was a discussion
>   of network architectures that we use to deliver Openstack.  As we
>   talked it became clear that there are a number of challenges around
>   networking.
>
>   In many cases, our data center networks are architected with a
>   differientation between layer 2 and layer 3.  Said another way, there
>   are distinct network "segments" which are only available to a subset
>   of compute hosts.  These topolgies are typically necessary to manage
>   network resource capacity (IP addresses, broadcast domain size, ARP
>   tables, etc.)   Network topologies like these are not possible to
>   describe with Neutron constructs today.
>
>   The traditional solution to this is tunneling and overlay networks
>   which makes all networks available everywhere in the data center.
>   However, overlay networks represent a large increase in complexity
>   that can be very difficult to troubleshoot.  For this reason, many
>   large deployers are not using overlay networks at all (or only for
>   specific use cases like private tenant networks.)
>
>   Beacuse Neutron does not have constructs that accurately describe our
>   network architectures, we'd like to see the notion of a network
>   "segment" in Neutron.  A "segment" could mean a L2 domain, IP block
>   boundary, or other partition.  Operators could use this new construct
>   to build accurate models of network topology within Neutron, making it
>   much more usable.
>
>       Example:  The typical use case is L2 segments that are restrained
>   to a single rack (or some subnet of compute hosts), but are still part
>   of a larger L3 network.  In this case, the overall Neutron network
>   would describe the L3 network, and the network segments would be used
>   to describe the L2 segments.
>
>
>   WIth the network segment construct (which are not intended to be exposed to end users ), there is also a need for some scheduling logic around placement and addressing of instances on an appropriate network segment based on availablity and capacity.  This also implies a means via API to report IP capacity of networks and segments, so we can filter out segments without capacity and the compute nodes that are tied to those segments.
>
>       Example:  The end user chooses the Neutron network for their
>   instance, which is actually comprised of several lower level network
>   segments within Neutron.  Scheduling must be done such that the
>   network segment chosen for the instance is available to the compute
>   node on which the instance is placed.  Additionally, the network
>   segment that's chosen must have available IP capacity in order for the
>   instance to be placed there.
>
>
>   Also, the scheduling for resize, migrate, ... should only consider the compute nodes allowed in the "network segment" where the VM is placed.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/neutron/+bug/1458890/+subscriptions

-- 
Best,

Jian