Here is the proposal in etherpad, I hope it makes it more readable - https://etherpad.openstack.org/p/Integration_with_OVN_L3_Gateway <https://etherpad.openstack.org/p/Integration_with_OVN_L3_Gateway>
Thanks Amitabha > On Jun 8, 2016, at 5:59 AM, Kyle Mestery <mest...@mestery.com> wrote: > > On Tue, Jun 7, 2016 at 3:50 PM, Amitabha Biswas <azbis...@gmail.com> wrote: >> This proposal outlines the modifications needed in networking-ovn (addresses >> https://bugs.launchpad.net/networking-ovn/+bug/1551717 >> <https://bugs.launchpad.net/networking-ovn/+bug/1551717>) to provide >> Floating IP (FIP) and SNAT using the L3 gateway router patches listed below: >> >> http://patchwork.ozlabs.org/patch/624312/ >> <http://patchwork.ozlabs.org/patch/624312/> >> http://patchwork.ozlabs.org/patch/624313/ >> <http://patchwork.ozlabs.org/patch/624312/> >> http://patchwork.ozlabs.org/patch/624314/ >> <http://patchwork.ozlabs.org/patch/624312/> >> http://patchwork.ozlabs.org/patch/624315/ >> <http://patchwork.ozlabs.org/patch/624312/> >> http://patchwork.ozlabs.org/patch/629607/ >> <http://patchwork.ozlabs.org/patch/629607/> >> >> Diagram: >> >> +-------+ +-------+ >> | NET 1 | | NET 2 | >> +-------+ +-------+ >> | | >> | ********* | >> | ** ** | >> | ** * * ** | >> +---RP1 * DR * RP2 --+ >> ** * * ** >> ** ** >> ********* >> DTRP (168.254.128.2) >> | >> | >> | >> +------------------+ >> | Transit Network | >> | 169.254.128.0/30 | >> +------------------+ >> | >> | >> | >> | >> GTRP (169.254.128.1) >> ******* >> ** ** >> ** * * ** +------------------+ >> * GW *-----------------| Provider Network | >> ** * * ** +------------------+ >> ** ** >> ******* >> >> New Entities: >> >> OVN Join/Transit Networks >> One per Neutron Router - /30 address space with only 2 ports for e.g. >> 169.254.128.0/30 >> Created when an external gateway is added to a router. >> One extra datapath per router with an External Gateway. >> (Alternate option - One Transit Network in a deployment, IPAM becomes a >> headache - Not discussed here). >> Prevent Neutron from using that /30 address space. Specify in networking-ovn >> con file. >> Create 1 new “Join” neutron network (to represent all Join OVN Networks) in >> the networking-ovn. >> Note that it may be possible to replace the Join/Transit network using >> Router Peering in later versions (not discussed here). >> Allocate 2 ports in the Join network in the networking-ovn plugin. >> Logical Gateway Transit Router Port (gtrp), 169.254.128.1 >> Logical Distributed Transit Router Port (dtrp), 169.254.128.2 >> Note that Neutron only sees 1 Join network with 2 ports; OVN sees a replica >> of this Join network as a new Logical Switch for each Gateway Router. The >> mapping of OVN Logical Switch(es) Join(s) to Gateway Router is discussed in >> OVN (Default) Gateway Routers below. >> Note that the MAC addresses of lgrp and lip will be the same on each OVN >> Join Network, but because they are in different branches of the network >> topology it doesn’t matter. >> OVN (Default) Gateway Routers: >> One per Neutron Router. >> 2 ports >> Logical Gateway Transit Router Port (gtrp), 169.254.128.1 (same for each OVN >> Join network). >> External/Provider Router Port (legwrp), this is allocated by neutron. >> Scheduling - The current OVN gateway proposal relies on the CMS/nbctl to >> decide on which hypervisor (HV) to schedule a particular gateway router. >> A setting on the chassis (new external_id key or a new column) that allows >> the hypervisor admin to specify that a chassis can or cannot be used to host >> a gateway router (similar to a network node in OpenStack). Default - Allow >> (for compatibility purposes). >> The networking-ovn plugin picks up the list of “candidate” chassis from the >> Southbound DB and uses an existing scheduling algorithm >> Use a simple random.choice i.e. ChanceScheduler (Version 1) >> Tap into the neutron’s LeastRouterScheduler - but that requires the >> networking-ovn (or some a hacked up version of the L3 agent) to imitate the >> L3 agent running on various network nodes. >> Populate the SNAT and DNAT columns in the logical router table. This is >> under review in OVS - >> http://openvswitch.org/pipermail/dev/2016-June/072169.html >> <http://openvswitch.org/pipermail/dev/2016-June/072169.html> >> Create static routing entry in the gateway router to route tenant bound >> traffic to the distributed logical router.ar gate >> >> Existing Entities: >> >> Distributed Logical Routers: >> Set the default gateway of the distributed logical router to the IP Address >> of the corresponding Logical Gateway Transit Router Port (169.254.128.1). >> >> It would be good to get some feedback on this strategy. Guru mentioned that >> he saw a need for ARP response across multiple gateway routers, we don’t see >> that requirement in this design/use-case. >> > > Amitabha, thanks for writing this up and sending it out! However, the > formating is really bad (I blame Notes). It's also bad in the archives > of the openstack-dev ML [1]. It may make sense to put this on an > etherpad or something so it's easier to digest. > > Overall, the proposal does make sense and I'm excited to hear feedback > from others. > > Thanks! > Kyle > > [1] http://lists.openstack.org/pipermail/openstack-dev/2016-June/096806.html > >> Thanks >> Amitabha (azbiswas) and Chandra (chandrav) >> >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
