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

[Ramon C. <cas...@in...>]

On Fri, 13 Feb 2004, Jamal Hadi Salim wrote:

disclaimer:

from now on, all mails will be sent to mpl...@li... (
that is what I wa going to do, but then i received your email about the 
mailing list failing) 


 
> Essentially it is an identifier of a NHLFE entry. 
> So you are right naming it a FEC identifier may not be the best.

So the relationship is:

1 FEC F                         to      N available objects 
1 Incoming Label/Labelspace     to      N available objects


> I dont wanna call the so-far-called fecid lspid but it is close.

I see what you mean. Let us check what the RFC says:
   The "Incoming Label Map" (ILM) maps each incoming label to a set of
   NHLFEs. (...)


   If the ILM maps a particular label to a set of NHLFEs that contains
   more than one element, exactly one element of the set must be chosen
   before the packet is forwarded.  The procedures for choosing an
   element from the set are beyond the scope of this document.  Having
   the ILM map a label to a set containing more than one NHLFE may be
   useful if, e.g., it is desired to do load balancing over multiple
   equal-cost paths.

(RCAS: N.B. you don't need equal cost paths)...

> Given the above info, suggest a new name. Maybe NHid?

I would say something like a "fwd_id" from "Forward Id", or "out_id" it 
should not prelude one or other Next Hop.
 


> 
> Ok, that is useful. I have not tested multipath but it should


> Also i would think most of these lists would contain a single entry.

Yes, unicast MPLS with no load sharing enabled. However, you may need them 
when doing multicast and/or load sharing.



> BTW, the ILM is not multihop ready. We should be able to add easily.
Do you really need it to? Just hold a set of fwd_ids. The policy to select 
one should be configurable (discipline) & pluggable. A common impl. Is a 
hash table.

The RFC also defines the interaction with routing in this case. (although 
vaguely)


> The ability to select this value by policy allows us to be able to
> select the NHLFE entries from other subsystems; eg a u32 classifier
> on ingress could select all IP addresses from 10.1.1.1/24 to have a
> fecid of 10. The skb->fecid is then set to 10. When the packet gets to

I see, but as long as it is not called fec_id, it's fine :) call it 
fwd_id.


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

I am not sure that you need to. This is what was done in James' impl.  
mpls_dst. The only thing you need is a means to allocate mpls_dsts and
hang the reference into the skb's dst. The advantage is that you don't add
another member to dst (I still don't like adding a mpls ptr to a generic
dst, but I assume you are far more knowledgeable than I am), but of 
course, you still have to modify the skb dst. (e.g. release it and hold a 
new reference).



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

Well, I though we agreed on doing it the right way :) I am not stating 
which one it is though.



In  mpls_unicast_forward

        lt = (struct ltable *)skb->dst;
        skb->dst = &lt->u.dst;

would not it be possible here to allocate a mpls_dst with a new dst_ops 
with the right size?




comment: I *do* think that mpls_tunnel.c from James impl can directly be 
used and it's very convenient. Just %s/moi/fwd_id/g

Ramon.