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. 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. - 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.com<mailto:blak...@gmail.com>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org<mailto: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.org<mailto: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.com<mailto: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.com<mailto: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, > > > > Current Open-stack was built as flat network. > > > > With the introduction of the L3 lookup (by inserting the routing table > > in forwarding path) and separate 'VIF Route Type' interface: > > > > At what point of time in the packet processing decision will be made > > to lookup FIB during ? For each packet there will additional FIB > > lookup ? > > > > How about the impact on 'inter compute traffic', processed by DVR ? > > Here thinking OpenStack cloud as hierarchical network instead of Flat > > network ? > > Keshava, > > It's difficult for me to answer in general terms: the proposed specs are > general enough to allow multiple approaches to building purely-routed > networks in OpenStack, and they may all have slightly different answers to > some of these questions. I can, however, speak about how Project Calico > intends to apply them. > > For Project Calico, the FIB lookup is performed for every packet emitted by > a VM and destined for a VM. Each compute host routes all the traffic > to/from its guests. The DVR approach isn't necessary in this kind of > network because it essentially already implements one: all packets are > always routed, and no network node is ever required in the network. > > The routed network approach doesn't add any hierarchical nature to an > OpenStack cloud. The difference between the routed approach and the > standard OVS approach is that packet processing happens entirely at layer > 3. Put another way, in Project Calico-based networks a Neutron subnet no > longer maps to a layer 2 broadcast domain. > > I hope that clarifies: please shout if you'd like more detail. > > Cory > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Kevin Benton _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
