Re: [openstack-dev] [neutron][networking-ovn] Integration with OVN NAT gateway (Proposal)

2016-06-08 Thread Amitabha Biswas
Here is the proposal in etherpad to make 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 7, 2016, at 5:12 PM, Amitabha Biswas  wrote:
> 
> Sorry that was a typo, it should read:
> 
>> Note that the MAC addresses of gtrp and dtrp will be the same on each OVN 
>> Join Network, but because they are in different branches of the network 
>> topology it doesn’t matter.
> Amitabha
> 
>> On Jun 7, 2016, at 4:39 PM, Bhalachandra Banavalikar 
>> mailto:bhal.banavali...@us.ibm.com>> wrote:
>> 
>> Can you please provide more details on lgrp and lip ports (last bullet in 
>> section 1)?
>> 
>> Thanks,
>> Bhal
>> 
>> Amitabha Biswas ---06/07/2016 01:56:23 PM---This proposal 
>> outlines the modifications needed in networking-ovn (addresses 
>> https://bugs.launchpad <https://bugs.launchpad/>.
>> 
>> From:  Amitabha Biswas mailto:azbis...@gmail.com>>
>> To:  "OpenStack Development Mailing List (not for usage questions)" 
>> > <mailto:openstack-dev@lists.openstack.org>>
>> Cc:  Chandra Sekhar Vejendla/San Jose/IBM@IBMUS
>> Date:  06/07/2016 01:56 PM
>> Subject:  [openstack-dev] [neutron][networking-ovn] Integration with OVN NAT 
>> gateway (Proposal)
>> 
>> 
>> 
>> 
>> 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.
>> 
>> 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 
>> conf 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 gtrp and dtrp 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 pr

Re: [openstack-dev] [neutron][networking-ovn] Integration with OVN NAT gateway (Proposal)

2016-06-07 Thread Amitabha Biswas
Sorry that was a typo, it should read:

> Note that the MAC addresses of gtrp and dtrp will be the same on each OVN 
> Join Network, but because they are in different branches of the network 
> topology it doesn’t matter.
Amitabha

> On Jun 7, 2016, at 4:39 PM, Bhalachandra Banavalikar 
>  wrote:
> 
> Can you please provide more details on lgrp and lip ports (last bullet in 
> section 1)?
> 
> Thanks,
> Bhal
> 
> Amitabha Biswas ---06/07/2016 01:56:23 PM---This proposal 
> outlines the modifications needed in networking-ovn (addresses 
> https://bugs.launchpad <https://bugs.launchpad/>.
> 
> From: Amitabha Biswas 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Cc: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS
> Date: 06/07/2016 01:56 PM
> Subject: [openstack-dev] [neutron][networking-ovn] Integration with OVN NAT 
> gateway (Proposal)
> 
> 
> 
> 
> 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.
> 
> 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 
> conf 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 gtrp and dtrp 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 ta

Re: [openstack-dev] [neutron][networking-ovn] Integration with OVN NAT gateway (Proposal)

2016-06-07 Thread Bhalachandra Banavalikar
Can you please provide more details on lgrp and lip ports (last bullet in
section 1)?

Thanks,
Bhal



From:   Amitabha Biswas 
To: "OpenStack Development Mailing List (not for usage questions)"

Cc: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS
Date:   06/07/2016 01:56 PM
Subject:[openstack-dev] [neutron][networking-ovn] Integration with OVN
        NAT gateway (Proposal)



This proposal outlines the modifications needed in networking-ovn
(addresses https://bugs.launchpad.net/networking-ovn/+bug/1551717) to
provide Floating IP (FIP) and SNAT using the L3 gateway router patches.

http://patchwork.ozlabs.org/patch/624312/
http://patchwork.ozlabs.org/patch/624313/
http://patchwork.ozlabs.org/patch/624314/
http://patchwork.ozlabs.org/patch/624315/
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 conf 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 logi

[openstack-dev] [neutron][networking-ovn] Integration with OVN NAT gateway (Proposal)

2016-06-07 Thread Amitabha Biswas
This proposal outlines the modifications needed in networking-ovn (addresses 
https://bugs.launchpad.net/networking-ovn/+bug/1551717 
) to provide Floating 
IP (FIP) and SNAT using the L3 gateway router patches.

http://patchwork.ozlabs.org/patch/624312/ 
 
http://patchwork.ozlabs.org/patch/624313/ 
 
http://patchwork.ozlabs.org/patch/624314/ 
 
http://patchwork.ozlabs.org/patch/624315/ 
 
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 
conf 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 

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.

Thanks
Amitabha (azbiswas) and Chandra (chandrav)

__
OpenStack Development Mailing List (not for usage