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. 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. For these reasons, I prefer to keep a separate table for static routes. Mickey -----"dev" <dev-boun...@openvswitch.org> wrote: ----- To: Shi Xin Ruan <steve.r...@cn.ibm.com> From: Guru Shetty Sent by: "dev" Date: 04/04/2016 08:41AM Cc: ovs dev <dev@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.r...@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@openvswitch.org http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
