Paul, On 10/20/2015 5:04 AM, Paul Jakma wrote: > On Mon, 19 Oct 2015, Lou Berger wrote: > >> What your describing here sounds like logical routers vs VRFs. > What do you mean by that exactly?
The three levels of virtualization of routing functions I see pretty commonly are: 1) VM based (aka VNF): where there's a hardware owner which allocates certain resources to a virtual platform and then leaves it to the VM user to configure/operate as the see fit. VMs never share processes, data structures, etc. Communication between VMs is via a standard (IP/ether, virtual or physical) network interface. Quagga clearly supports this today. 2) Logical system/router/chassis/element based (lots of vendor specific names here) Where the hardware owner again allocates resources to the LR, and then maintains visibility into the LR. Management of the LR may be delegated to the LR user/customer. Inter LR communication is again via a standard (IP/ether, virtual or physical) network interface. LRs can be implemented in a number of ways. I believe most prefer different processes per LR mainly for fault and management isolation. I see the current multiprocess NS approach as falling into this category. 3) VRFs and VSI (virtual switch instance) Here too (logical or physical) interface and other resources are assigned to a VRF. VRFs are always (at least in my experienced) managed within the context of a single (logical or physical) router. There may be no routing/interaction between VRFs (often called VRF-lite); routes may be leaked/imported/exported between VRFs; and tunnel interfaces may be exposed from one or more "core" VRFs (ala BGP VPNs). There are certainly many ways to implement the process/thread support for these. I see the VRF support of zebra as an important enabler. As I mentioned on the list before we have support for BGP VPNs (RFCs 4364, 4659,, 5512, 5566) that we'd to submit back , but demonstrating/testing this outside our internal environment has been a challenge and the zebra VRF code gives us a clean path to forward. Our implementation is single BGP process - but certainly could be restructured to be by multi-threaded or multi-process once the code is incorporated. Of course these three categories are a bit of an over simplifications and there are many ways that could and have been done. > Is there a perception here that 1 daemon : 1 VRF makes it impossible to > share routes between VRFs? That shouldn't be the case though. E.g., a bgpd > in one netns should still be able to communicate with a bgpd in another > netns via a filesystem name-spaced socket, and exchange routes. So > inter-VRF route sharing should still be quite feasible. Sure. I think it's really important to first keep the (a) route sharing/leaking models and the (b) management models in mind when talking different types of routing function virtualization, and then talk process/thread models. I >> My hope is that the next release would provide support in at least zebra >> and provide a platform of for those of us interested in doing multi-VRF >> protocol work. > The issue for me is that if the only option we have for VRF is to continue > with a fixed set of single-threaded processes, that we are going to > entrench Quagga's reputation for not scaling up with increasing numbers of > CPU cores. Well, IMO this is a separable discussion and that wanting to solve one (VRF or multi CPUs) shouldn't hold up solving the other. I do think/agree that both are important. Lou > > regards, _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
