Re: [mpls-linux-devel] Current state of dst stacking on davem implementation

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

See comments in line.

On Mon, Mar 22, 2004 at 08:38:29AM -0500, Jamal Hadi Salim wrote:
> James,
> I really meant to respond to this sooner, but i suppose i am still faced
> with glitches.
> 
> On Fri, 2004-03-19 at 11:40, James R. Leu wrote:
> > Hey guys,
> > 
> > Here is my list of "issues" with the davem implementation:
> > 
> > -no handling of exceeding MTU, or to changes in devices MTU
> > -reserved label values are not restricted nor handled
> > -no support for flushing all ILM/NHLFE
> > -no handling of PUSH when SKB has no space
> > -tcpdump of egress LSR shows packet twice, once with MPLS header once without
> > -NHLFE structure has issues
> >     -same NHLFE cannot be used by transit LSP and locally originated traffic
> >         -Think of LDP with ordered control where an LSR could be ingress for
> >          a FEC as well as transit. (LSR received label mapping, it decides it
> >          can be ingress for the FEC, and then propagates the mapping, result
> >          it that the NHLFE is tied to a route entry and well as a ILM.  ILM
> >          needs XCHANGE, route entry needs ADD).
> >     -there is no such thing as a labelspace for NHLFE, it should be removed.
> >     -NHLFE hashing does not allow for same label mapping to be received
> >      from multiple peers in the same subnet
> >         -Think of an LSR speaking RSVP-TE connected to a ethernet subnet
> >          with 2 other RSVP-TE speakers.  RSVP-TE LSPs are requested from
> >          each of the other RSVP-TE speakers, they both advertise back the
> >          same label value.
> >     -does not allow for re-use of NHLFE when stacking
> >     -extra fields which would not be used when stacking
> 
> To be fair, all the above are resolvable issues. Some are even
> mentioned in the TODO list.

Some are quite trivial, but some require changes to the architecture.

> > -no support for LSP hierarchy (ingress or egress)
> >
> > The "no support for LSP hierarchy" is only one element in the list, but
> > it is a fairly large issue.
> 
> I didnt understand this one. Did we discuss this?

I mentioned in a previous email that evaluating the current architecture
without considering LSP hierarchy was a bit foolish.

> > Since I didn't want to make large changes to the davem code without discussion
> > I have been spending my time integrating the positive features of the davem
> > implementation into mine.  This consisted of adding the protocol driver
> > model and making better use of the the dst_entry to guide skb's through
> > the MPLS stack.
> >
> > In the process I've:
> > - implemented MPLS-ICMP for IPv4 (which has been implemented by vendors,
> >   but is only in draft form. It works with the NANOG patch to traceroute
> >   to show the labeling info.)  It is kind of a hack because I build the
> >   entire ICMP payload by hand.  I'm looking at ways to utilize the existing
> >   IPv4 ICMP code. (as an aside, it is cool to use an MPLS enable traceroute
> >   and see all of the providers who are using MPLS :-)
> > - the ICMP path has been modified to allow for offending messages to be
> >   replace by ICMP messages and forwarded along to the end of the LSP where
> >   the egress can handle it.
> > - the refcnt'ing code has been modified to disallow removing in/out
> >   information when some external entity is holding a ref (IPv4/IPv6/MPLS
> >   tunnel interface)
> > - Beginning of separation of sysfs code.  I love the sysfs code, but it needed
> >   to be separated so MPLS can be compiled without sysfs support.  The sysfs
> >   support also makes the implementation look more complicated then it really
> >   is.
> > 
> > I've just started adding netlink support.  My goal is to utilize all of the
> > netlink infrastructure Jamal added to the Davem implementation.  I want to
> > be user land API compliant between the implementations.
> > 
> > After netlink comes LSP load balancing (ILM based) using some of the schemes
> > we discussed previously.
> > 
> > In addition I've spent a lot of time working on a generic MPLS infrastructure
> > for quagga.  I'm to the point where I now need to add OS level support for
> > the various MPLS components.  I will make sure to write versions for
> > my code as well and the davem code.
> > 
> > I still think the best path going forward is to enhance my implementation
> > to be more agreeable to DaveM (I'm not sure what, if any, issues remain).
> > If you guys still think that the easiest path to adoption of MPLS code into
> > the Linux distribution is by modifying the DaveM code, I'll continue to help
> > out as much as possible, but we need to starting talking about making some
> > big changes.
> 
> The problem i am faced with is to come up with some strong reasons to go
> back to Dave. It will be unfair to him if we go back now - after all the
> time we passed - and say we decided to junk all the code he has written
> (and is willing to maintain). We need some strong reasons to make
> progress for inclusion. What you have listed seems to me as something
> someone with time can fix. Maybe we can do parallel approach and have
> both coming in together?

I reality the implementations are already converging because I'm flexible
with my implementation and I'm willing to learn from others and have thus
implemented what I see as the positive points of the DaveM code.

The remaining areas of difference are:

-instructions - I have 'ILM' and 'NHLFE' instructions, the DaveM code only
 has 'NHLFE' instructions.  Separating 'ILM' and 'NHLFE' processing in my
 mind is one of the key requirements for supporting scalable LSP hierarchy.
 If the 'single instruction' model is desirable for some configurations, it
 can be accomplished with my 'dual' instructions model, by making all of the
 'ILMs' have one instruction, which FWDs it to a NHLFE for processing.
-storage - I use a generated key for storing 'NHLFE' info, the DaveM code
 uses the label value itself (see above list of issues as to why this
 it bad).  I store the 'ILM' and 'NHLFE' info in a radix tree, the DaveM
 code uses a hash table.
-user input - my implementation does not have a netlink interface (yet),
 I use IOCTLs().  The DaveM code uses netlink.
-labelspace - I have thought out the issues with respect to labelspace and
 and have implemented a 'best of both worlds' scheme which allows the users
 application to implement whatever type of labelspace management they choose.
 The DaveM code only has labelspace 0.
-labeling types - I have support for all labeling types in my code (ATM, FR,
 and generic) and support for multiple interface type (ethernet, PPP, GRE).
 At one point in time I even had direct support for ATM interfaces (has
 since been removed because the ATM stack for linux is not designed for
 routers or switches).  The DaveM code only supports ethernet.
-availability of kernel information - My implementation has implemented
 crude yet effective PROCFS and SYSFS interfaces, the DaveM code has neither.

Basically, if you rip out support for LSP hierarchy, PROCFS, SYSFS, and
a couple other features and add netlink support and convert from radix
to a hash table, you could convert my implementation into the DaveM
implementation.

> > No matter what. I'll still be working on my implementation, if nothing
> > else it is an easy place for me to implement new features which could then
> > be ported to the DaveM code.
> > 
> 
> Maybe we can do this. To me the most valuable thing is to have the code
> merged. And the approach of improving over Davems code seems to be the
> most logical compromise. Perhaps your code can serve as an area for more
> experimental stuff which later gets merged. 

I think we should identify the desirable features of the DaveM code and
my code and decide whether it is easier to propagate the changes from mine
to DaveM or vice versa.  That is just my $.02.

> Thoughts?

If we are still dead set on enhancing the DaveM code, lets decide
what is the first area to focus on and fix it.  I think the most
important area to look at is support for LSP hierarchy.

> cheers,
> jamal
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

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