Guru,

Your summary is exactly what I was thinking.

Mickey


-----Guru Shetty <g...@ovn.org> wrote: -----
To: Mickey Spiegel/San Jose/IBM@IBMUS
From: Guru Shetty <g...@ovn.org>
Date: 04/07/2016 11:05AM
Cc: ovs dev <dev@openvswitch.org>, Shi Xin Ruan <steve.r...@cn.ibm.com>
Subject: Re: [ovs-dev] [PATCH 1/1] Add Static route to logical router



On 7 April 2016 at 01:43, Mickey Spiegel <emspi...@us.ibm.com> wrote:
See comments inline
 
 Mickey
 
 
 -----Guru Shetty <g...@ovn.org> wrote: -----
 >To: Mickey Spiegel/San Jose/IBM@IBMUS
 >From: Guru Shetty <g...@ovn.org>
 >Date: 04/06/2016 05:58PM
 >Cc: ovs dev <dev@openvswitch.org>, Shi Xin Ruan <steve.r...@cn.ibm.com>
 >Subject: Re: [ovs-dev] [PATCH 1/1] Add Static route to logical router
 >
 >
 >
 >On 6 April 2016 at 16:55, Mickey Spiegel <emspi...@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.
 
 [Mickey] Point of clarification, the proposal is to add an output port column 
to the static route table in northd. The question is not whether there is code 
in ovn-northd that uses it, it is whether there is code at the CMS layer that 
fills this column. Both the features in points 1 and 2 would make use of this 
column.
I see what you mean now.

 
 Even if we don't add this column now, if you don't have a separate static 
route table, it will make such an addition difficult in the future.
 
 >> 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.
 
 [Mickey] By routing recursion I just meant a small walk through all of the 
router ports to find which router port has the next hop address.
We are on the same page then (for the above point.)

So to summarize, a new table will help if we add the outport as a column and 
keep it optional. If it is filled, use it. Else, figure out the next hop.



 

_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to