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 <[email protected]> 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 > [email protected] > https://lists.quagga.net/mailman/listinfo/quagga-dev > >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
