Hi Nicolas, "vrf-lite" I referred is not policy based routing, but I agreed with you that simply call VRF.
Just curious, do you have link to the corner case that can't be solved by implementing VRF? Thanks, Andrew -----Original Message----- From: Nicolas Dichtel [mailto:[email protected]] Sent: Wednesday, May 20, 2015 9:03 AM To: Andrew Qu; Jafar Al-Gharaibeh; [email protected] Subject: Re: [quagga-dev 12336] Re: VRF and Multiple-Instance OSPF Hi Jafar and Andrew, I think that both development are complementary. The point that bother me is to call this 'vrf-lite', it seems to be more policy based routing. As you said, we can easily imagine a scenario with netns + multiple routing table. Calling it vrf will confuse the user. With only multiple tables, you cannot assign the same address multiple times for example. VRF is usally more complete. On netdev mailing list (linux networking kernel), several people already report that, with multiple table, some corner case cannot be solved when they tried to implement VRF. Note also that there are develomement in the linux kernel to ease VRF usage and scalability. For example, Eric Biederman has recently post a patch to lighten the size of a netns. I've also post some patches to be able to assign an id to peer netns and ease netlink management. Regards, Nicolas Le 19/05/2015 19:48, Andrew Qu a écrit : > Hi Jafar, > > We noticed 6wind’s VRF implementation, but from networking > perspective, namespace approach Is more like virtual-router approach > rather than vrf-lite, it is too heavy and does not scale to say > 4000 VRF or more in a data center switch. > > Logically it should be more like this: a physical switch/router may > have multiple-virtual router/switch (which is by namespace), then > within each namespace, there are still needs of VRF within each Namespace. > > With our approach, user now has choice to use namespace to create > virtual router/switch as Independent administrative domain, and then > within each namespace (administrative domain) you can then support VRF within > that domain. > > As far ID part question, it is more to co-work with Linux the way VRF is > implementing. > Linux have name-id pair, hence if user using our created CLI to create > a VRF, internally We will allocate a unique ID which will be taken by Linux > kernel to create VRF table. > You don’t need to “input” ID, but you will see what ID is bind to the name > using “show” cli. > > Thanks, > > Andrew > > From: Jafar Al-Gharaibeh [mailto:[email protected]] > Sent: Tuesday, May 19, 2015 7:26 AM > To: Andrew Qu; [email protected] > Cc: [email protected] > Subject: Re: [quagga-dev 12336] Re: VRF and Multiple-Instance OSPF > > Andrew, > > Nice work and a well written design document. I skimmed through the > document and here are a couple of quick comments/questions: > > The VRF implementation in this case takes a different approach than that > of 6wind's. > 6wind's VRFs are bound to different network namespaces, but in your case > VRFs are bound to different kernel routing table > within the same network namespace (normally the global one). Is that > correct? > > Section 7.1.1 describes how to create a new vrf table by using the command > Router(config)# ip vrf NAME > % bind table name NAME with id ID. > > I don't see ID in the command, was it supposed to be ip vrf NAME ID? > Does the ID refer to a kernel routing tabel id that is already created > outside Quagga, or does the command actually creates a new kernel routing > table? > > Thanks again for sharing this, > Jafar > > > ************* 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
