<div dir="ltr">L3 routed network can support<div>1. broadcast/multicast</div><div>2. VRRP virtual MAC like technology</div><div><br></div><div>For example OpenContrail does support both of these in fully L3 routed networks.</div><div><br></div><div>Regards</div><div>-Harshad<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 28, 2014 at 4:59 PM, Angus Lees <span dir="ltr"><<a href="mailto:gus@inodes.org" target="_blank">gus@inodes.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 28 Oct 2014 09:07:03 PM Rohit Agarwalla wrote:<br>
> Agreed. The way I'm thinking about this is that tenants shouldn't care what<br>
> the underlying implementation is - L2 or L3. As long as the connectivity<br>
> requirements are met using the model/API, end users should be fine. The<br>
> data center network design should be an administrators decision based on<br>
> the implementation mechanism that has been configured for OpenStack.<br>
<br>
</span>I don't know anything about Project Calico, but I have been involved with<br>
running a large cloud network previously that made heavy use of L3 overlays.<br>
<br>
Just because these points weren't raised earlier in this thread: In my<br>
experience, a move to L3 involves losing:<br>
<br>
- broadcast/multicast. It's possible to do L3 multicast/IGMP/etc, but that's<br>
a whole can of worms - so perhaps best to just say up front that this is a<br>
non-broadcast network.<br>
<br>
- support for other IP protocols.<br>
<br>
- various "L2 games" like virtual MAC addresses, etc that NFV/etc people like.<br>
<br>
<br>
We gain:<br>
<br>
- the ability to have proper hierarchical addressing underneath (which is a<br>
big one for scaling a single "network"). This itself is a tradeoff however -<br>
an efficient/strict hierarchical addressing scheme means VMs can't choose their<br>
own IP addresses, and VM migration is messy/limited/impossible.<br>
<br>
- hardware support for dynamic L3 routing is generally universal, through a<br>
small set of mostly-standard protocols (BGP, ISIS, etc).<br>
<br>
- can play various "L3 games" like BGP/anycast, which is super useful for<br>
geographically diverse services.<br>
<br>
<br>
It's certainly a useful tradeoff for many use cases. Users lose some<br>
generality in return for more powerful cooperation with the provider around<br>
particular features, so I sort of think of it like a step halfway up the IaaS-<br>
>PaaS stack - except for networking.<br>
<br>
- Gus<br>
<br>
> Thanks<br>
> Rohit<br>
><br>
> From: Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a><mailto:<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>>><br>
<span class="">> Reply-To: "OpenStack Development Mailing List (not for usage questions)"<br>
</span>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<span class="">> >> Date: Tuesday, October 28, 2014 1:01 PM<br>
> To: "OpenStack Development Mailing List (not for usage questions)"<br>
</span>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<span class="">> >> Subject: Re: [openstack-dev] [neutron][nova] New specs on routed<br>
> networking<br>
> >1. Every packet L3 FIB Lookup : Radix Tree Search, instead of current L2<br>
> >Hash/Index Lookup ? 2. Will there be Hierarchical network ? How much<br>
> >of the Routes will be imported from external world ? 3. Will there be<br>
> >Separate routing domain for overlay network ? Or it will be mixed with<br>
> >external/underlay network ?<br>
> These are all implementation specific details. Different deployments and<br>
> network backends can implement them however they want. What we need to<br>
> discuss now is how this model will look to the end-user and API.<br>
> >4. What will be the basic use case of this ? Thinking of L3 switching to<br>
> >support BGP-MPLS L3 VPN Scenario right from compute node ?<br>
> I think the simplest use case is just that a provider doesn't want to deal<br>
> with extending L2 domains all over their datacenter.<br>
><br>
> On Tue, Oct 28, 2014 at 12:39 PM, A, Keshava<br>
</span>> <<a href="mailto:keshava.a@hp.com">keshava.a@hp.com</a><mailto:<a href="mailto:keshava.a@hp.com">keshava.a@hp.com</a>>> wrote: Hi Cory,<br>
<span class="">><br>
> Yes that is the basic question I have.<br>
><br>
> OpenStack cloud is ready to move away from Flat L2 network ?<br>
><br>
> 1. Every packet L3 FIB Lookup : Radix Tree Search, instead of current L2<br>
> Hash/Index Lookup ? 2. Will there be Hierarchical network ? How much<br>
> of the Routes will be imported from external world ? 3. Will there be<br>
> Separate routing domain for overlay network ? Or it will be mixed with<br>
> external/underlay network ? 4. What will be the basic use case of this ?<br>
> Thinking of L3 switching to support BGP-MPLS L3 VPN Scenario right from<br>
> compute node ?<br>
><br>
> Others can give their opinion also.<br>
><br>
> Thanks & Regards,<br>
> keshava<br>
><br>
> -----Original Message-----<br>
> From: Cory Benfield<br>
</span><div><div class="h5">> [mailto:<a href="mailto:Cory.Benfield@metaswitch.com">Cory.Benfield@metaswitch.com</a><mailto:<a href="mailto:Cory.Benfield@metaswitch.com">Cory.Benfield@metaswitch.com</a>>]<br>
> Sent: Tuesday, October 28, 2014 10:35 PM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [neutron][nova] New specs on routed networking<br>
><br>
> On Tue, Oct 28, 2014 at 07:44:48, A, Keshava wrote:<br>
> > Hi,<br>
> ><br>
> > Current Open-stack was built as flat network.<br>
> ><br>
> > With the introduction of the L3 lookup (by inserting the routing table<br>
> > in forwarding path) and separate 'VIF Route Type' interface:<br>
> ><br>
> > At what point of time in the packet processing decision will be made<br>
> > to lookup FIB during ? For each packet there will additional FIB<br>
> > lookup ?<br>
> ><br>
> > How about the impact on 'inter compute traffic', processed by DVR ?<br>
> > Here thinking OpenStack cloud as hierarchical network instead of Flat<br>
> > network ?<br>
><br>
> Keshava,<br>
><br>
> It's difficult for me to answer in general terms: the proposed specs are<br>
> general enough to allow multiple approaches to building purely-routed<br>
> networks in OpenStack, and they may all have slightly different answers to<br>
> some of these questions. I can, however, speak about how Project Calico<br>
> intends to apply them.<br>
><br>
> For Project Calico, the FIB lookup is performed for every packet emitted by<br>
> a VM and destined for a VM. Each compute host routes all the traffic<br>
> to/from its guests. The DVR approach isn't necessary in this kind of<br>
> network because it essentially already implements one: all packets are<br>
> always routed, and no network node is ever required in the network.<br>
><br>
> The routed network approach doesn't add any hierarchical nature to an<br>
> OpenStack cloud. The difference between the routed approach and the<br>
> standard OVS approach is that packet processing happens entirely at layer<br>
> 3. Put another way, in Project Calico-based networks a Neutron subnet no<br>
> longer maps to a layer 2 broadcast domain.<br>
><br>
> I hope that clarifies: please shout if you'd like more detail.<br>
><br>
> Cory<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
</div></div>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<span class="">> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
</span>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<span class="im HOEnZb">> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> --<br>
> Kevin Benton<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>