Re: [openstack-dev] [neutron][nova] New specs on routed networking

2014-10-28 Thread Fred Baker (fred)

On Oct 28, 2014, at 4:59 PM, Angus Lees g...@inodes.org wrote:

 On Tue, 28 Oct 2014 09:07:03 PM Rohit Agarwalla wrote:
 Agreed. The way I'm thinking about this is that tenants shouldn't care what
 the underlying implementation is - L2 or L3. As long as the connectivity
 requirements are met using the model/API, end users should be fine. The
 data center network design should be an administrators decision based on
 the implementation mechanism that has been configured for OpenStack.
 
 I don't know anything about Project Calico, but I have been involved with 
 running a large cloud network previously that made heavy use of L3 overlays.  
 
 Just because these points weren't raised earlier in this thread:  In my 
 experience, a move to L3 involves losing:
 
 - broadcast/multicast.  It's possible to do L3 multicast/IGMP/etc, but that's 
 a whole can of worms - so perhaps best to just say up front that this is a 
 non-broadcast network.
 
 - support for other IP protocols.
 
 - various L2 games like virtual MAC addresses, etc that NFV/etc people like.

I’m a little confused. IP supports multicast. It requires a routing protocol, 
and you have to “join” the multicast group, but it’s not out of the picture.

What other “IP” protocols do you have in mind? Are you thinking about 
IPX/CLNP/etc? Or are you thinking about new network layers?

I’m afraid the L2 games leave me a little cold. We have been there, such as 
with DECNET IV. I’d need to understand what you were trying to achieve before I 
would consider that a loss.

 We gain:
 
 - the ability to have proper hierarchical addressing underneath (which is a 
 big one for scaling a single network).  This itself is a tradeoff however - 
 an efficient/strict hierarchical addressing scheme means VMs can't choose 
 their 
 own IP addresses, and VM migration is messy/limited/impossible.

It does require some variation on a host route, and it leads us to ask about 
renumbering. The hard part of VM migration is at the application layer, not the 
network, and is therefore pretty much the same.

 - hardware support for dynamic L3 routing is generally universal, through a 
 small set of mostly-standard protocols (BGP, ISIS, etc).
 
 - can play various L3 games like BGP/anycast, which is super useful for 
 geographically diverse services.
 
 
 It's certainly a useful tradeoff for many use cases.  Users lose some 
 generality in return for more powerful cooperation with the provider around 
 particular features, so I sort of think of it like a step halfway up the IaaS-
 PaaS stack - except for networking.
 
 - Gus
 
 Thanks
 Rohit
 
 From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 Date: Tuesday, October 28, 2014 1:01 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [neutron][nova] New specs on routed
 networking
 1. Every packet L3 FIB Lookup : Radix Tree Search, instead of current L2
 Hash/Index Lookup ? 2. Will there be Hierarchical network ?  How much
 of the Routes will be imported from external world ? 3. Will there be 
 Separate routing domain for overlay network  ? Or it will be mixed with
 external/underlay network ?
 These are all implementation specific details. Different deployments and
 network backends can implement them however they want. What we need to
 discuss now is how this model will look to the end-user and API.
 4. What will be the basic use case of this ? Thinking of L3 switching to
 support BGP-MPLS L3 VPN Scenario right from compute node ?
 I think the simplest use case is just that a provider doesn't want to deal
 with extending L2 domains all over their datacenter.
 
 On Tue, Oct 28, 2014 at 12:39 PM, A, Keshava
 keshav...@hp.commailto:keshav...@hp.com wrote: Hi Cory,
 
 Yes that is the basic question I have.
 
 OpenStack cloud  is ready to move away from Flat L2 network ?
 
 1. Every packet L3 FIB Lookup : Radix Tree Search, instead of current L2
 Hash/Index Lookup ? 2. Will there be Hierarchical network ?  How much
 of the Routes will be imported from external world ? 3. Will there be 
 Separate routing domain for overlay network  ? Or it will be mixed with
 external/underlay network ? 4. What will be the basic use case of this ?
 Thinking of L3 switching to support BGP-MPLS L3 VPN Scenario right from
 compute node ?
 
 Others can give their opinion also.
 
 Thanks  Regards,
 keshava
 
 -Original Message-
 From: Cory Benfield
 [mailto:cory.benfi...@metaswitch.commailto:cory.benfi...@metaswitch.com]
 Sent: Tuesday, October 28, 2014 10:35 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [neutron][nova] New specs on routed networking
 
 On Tue, Oct 28, 2014 at 07:44:48, A, Keshava wrote:
 Hi,
 
 

