David, Paul,
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.
Best regards,
Vincent
PS: Sorry, I cannot connect on IRC during dayworks.
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 <[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
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
