Hi Carl, As far as I understand Address Scopes, end user’s algorithm will be next: 1. Administrator creates an address scope and associate an IPv6 subnet pool with it. 2. Administrator creates Public shared network’s subnet from this subnet pool. 3. Tenant user creates tenant network from this subnet pool and connect it to Public shared network with router 4. OpenStack advertises prefix to the external interface of the router.
-- With best regards, Vladimir Eremin, Fuel Deployment Engineer, Mirantis, Inc. > On Dec 17, 2015, at 8:21 PM, Carl Baldwin <c...@ecbaldwin.net> wrote: > > On Thu, Dec 17, 2015 at 4:09 PM, Vladimir Eremin <vere...@mirantis.com> wrote: >> Hi Carl, >> >> I’ll fil RFE for sure, thank you for the link to the process ) >> >> So actually, we should announce all SUBNETS we’ve attached to router. >> Otherwise is will not work, because external network router will have no >> idea, where the traffic should be routed back. It is an actual viability >> discriminator: subnets, that doesn’t attached are counting as unviable to >> the external network context. > > The subnets attached to the router which are not controlled by a > subnet pool come straight from the user and there is no validation of > the addresses used, no overlap prevention, nor any other kind of > control. We can't leave it up to tenants to advertise whatever > subnets they want to to the external network. The advertisements must > be limited to subnets allocated to the tenant by the operator of the > cloud with some mechanism for preventing overlap of addresses between > subnets. > > A subnet that has an address scope was allocated from a pool defined > under that scope. We know where the address came from and that it > will not overlap any other subnet in the same scope. > > For subnets that don't meet this criteria, their traffic should not > even be routed out to the external network in the first place let > alone get a route back to the router. The address pools blueprint > covers this too. > >> BTW, could you please point me to the spec for address scopes. > > Sure: https://blueprints.launchpad.net/neutron/+spec/address-scopes > > Carl > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
