On 6/1/2015 9:28 AM, Paul Jakma wrote:
Using the fact that the Linux kernel namespaces were explicitly
designed to *avoid* the need for modifying user-space network code
(least, outside of things that want to trade info between namespaces),
to *avoid* having to modify the code has a huge advantage:
E.g., again, if we accept this zebra patch, we're going to have zebra
inside /containers/ advertising VRF capability (which may work on
Linux with its nestable namespaces, but not elsewhere), as things stand.
I think we are thinking too much in Linux terms, we want to rely on
the OS to provide the isolation so that we don't have to write/change a
lot of code and at the same time we want to be cross platform.
Functionality-wise for VRFs, "running inside" a VRF doesn't necessarily
mean running "from within", it mainly means managing that VRF. You could
still have 10 daemons managing 10 VRFs all running in the global scope.
In fact this is what 6WIND's patch promises since it adds the ability to
manage any VRF from the global scope. From a design point of view, I
believe we should disassociate namespaces from VRFs.
If we want to talk about design, we should think top-down. What do VRFs
mean for Quagga ( optimally I shouldn't even care if Quagga decides to
launch a new daemon to scale better although I'd still like to be able
to control that )? how do I create a VRF ? how do I use one?
Regards,
Jafar
P.S. I don't think we should get lost "inside" namespaces!... pun
intended :)
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
