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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
