I understand about not wanting to use the 'Cisco' name. We've been discussing using MRF instead of VRF internally because of the baggage that such a term brings to the table.
I'm not familiar with the netdev shred alias, my focus here at Cumulus is less on the kernel and more on routing, but I've added the relevant person to this email thread to keep him in the loop. thanks! donald On Thu, May 21, 2015 at 4:34 PM, Andrew Qu <[email protected]> wrote: > Hi Donald, > > Agreed. I just didn't want to bring Cisco name specific here by saying > logical router instead. > > As for the kernel change, let's discuss this in netdev shred, we'd like > to work with netdev to get the change done > > Thanks > > Andrew > > Donald Sharp <[email protected]> wrote: > > > Network namespaces align closely with Cisco's VDC concept and are > orthogonal to some extent to an actual VRF implementation from my > perspective. As pointed out elsewhere namespaces are heavy weight and > having a large number of namespaces would present serious performance > problems. I think that namespaces could( and should ) co-exist with VRF's. > > > By definition (in RFC 4364), VRFs refer to multiple routing and forwarding > tables with the ability to associate interfaces (attachment circuits) to a > VRF and the ability to have overlapping address spaces. This can be > implemented in Linux by leveraging the existing support for multiple > routing tables, but some kernel enhancements are needed to facilitate > overlapping IP addresses in different VRFs. > > Thanks! > > donald > > On Thu, May 21, 2015 at 1:32 AM, Nicolas Dichtel < > [email protected]> wrote: > >> Le 20/05/2015 20:20, Andrew Qu a écrit : >> [snip] >> >>> >>> The way network namespace is configured and used is as I said earlier >>> more like >>> Virtual router or virtual switch that virtualizing a physical box into >>> multiple >>> Logical real network device, for example: >>> >>> OSPF/ISIS in NamespaceA and OSPF/ISIS in NamespaceB relationthip is >>> network adjacency, >>> A link in namespaceA and a link in namespaceB can be connected and form >>> OSPF/ISIS >>> Network adjacency. >>> >>> As you can't not call two different routers (even they have separate >>> routing table) as VRF, >>> Same way, you can't call namespace approach as VRF. They are just >>> different routers. >>> The routing table managed by namespace is more like routing table >>> managed by physically >>> Different routers, we can't call this as VRF. At least not the VRF >>> term that has >>> Been used by network operators. >>> >>> VRF approach is within ONE logical router/switch that via multiple >>> routing instances or single instance >>> To build multiple routing table which can fall back to one global >>> routing table if >>> Use configured. >>> >> I had some discussions around this topic. A patch that allows to have a >> route >> in a netns that points to another netns make sense and will probably be >> accepted on netdev. >> I really think that the way to go for VRF is netns. And I agree that some >> improvements are still needed in the linux network stack for that purpose, >> but netdev community now agrees with the big picture, thus it's just a >> matter >> of writing the patches ;-) >> >> Namespaces are very flexible. You can build your virtual machine by using >> user >> namespaces. Then have a set of embbeded netns into this virtual machine >> for the >> VRF. And in each netns/VRF, you can do policy based routing. >> With this design, you can handle most of the scenarii without weird >> limitations. >> >> >> Regards, >> Nicolas >> >> >> _______________________________________________ >> 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
