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.
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.
In Steve's diff for ovn-northd.c, in build_static_route_flow which is called
for every static route, the section starting with:
+ /* find the outgoing port */
+ out_port = NULL;
+ len = 0;
+ for (int i = 0; i < od->nbr->n_ports; i++){
>> 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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
