Hi Paul,
The following is what I'd like to have using Quagga/w Linux. 1) in terms of LR support, we can use namespace features to split a physical routing device to a few logical ones with complete isolation. 2) modify routing daemons to be VRF aware so there is no conflict with 1) (namespace is only used for LR as the infrastructure) Additionally, maintain the supporting of multiple routing daemons within a namespace that may help to scale one instance even it can be cover all VRFs configured. with 1) we have logical container (100% isolation at admin level) with 2) each container can support VRF with multiple instances. It may take time to get there ultimately, but thanks for taking steps now to coordinate the effort. We are working on this as I sketched above, if needed, we can join and discuss how to design together. Thanks, Andrew -----Original Message----- From: Paul Jakma [mailto:[email protected]] Sent: Friday, October 16, 2015 5:24 AM To: Nicolas Dichtel Cc: Quagga Devel Subject: [quagga-dev 13302] Re: the VRF/namespace/multi-instance story On Fri, 16 Oct 2015, Nicolas Dichtel wrote: > Hi Paul, > we are pausing with this project right now, due to some other > priorities. We still plan to upstream vrf support in ospf, but it is > delayed. As you said, a first milestone has been reached, I'm not sur > to see why it blocks the release. > Concerning the zAPI, we can obviously agree on the general direction. > What you've proposed in your small PoC was (and is) ok for me. What do > you expect exactly? So that can go in? That was one thing blocking. The other is the current patch, being only a part of the story, is somewhat confusing. It is still not clear to me how we will make this "support both in-daemon VRFs and 1-daemon:VRF and shades in between" work. And myself and Donald spent a while yesterday on IRC discussing the issues. E.g., what is going to be responsible for creating the namespaces? zebra? How will 1:1 daemon:VRF work if zebra creates them? So we probably need another daemon setup the namespaces. Should that new daemon also then be responsible for starting daemons (side-effect: then 'router ospf|bgp|etc' potentially could be commands that start daemons, which might interest some)? Should it be watchquagga? How will the applicable VRFs be communicated to the daemons? How will this sync up with zebra? There are many high-level design questions that need to be worked out if we are to support /both/ 1:1 and m:n and shades between (e.g. 1:m zebra:VRF + 1:1 routing-daemon:VRF). Some aspects of which in the current preliminary support will become API and user-UI visible and hence more committed than now if we release. I'd like to figure out what the end state is likely to be, in terms of ZServ and UI requirements, so we can make whatever small changes are needed now to try avoid more obvious pain-points, confusion or dead-ends for users and other devs. The current state of things seems a little confusing, at least: We have 'vrf' commands in zebra that will not get you VRF; to get VRF you need to ignore those, create netnses with 'ip' instead, and just run a whole set of daemons in each netns. Plus, we've put commands in zebra, which we probably will have to remove them to make this work (unless you can sketch a design where we don't?). regards, -- Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A Fortune: I either want less decadence or more chance to participate in it. _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev ************* Email Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you! _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
