Hi all, I fully agree; let's move to the "domain" name for this feature. Then high level part of the feature can be summarized into: "quagga is able to manage several routing tables/domains, period.".
The "low level" part is: how do I feed kernel with those tables; and this is directly correlated to what those different tables are used for : populate netns, VRFs, MRFs, any mix of indirection levels, etc. which is of course very OS-dependent. Best regards, Alain On 06/05/2015 10:44 AM, Donald Sharp wrote:
Cisco supports logical routers( ala VDC's in the NX/OS line), it's purely managed at the application level though. Logical Routers(or VDC's) are roughly equivalent to the set of patches you have put forward though, especially with how the netns completely separates the processes. This is the reason why in our OOB conversation with Vincent that we argued for calling the construct something else besides VRF's. To much baggage with expectations on behavior. This is the same reason that we are calling our 'VRF' implementation 'MRF' instead. I wouldn't attempt to match the Cisco cli since you are going to put forward a patch to name this feature domain's. donald On Fri, Jun 5, 2015 at 3:05 AM, Nicolas Dichtel <[email protected] <mailto:[email protected]>> wrote: Le 04/06/2015 19:36, Jorge Boncompte a écrit : El 04/06/15 a las 14:10, Nicolas Dichtel escribió: From: Feng Lu <[email protected] <mailto:[email protected]>> We realize VRFs with linux netns by default. The main job is to associate a VRF with a netns. Currently this is done by the configuration: [no] vrf N netns <netns-name> Wouldn't be better if this command were in a Cisco compatible syntax? Does Cisco support Linux netns? I'm not aware of that, so like any non Cisco related Quagga's feature, we cannot create compability syntax of something that does not exist ;-)
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
