Re: [mpls-linux-devel] Re: 2.6 Spec: Random comments.

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

On Fri, 2004-02-13 at 09:39, James R. Leu wrote:

> > Given the above info, suggest a new name. Maybe NHid?
> 
> Much better then FECid ;-) (although it is just a name ...)

True, but has to map to the semantics;
Ok NHid for now until something with a better ring shows up.


> > 
> > Ok, that is useful. I have not tested multipath but it should
> > work with Linux routing ECMP at least. 
> > I wouldnt call it NHLFE indices rather these identifiers so far
> > called fecid;
> > Also i would think most of these lists would contain a single entry.
> > BTW, the ILM is not multihop ready. We should be able to add easily.
> > Also there is no controil on how the multihop selection is done with
> > the linux routing table - whatever Linux ECMP does goes.
> > We should be able to fix the ILM with an algorith selector.
> 
> After looking at the code I would agreed that whatever linux multiple does
> at the ingress LER, this code will follow.  The real question is how to
> go about supporting multipath as an LSR? (one ILM needs to load balance over
> multiple NHLFE).  Or dare I suggest p-mp LSPs?
> 

Ive actually done some background compute on this in my head at least.
Here are my thoughts on paper or electrons:
ILM table entry (struct ltable in the code) should have a new structure,
call it nh_choice, which has the following entries:

function selector();
struct nh_info nh_list; 

nh_list would look like:
struct gnet_stats	stats;		/* stats */
u32			lt_fecid;    /* change that to ilm_nhid */

Note the above two entries currently reside in struct ltable.

A packet coming in will have the usual lookup; the entries
nh_choice->selector() will be invoked. It will return the
nhid.
The idea behind the selector() is we can attach different algorithms
via policy and make them take care of things like paths being down etc.
I can think of two simple algorithms right away: random selection and
RR. The idea is to open these algorithms to innovation.

>From user space this would look like:

l2c mpls ilm add dev eth0 label 22 nhalg roundrobin nhid 2 nhid 3 nhid 4

etc.

Thoughts?
 
> 
> I know you mentioned it is "not an index" but to me it seems like it really
> _is_ an index for the NHLFE. Can multiple NHids correspond to the same NHLFE?
> If it is a 1 to 1 mapping for all intents an purposes it is an index :-)

Ok;->
how about NHkey ? maybe a prefix of mpls_ would also be good.

> > dsts are still managed from the MPLS code. There is some generic stuff
> > (create, destriy, gc etc) for which there is no point in recreating in
> > the MPLS code
> > The way it is right now works fine. What could probably have been a
> > better approach is to stack dsts. It would require some surgery and i am
> > not sure i have the patience for it. Mayeb we can ask Dave on his
> > thoughts on this.
> 
> Currently we use dst stacking.  The 'child' dst is actually a static member
> of the 'out going label info' (NHLFE).  So when the skb reaches the the exit
> of IPv4|6 a check for the child is done.  The skb->dst is replaced with the
> child dst and the child output funtion is called (which sends it into
> MPLS land).  The entrace to MPLS land use "container_of" macro to get the
> NHLFE to used to forward the packet.  How the stacked dst is created is
> similar to your scheme.  I was wondering is XFRM is a better scheme to use
> for all of this?

sorry i meant XFRM.
I am indifferent whether we change it to your scheme or leave it as is.
I will have to look at your code to make better judgement. My thinking
would be the end goal should be NOT to touch the IPV4/6 code with ifdefs
unless necessary. If theres not a huge difference in terms of eficiency
or code beautifaction i would rather stick to the current code.
BTW if you point me to the latest code i will print it and read offline
over the weekend if possible.

I may be a bit slow responding now since i am at work.

cheers,
jamal