[openstack-dev] [neutron][nova] New specs on routed networking
Angus Lees
gus at inodes.org
Tue Oct 28 23:59:05 UTC 2014
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 <blak111 at gmail.com<mailto:blak111 at gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org
> >> Date: Tuesday, October 28, 2014 1:01 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org<mailto:openstack-dev at 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
> <keshava.a at hp.com<mailto:keshava.a at 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.Benfield at metaswitch.com<mailto:Cory.Benfield at 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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Kevin Benton
More information about the OpenStack-dev
mailing list