Re: [openstack-dev] [neutron][nova] New specs on routed networking

2014-10-29 Thread Fred Baker (fred)
Some of us are looking at a different model. I’d be interested in your thoughts.

The premise in this is that a great deal of the complexity in OpenStack is 
basically working around the deficiencies of IPv4, especially its address space 
and issues in multicast deployment. IPv6 actually addresses a lot of that. So I 
would posit that we can use a label to isolate tenants, use IPv6 Multicast for 
the cases in which IPv4 and Ethernet use broadcast, and wind up with some much 
simpler and more scalable. 

https://tools.ietf.org/html/draft-baker-openstack-ipv6-model
  A Model for IPv6 Operation in OpenStack, Fred Baker, Chris Marino, Ian
  Wells, 2014-10-17

https://tools.ietf.org/html/draft-baker-openstack-rbac-federated-identity
  Federated Identity for IPv6 Role-base Access Control, Fred Baker,
  2014-10-17


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][nova] New specs on routed networking

2014-10-29 Thread Fred Baker (fred)

On Oct 28, 2014, at 12:44 AM, A, Keshava keshav...@hp.com wrote:

 Here thinking  OpenStack cloud as hierarchical network instead of Flat 
 network ?

A routed network has one lookup just like a bridged network. The difference is 
that the router operates as a host in the L2 domain - it only receives or 
operates on messages sent to its MAC address or to multicast addresses it 
accepts.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][nova] New specs on routed networking

2014-10-29 Thread Fred Baker (fred)
Certainly, let’s talk next week in Paris.

On Oct 29, 2014, at 12:11 PM, Cory Benfield cory.benfi...@metaswitch.com 
wrote:

 Some of us are looking at a different model. I’d be interested in your 
 thoughts.
 
 Fred,
 
 Thanks for the link to the drafts. They look extremely similar to the 
 approach we've been pursuing for Project Calico, and it's good to see 
 that we're not the only people thinking in this direction.
 
 It looks like the main differences between our approach and yours are 
 that we've tried to come up with a model that works both for IPv4 and 
 IPv6 (although we agree that moving the data center fabric to IPv6 has a 
 lot of advantages - e.g. we are planning on using 464XLAT as the 
 mechanism to handle IPv4 overlap).  Given this, we've focused our 
 policy/security model on ACLs rather than flow labels.  An interesting 
 derivative effect of that choice is that any policy or security model 
 can be enforced (such as intra-tenant controls, extra-cloud controls, 
 etc).
 
 As a side note, we have been interested in using flow labels as 
 namespace identifiers and for SFC.  Recently, we have moved away from 
 that thinking given the guidance that the flow label should be not be 
 modified in flight.  If you believe that such modifications will be 
 acceptable, we would love to discuss that with you, and see where we can 
 collaborate.
 
 As it is, I believe our proposed changes to Nova and Neutron should be 
 generic enough to provide a basis for implementing your approach as well 
 as supporting our Project Calico ML2 driver. If they aren't, we should 
 work together to make whatever changes we have to make to achieve that 
 generality.
 
 It might also be worth checking out our agent code[0]. It's in the 
 middle of a rewrite at the minute so the code is unfinished, but it 
 handles a lot of what you'd be doing with your proposed drafts. 
 Hopefully it'd be a useful jumping off point.
 
 Cory
 
 [0]: https://github.com/Metaswitch/calico/tree/master/calico/felix
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev