[quagga-dev 13336] Re: VRF device integration in quagga

Paul Jakma paul at jakma.org
Tue Oct 20 13:09:37 BST 2015


On Mon, 19 Oct 2015, Vipin Kumar wrote:

> Hello Quagga-dev,
>
> Linux community has recently accepted patches for VRF support that realizes
> VRFs as a master device of type 'vrf' (that has a route-table association
> via IP rules). Links can be made part of a VRF by simply using native Linux
> link to master device enslavement.

Interesting.

> I have CCed David Ahern and Shrijeet Mukherjee here, who are the authors of
> this work in Linux. Description and reference to the actual patches can be
> found at:
> https://lwn.net/Articles/654541/
> http://permalink.gmane.org/gmane.linux.network/382285

Just as an aside, there is no known way to achieve:

   Layered routing AND Scaling AND Efficient forwarding

for all hosts on arbitrary networks (e.g. the Internet). It'd be good if 
there more awareness of this in the routing engineering world. :)

There are many sound reasons to use split tables and layering of routing, 
but generally scalable routing just isn't known to be one of them (least, 
not while retaining efficient routing).

> We see this model better aligned to support traditional VRF semantics 
> and modern VRF requirements for the following reasons:
>
>        Management of VRFs/entities within a VRF is easier from a single
> module on system.
>        Resource usage wise, it can be argued that netns model is
> relatively heavier.
>        For route-leaking or any other feature (like BGP/MPLS based L3VPN)
> that requires a component to work with multiple VRFs.
>
> With that, to integrate with VRF devices, we would like to build upon 
> the quagga community accepted VRF lib in zebra. We believe the 
> implementation should be able to co-exist with the netns support (which 
> currently gets triggered based on the 'vrf <vrf-id> netns <path>').

The details of how it gets triggered are open to change at this point. 
Including whether it lives in zebra or somewhere else.

You're going to have figure out how to make your proposal co-exist with 
the other ways though (the semi-functional 'vrf...' commands in there now, 
though see above; the ability to run daemons in namespaces; etc).

> We hope this approach is acceptable to quagga-dev, and useful to 
> quagga-users.

I'd suggest a design document, showing how everything will work in terms 
of the UI, internal protocols, and architecture, to avoid problems down 
the road.

Big changes /can/ be easy to integrate, *if* contributors come to the 
community first with design proposals, work out the details, and get 
consensus. As you seem to be trying to do - bravo. :)

regards,
-- 
Paul Jakma	paul at jakma.org	@pjakma	Key ID: 64A2FF6A
Fortune:
Yield to Temptation ... it may not pass your way again.
 		-- Lazarus Long, "Time Enough for Love"




More information about the Quagga-dev mailing list