Open Stack

L3 routed network can support
1. broadcast/multicast
2. VRRP virtual MAC like technology

For example OpenContrail does support both of these in fully L3 routed
networks.

Regards
-Harshad

On Tue, Oct 28, 2014 at 4:59 PM, Angus Lees <gus at 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.
>
>
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141028/aa78ca3f/attachment-0001.html>