On 2 June 2016 at 13:23, Ben Pfaff <b...@ovn.org> wrote:

> On Thu, May 19, 2016 at 01:02:31PM -0700, Gurucharan Shetty wrote:
> > Currently OVN has distributed switches and routers. When a packet
> > exits a container or a VM, the entire lifecycle of the packet
> > through multiple switches and routers are calculated in source
> > chassis itself. When the destination endpoint resides on a different
> > chassis, the packet is sent to the other chassis and it only goes
> > through the egress pipeline of that chassis once and eventually to
> > the real destination.
> >
> > When the packet returns back, the same thing happens. The return
> > packet leaves the VM/container on the chassis where it resides.
> > The packet goes through all the switches and routers in the logical
> > pipleline on that chassis and then sent to the eventual destination
> > over the tunnel.
> >
> > The above makes the logical pipeline very flexible and easy. But,
> > creates a problem for cases where you need to add stateful services
> > (via conntrack) on switches and routers.
> >
> > For l3 gateways, we plan to leverage DNAT and SNAT functionality
> > and we want to apply DNAT and SNAT rules on a router. So we ideally need
> > the packet to go through that router in both directions in the same
> > chassis. To achieve this, this commit introduces a new gateway router
> which is
> > static and can be connected to your distributed router via a switch.
> >
> > To make minimal changes in OVN's logical pipeline, this commit
> > tries to make the switch port connected to a l3 gateway router look like
> > a container/VM endpoint for every other chassis except the chassis
> > on which the l3 gateway router resides. On the chassis where the
> > gateway router resides, the connection looks just like a patch port.
> >
> > This is achieved by the doing the following:
> > Introduces a new type of port_binding record called 'gateway'.
> > On the chassis where the gateway router resides, this port behaves just
> > like the port of type 'patch'. The ovn-controller on that chassis
> > populates the "chassis" column for this record as an indication for
> > other ovn-controllers of its physical location. Other ovn-controllers
> > treat this port as they would treat a VM/Container port on a different
> > chassis.
> >
> > Signed-off-by: Gurucharan Shetty <g...@ovn.org>
>
> The commit mesagee description above is really good.  Do you think that
> it would be appropriate to include it, or some variant, somewhere in the
> documentation as introductory or tutorial material?
>

Thank you! ovn-architecture may be a place to fit it in. I will try to do
that as part of a separate patch.

>
> > diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml
> > index efd2f9a..741228c 100644
> > --- a/ovn/ovn-sb.xml
> > +++ b/ovn/ovn-sb.xml
> > @@ -1220,7 +1220,12 @@ tcp.flags = RST;
> >        which
> <code>ovn-controller</code>/<code>ovn-controller-vtep</code> in
> >        turn finds out by monitoring the local hypervisor's Open_vSwitch
> >        database, which identifies logical ports via the conventions
> described
> > -      in <code>IntegrationGuide.md</code>.
> > +      in <code>IntegrationGuide.md</code>. (The exceptions are for
>
> Instead of "of <code>type</code> 'gateway' here";
> > +      <code>Port_Binding</code> records of <code>type</code> 'gateway',
> I would write "with <code>type</code> of <code>gateway</code>", so that
> we are consistent about fonts.
>
> I made the change above and replaced a mention of 'non-distributed router'
to a 'a Gateway router (which is centralized)'
and applied it.


> > +      whose locations are identified by <code>ovn-northd</code> via
> > +      the <code>options:gateway-chassis</code> column in this table.
> > +      <code>ovn-controller</code> is still responsible to populate the
> > +      <code>chassis</code> column.)
> >      </p>
>
> Acked-by: Ben Pfaff <b...@ovn.org>
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to