On Mon, Jun 6, 2016 at 9:55 PM, Ben Pfaff <b...@ovn.org> wrote: > On Tue, May 31, 2016 at 09:37:10AM -0700, Darrell Ball wrote: > > This patch adds local router support. The CMS provides a hint for > > a NB distributed logical router as to which logical switches the > > logical router services; the CMS always knows this information. A > > new external ID tentatively named local-router-lss is used, which is > > a list of NB logical switch UUIDs associated with a logical router. > > > > This association is converted by northd into SB database format also > > using an external ID, local-router-lss, but storing logical switch > datapath > > tunnel keys. > > > > During lflow processing the above southbound association is queried to > > allow only processing southbound logical flows that are needed on a given > > HV. Two hash tables are used to keep track of which logical router data > paths > > are needed locally and which are already known to be not needed. > > > > Signed-off-by: Darrell Ball <dlu...@gmail.com> > > I don't understand why the CMS needs to separately provide this > information to the hypervisors. I think that a hypervisor can start > from the VIFs that it hosts, then follow patch ports from the logical > switches that those VIFs are on to arrive at the logical routers that > the hypervisor hosts, and so on recursively. >
Thanks for the comment I considered the bottom up flood fill approach following logical patch ports and their peer ports; the advantages of the bottom up approach are clear. I wanted to explore another general approach with this patch - using precomputed datasets. The OVN NB API requires forming the associations b/w logical switches and logical routers as would any other similar CMS API. The full set of associations per LR must also be known, in the CMS, in some form, in order to manage each tenant network and/or subnetwork. Hence, this patch uses an existing LS-LR association set, which is also direct information from the originator/master of the association set (i.e. the CMS) along with local VIF info.. There is a minor added requirement in packaging the data down to OVN. However, I also don't like having any dependency, however minor, on the CMS side in this ecosystem; this probably trumps most other considerations. Hence, this patch approach can be abandoned. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
