On Wed, May 27, 2015 at 12:11:52PM +0200, Vincent JARDIN wrote: > Until now, I did prefer to stay quite to avoid confusions. > > 1- I understand that there is a consensus on this contribution (both > approaches Single Daemon and Multi Daemon make sense and can coexist), > 2- my review of the code is OK too. > > So, I am ready for a merge of this v3 of the patch, unless there is > another concern on the code.
The normal approach is to have the code on the list for comments/review for circa 2 weeks. I see no problem merging your code, but I'd like to wait a few more days. I will merge it by next Monday if no one complains :) Btw: http://patchwork.quagga.net/ lists the age of patches now, next to the date. We're not really using the "Under Review" state, but I do mark patches as "Accepted" or "Changes Requested". Cheers, -David > On 27/05/2015 10:42, Nicolas Dichtel wrote: > > I also agree. > > > > > > Thank you, > > Nicolas > > > > Le 26/05/2015 22:33, Donald Sharp a écrit : > >> Jafar - > >> > >> Thanks for saying this so eloquently. This is exactly what we have been > >> discussing internally and we believe that this is the correct > >> direction to > >> go. > >> > >> thanks! > >> > >> donald > >> > >> On Tue, May 26, 2015 at 3:13 PM, Jafar Al-Gharaibeh <ja...@atcorp.com> > >> wrote: > >> > >>> Andrew, > >>> > >>> I will leave direct answers to your questions to Nicolas, but > >>> here is > >>> my take in the matter. > >>> > >>> Given how substantial 6WIND's patches already, I'd probably wait for > >>> the patches to be merged in (if ever) and rebase afterward. > >>> > >>> Just a thought, in the bigger picture, I think your approach to VRF > >>> (VRF-light as you call it) complements 6WIND's, and it is useful > >>> with or > >>> without 6WIND patches, but we need resolve terminology issues if we are > >>> going to have both. 6WIND's VRFs are tightly coupled to network > >>> namespaces > >>> while your VRFs are mapping to different routing tables. I know there > >>> is a > >>> "table" commands in zebra that I've never tried and don't know if it is > >>> fully functional. The documentation says: > >>> > >>> — Command: *table *tableno > >>> > >>> Select the primary kernel routing table to be used. This only works for > >>> kernels supporting multiple routing tables (like GNU/Linux 2.2.x and > >>> later). After setting tableno with this command, static routes defined > >>> after this are added to the specified table. > >>> > >>> > >>> "VRF-Light" defines a mapping to different kernel routing tables. In my > >>> mind, (Please correct if I'm wrong) it seems as if vrf-light is a > >>> natural > >>> generalization of this command's concept. Currently the "table" command > >>> has a global effect on Zebra's state and I'm not sure if you can > >>> change the > >>> table at run-time even, with VRF-Light we want to extend this > >>> behavior and > >>> make it dynamic so that we can maintain different tables at the same > >>> time, > >>> and also direct commands/routes to a specific table. In such world: > >>> > >>> VRF 3 table 2 > >>> > >>> Means network name space 3, routing table number 2. The former is > >>> 6WIND's work, the latter is yours. > >>> > >>> Cheers, > >>> Jafar > >>> > >>> > >>> On 5/26/2015 1:08 PM, Xiaorong (Andrew) Qu wrote: > >>> > >>> Hi Nicolas, > >>> > >>> > >>> It's good to see 6wind also worked on VRF support. > >>> > >>> How about we coordinate the VRF support check-in? we can re-base to > >>> your branch and add what is missed in our patch? > >>> > >>> The design/implementation between 6wind and us in this patch are very > >>> similar, so there will be no much conflict in design and is more > >>> just add on. > >>> > >>> coordinating may resolve minor differences before entire patch > >>> checked in > >>> Quagga. and it may serves a good code review as well. > >>> > >>> What do you think? > >>> > >>> Thanks, > >>> > >>> Andrew > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Quagga-dev mailing list > >>> Quagga-dev@lists.quagga.net > >>> https://lists.quagga.net/mailman/listinfo/quagga-dev > >>> > >>> > >> > > > > > > _______________________________________________ > > Quagga-dev mailing list > > Quagga-dev@lists.quagga.net > > https://lists.quagga.net/mailman/listinfo/quagga-dev > _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
