Re: [mpls-linux-devel] Moving forward

[James R. L. <jl...@mi...>]

Hello Scott,

On Mon, Jan 05, 2009 at 02:11:03PM -0500, Scott A. Yoder wrote:
> James,
> 
> I'd like to help out with L3 BGP VPNs. In several e-mails on list you mentioned work
> that needed to be done on a label manager and the new network namespaces in 2.6 that
> might be used instead of vrf.

Correct, along with a lot of other areas, but these pieces are pretty core
to the work that is needed.

> I had come to the conclusion that the kernel's implementation of namespaces was not
> well suited for the creation of multiple L3 VPNs from a single process. I see that
> Vivien Chappelier submitted a patchset that allows interfaces and processes to attach
> to a namespace. What is the current status of this patchset and will it be used by
> the mpls-linux project?

You are correct again. The namespace code is meant to provide a
process and it's children access to a private network namespace.
As you saw with Vivien's code it doesn't take much to make the
network namespace implementation useful for VRF type usage. To
that end I've adopted most of Vivien's patches into my VRF tree,
and I will augment them with some additional work (replace the static
number of VRFs with a dynamic scheme).

> I have the latest p4 code (Quagga 0.99.10) checked out and am happy to report that it compiles and runs
> fine in my testbed (simple 2 host 2 LER setup).
> 
> So to get L3 BGP VPN support moving forward which subproject should I start with? The label manager?

Here are a couple of areas to start, note these are just beginings, not
finished products.  I'm also open to other ideas.  For example if there is a
particular area that you find interesting, challenging, or benifits you
in some way, let me know and I'm sure we can make it work.

BGP transmit side
    - a VTY interface to creating VPN4 NLRI with tagging info
    - peer with an existing implementation to make sure they
      get added to the peers correct VRF
BGP receive side
    - implement RFC2547 policy interface
    - apply policy to incoming VPN4 NLRI and put the results into
      different quagga tables (not neccessariy VRFs at this point)
generic VRF quagga infrastructure
    - implement code for a generic interface to creating
      static routes in VRFs which are stored in different quagga
      tables
    - implement various VRF drivers (using linux tables and rules,
      solaris zones?, and linux namespace/VRF, null - just use single
      routing table but warn when overlaping address space is encountered)
    - probably involves modifying ZEBRA protocol ...
support for recursive/hierachical MPLS labeling
    - tagged BGP route that have a nexthop that uses a static route with a
      label attached, the result is a route in the table that points
      to a NHLFE that pushes two labels (or fwds to another NHLFE ...)
label manager
    - sync API for protocols (LDP, BGP, RSVP-TE) to query for a label
      which will be installed as an ILM and distributed to a peer
    - make sure static label assignments do not conflict
    - make sure that 'service' labels (BGP and L2VPN etc) are allocated
      and used only on like labelspaces (most often global)
namespace/VRF kernel work
    - finish API for creating/deleting VRFs

> Thanks,
> Scott Yoder
> ImageStream Internet Solutions, Inc.
> E-mail: sy...@im...
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

-- 
James R. Leu
jl...@mi...