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

[Jamal H. S. <ha...@zn...>]

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 NLFE 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 propogates 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.

> -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?

> 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 labelling 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 entitiy is holding a ref (IPv4/IPv6/MPLS
>   tunnel interface)
> - Begining of seperation of sysfs code.  I love the sysfs code, but it needed
>   to be seperated 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 userland API compliant between the implementations.
> 
> After netlink comes LSP loadbalancing (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 modifing 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?

> 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. 

Thoughts?

cheers,
jamal