[ovs-dev] [PATCH 1/1] Add Static route to logical router

[Darrell Ball]

On Wed, Apr 6, 2016 at 5:58 PM, Guru Shetty <guru at ovn.org> wrote:

> On 6 April 2016 at 16:55, Mickey Spiegel <emspiege at us.ibm.com> wrote:
>
> > Steve and Guru,
> >
> > I am not all that concerned about the "valid" column, but I do think that
> > we will need a different additional column in the near future for output
> > port.
> >
> > There are three different motivations for allowing output port to be
> > specified in the static route:
> > 1) In order to support static routes with a link local next hop. If a
> link
> > local next hop is used, it is possible that the same link local address
> > appears on different router ports with different meanings. By specifying
> > the port, this disambiguates the specific link local next hop that was
> > desired.
> > Note: Neutron does not yet support static routes with link local next
> hop.
> > We need to drive the feature in Neutron as well, optionally allowing a
> > router interface to be specified in addition to the next hop.
> > 2) This feature should not really be specific to static routes, it should
> > also apply to dynamic routes when we add that in the future. Basically
> > anything that looks up an IP address prefix and returns a next hop and
> > optionally an output port. There are cases where explicitly specifying
> the
> > output port makes sense.
> >
> For point 1 and 2, I am not sure whether we should do anything till there
> is code in ovn-northd that actually uses it.
>
>
>
> > 3) In order to optimize processing of the routing recursion (Steve's code
> > loops over the router's ports in ovn-northd.c to carry out this routing
> > recursion), we might want to do it above OVN in an event triggered
> manner,
> > rather than every time ovn-northd.c recalculates the flows that it places
> > into the southbound database.
> >
> I don't think I understand the above point. The static_route I have in mind
> need not recursively look through routers. All they need is to see whether
> the router peer has the next hop IP address and the packet is just sent to
> that router. From there on it is a fresh start.
>

The last point that Mickey mentioned is relevant even in this simplest form
of
routing.

Specifying both outport (eg logical router port) and next hop has
significant
advantages in processing time even for tiny route scales of a few 1000s
routes.
This is because finding the outport for each single non-recursive route is
O(1)
with smallest possible constant.



>
>
>
> >
> > For these reasons, I prefer to keep a separate table for static routes.
> >
> > Mickey
> >
> >
> > -----"dev" <dev-bounces at openvswitch.org> wrote: -----
> > To: Shi Xin Ruan <Steve.ruan at cn.ibm.com>
> > From: Guru Shetty
> > Sent by: "dev"
> > Date: 04/04/2016 08:41AM
> > Cc: ovs dev <dev at openvswitch.org>
> > Subject: Re: [ovs-dev] [PATCH 1/1] Add Static route to logical router
> >
> > On 31 March 2016 at 19:11, Shi Xin Ruan <Steve.ruan at cn.ibm.com> wrote:
> >
> > > Thanks Guru.
> > >
> > > The column "valid" will indicate whether the routes has been transfer
> > into
> > > logical flow.
> > > Thinking about this case, deleting the logical router port which is out
> > > going interface of some static routes.
> > > The first possible way is preventing the deleting, the second way is
> > > removing the stactic routing from logical flow.
> > >
> > [Trying this again as my previous reply got rejected by the mailing list]
> > I feel this is an unnecessary complication (unless it becomes a real use
> > case). Let us start with not adding a new table and try to do this with a
> > column. If you are fine with it, would you mind re-spinning a non-RFC
> patch
> > with a unit test? If you want, I can provide the unit tests. If you
> prefer
> > that I do the entire thing, I am happy with that too.
> >
> >
> >
> > >
> > >
> > > From my points, both can work fine and has their advantages.
> > >
> > >
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
> >
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
> >
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>