Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

2015-12-21 Thread Carl Baldwin 
On Fri, Dec 18, 2015 at 12:54 PM, Vladimir Eremin  wrote:
> 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.

Yes, this sounds like the right way to do it.  As long as we implement
step 4 to be address scope aware, what you describe here will work.

There is some flexibility to attach multiple subnet pools to the same
address scope.  This would allow a particular tenant to have exclusive
access to a pool under the right scope.

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

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

2015-12-18 Thread Vladimir Eremin 
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  wrote:
> 
> On Thu, Dec 17, 2015 at 4:09 PM, Vladimir Eremin  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

[openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

2015-12-17 Thread Vladimir Eremin 
Hi

For now, when end user is creating IPv6-enabled tenant network and attaching it 
to the virtual router, there is only way to set up external infrastructure to 
put traffic back to the router is using DHCPv6 PD[1], unfortunately, it’s not 
working at all[2]. Other methods like implementing BGP is still in development.

BTW, in IPv6 Router Advertisements we have an option called Route Information 
Option, RA-RIO[3] to advertise more specific routes from gateway. We could 
easily append a section like next one to advertise tenant prefix 
2001:db8:1::/64 to public network. And if provider network router outside 
OpenStack will be configured to accept these.

interface qg- {
AdvDefaultLifetime 0;
route 2001:db8:1::/64 {
};
};

Cisco accepts it by default AFAIK, linux needs a sysctl 
net.ipv6.conf.*.accept_ra_rt_info_max_plen set to 64.

Moreover, enabling receiving RA-RIO prefixes in router namespaces allows 
routers communicate by themselves.

I’ve done PoC patch for it https://gist.github.com/yottatsa/8282e670da16934960b3


[1]: 
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/ipv6-prefix-delegation.html
[2]: https://bugs.launchpad.net/neutron/+bug/1505316
[3]: https://tools.ietf.org/html/rfc4191

-- 
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.




__
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

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

2015-12-17 Thread Carl Baldwin 
On Thu, Dec 17, 2015 at 1:30 PM, Vladimir Eremin  wrote:
> Hi
>
> For now, when end user is creating IPv6-enabled tenant network and attaching 
> it to the virtual router, there is only way to set up external infrastructure 
> to put traffic back to the router is using DHCPv6 PD[1], unfortunately, it’s 
> not working at all[2]. Other methods like implementing BGP is still in 
> development.
>
> BTW, in IPv6 Router Advertisements we have an option called Route Information 
> Option, RA-RIO[3] to advertise more specific routes from gateway. We could 
> easily append a section like next one to advertise tenant prefix 
> 2001:db8:1::/64 to public network. And if provider network router outside 
> OpenStack will be configured to accept these.
>
> interface qg- {
> AdvDefaultLifetime 0;
> route 2001:db8:1::/64 {
> };
> };
>
> Cisco accepts it by default AFAIK, linux needs a sysctl 
> net.ipv6.conf.*.accept_ra_rt_info_max_plen set to 64.
>
> Moreover, enabling receiving RA-RIO prefixes in router namespaces allows 
> routers communicate by themselves.
>
> I’ve done PoC patch for it 
> https://gist.github.com/yottatsa/8282e670da16934960b3

This is an interesting idea.  I've wondered if we could do something
like this before but I didn't know all the details around RA-RIO.  The
problem is that, in general, we have no idea if the subnets behind the
routers are viable in the external network context.  So, we can't just
blindly have routers advertising whatever.

In Mitaka, we're merging a new feature called "address scopes".  We
could limit advertising to only subnets that come from the address
scope matching that of the external network.  If we do this then we'll
know that the subnet came from a pool of addresses that are valid in
the external network context and that the addresses are unique.

This could be relatively easy to implement on top of the current
address scopes work.  I think this is worth exploring with an RFE.
Would you mind filing an RFE according to the Neutron process [1]?

Carl

[1] 
http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements

__
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

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

2015-12-17 Thread Vladimir Eremin 
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.

BTW, could you please point me to the spec for address scopes.

-- 
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.



> On Dec 17, 2015, at 1:13 PM, Carl Baldwin  wrote:
> 
> On Thu, Dec 17, 2015 at 1:30 PM, Vladimir Eremin  wrote:
>> Hi
>> 
>> For now, when end user is creating IPv6-enabled tenant network and attaching 
>> it to the virtual router, there is only way to set up external 
>> infrastructure to put traffic back to the router is using DHCPv6 PD[1], 
>> unfortunately, it’s not working at all[2]. Other methods like implementing 
>> BGP is still in development.
>> 
>> BTW, in IPv6 Router Advertisements we have an option called Route 
>> Information Option, RA-RIO[3] to advertise more specific routes from 
>> gateway. We could easily append a section like next one to advertise tenant 
>> prefix 2001:db8:1::/64 to public network. And if provider network router 
>> outside OpenStack will be configured to accept these.
>> 
>> interface qg- {
>>AdvDefaultLifetime 0;
>>route 2001:db8:1::/64 {
>>};
>> };
>> 
>> Cisco accepts it by default AFAIK, linux needs a sysctl 
>> net.ipv6.conf.*.accept_ra_rt_info_max_plen set to 64.
>> 
>> Moreover, enabling receiving RA-RIO prefixes in router namespaces allows 
>> routers communicate by themselves.
>> 
>> I’ve done PoC patch for it 
>> https://gist.github.com/yottatsa/8282e670da16934960b3
> 
> This is an interesting idea.  I've wondered if we could do something
> like this before but I didn't know all the details around RA-RIO.  The
> problem is that, in general, we have no idea if the subnets behind the
> routers are viable in the external network context.  So, we can't just
> blindly have routers advertising whatever.
> 
> In Mitaka, we're merging a new feature called "address scopes".  We
> could limit advertising to only subnets that come from the address
> scope matching that of the external network.  If we do this then we'll
> know that the subnet came from a pool of addresses that are valid in
> the external network context and that the addresses are unique.
> 
> This could be relatively easy to implement on top of the current
> address scopes work.  I think this is worth exploring with an RFE.
> Would you mind filing an RFE according to the Neutron process [1]?
> 
> Carl
> 
> [1] 
> http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
> 
> __
> 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

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

2015-12-17 Thread Carl Baldwin 
On Thu, Dec 17, 2015 at 4:09 PM, Vladimir Eremin  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