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 settingtablenowith 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
