yahoo-eng-team team mailing list archive

[Ryan Tidwell <1830240@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Currently, neutron enforces that on any given network, all subnets of
the same address family (IPv4/6) must be all allocated from the same
subnet pool. This restriction was put in place before the concept of
address scopes existed, and was meant to help enforce the uniqueness of
subnet CIDR's associated with a network.

When address scopes are used, we really only need to enforce that all
subnets on a given network belong to the same address scope for each
address family. This unlocks use cases for operators that allow them to
build different subnet pools to be used with specific subnet service
types and allocate them from different pools.

For example:

Suppose an operator has different blocks of addresses for floating IP's
and FIP agent gateway ports. This change would allow the operator to
manage the FIP range from one subnet pool and FIP gateway addresses from
another pool, which is something they can't do today because neutron
only allows subnets to be placed on the network if they are allocated
from the same pool.

Proposed Changes:

- When address scopes are not used neutron behaves as it currently does,
enforcing all subnets of the same address family on the same network be
allocated from the same subnet pool

- When address scopes are used the "same subnet pool" constraint is
relaxed, and the check made is that all subnets belong to the same
address scope

- Logic will be added to subnet pool updates to block movement between
address scopes when moving the pool would cause one or more subnets
allocated from the pool to violate the "same address scope" constraint.

- Logic will be added to the subnet "off-board" case to block the
operation when "off-boarding" the requested subnet(s) causes a violation
of the "same address scope" constraint.

As an alternative implementation, introducing address_scope_v4 and
address_scope_v6 fields to the network resource would also give us a way
of associating networks with the address scope. Since these constraints
need to be enforced on the network, perhaps networks need to be aware of
address scopes.

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1830240

Title:
  [RFE] Allow subnets from different subnet pools on the same network
  when using address scopes

Status in neutron:
  New

Bug description:
  Currently, neutron enforces that on any given network, all subnets of
  the same address family (IPv4/6) must be all allocated from the same
  subnet pool. This restriction was put in place before the concept of
  address scopes existed, and was meant to help enforce the uniqueness
  of subnet CIDR's associated with a network.

  When address scopes are used, we really only need to enforce that all
  subnets on a given network belong to the same address scope for each
  address family. This unlocks use cases for operators that allow them
  to build different subnet pools to be used with specific subnet
  service types and allocate them from different pools.

  For example:

  Suppose an operator has different blocks of addresses for floating
  IP's and FIP agent gateway ports. This change would allow the operator
  to manage the FIP range from one subnet pool and FIP gateway addresses
  from another pool, which is something they can't do today because
  neutron only allows subnets to be placed on the network if they are
  allocated from the same pool.

  Proposed Changes:

  - When address scopes are not used neutron behaves as it currently
  does, enforcing all subnets of the same address family on the same
  network be allocated from the same subnet pool

  - When address scopes are used the "same subnet pool" constraint is
  relaxed, and the check made is that all subnets belong to the same
  address scope

  - Logic will be added to subnet pool updates to block movement between
  address scopes when moving the pool would cause one or more subnets
  allocated from the pool to violate the "same address scope"
  constraint.

  - Logic will be added to the subnet "off-board" case to block the
  operation when "off-boarding" the requested subnet(s) causes a
  violation of the "same address scope" constraint.

  As an alternative implementation, introducing address_scope_v4 and
  address_scope_v6 fields to the network resource would also give us a
  way of associating networks with the address scope. Since these
  constraints need to be enforced on the network, perhaps networks need
  to be aware of address scopes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1830240/+subscriptions