[mpls-linux-devel] XFRM (was Re: 2.6 Spec: Random comments.)

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

Last time CC'ing David.

I just wanted to get David's take on using XFRM for the Layer 3 to MPLS
mapping which would utilize dst stacking?

It XFRM capable of doing this, any pointers as to where to start?

On Fri, Feb 13, 2004 at 09:09:08AM -0500, Jamal Hadi Salim wrote:
> 
> Maybe we can move this discussion to the list and leave
> Dave alone; we can ping him when we need to verify things from him.
> I am trying to cc the list as a test.
> 
> On Fri, 2004-02-13 at 06:26, Ramon Casellas wrote:
> > Some comments,
> > 
> > (I'm still reading the spec, and slowly looking at the main entry points
> > and hooks in the code, so please be patient and bear with me)
> > 
> > 
> > RCAS 20040213: I see the utility of FEC Id, but I am not fond of the name.
> > The name Fec Id implies that it is "a FEC identifier". 
> 
> Essentially it is an identifier of a NHLFE entry. 
> So you are right naming it a FEC identifier may not be the best.
>  
> > What worries me is
> > the mapping FECId -> NHLFE (for example, in LSP merging, two FECids could
> > be mapped to the same NHLFE index), and the fact that a FECId should be a
> > member of a NHLFE entry...
> 
> I dont wanna call the so-far-called fecid lspid but it is close.
> 
> > Moreover, core LSRs should be FEC agnostic. This was my main comment last
> > time. Basically, the FECid is the label itself. The label implicitely
> > identifies the FEC as is the "key" to use to forward the packet. Otherwise 
> > you have at the same time label mappings and fecid management (signalling 
> > protocols)
> 
> I wouldnt call it a label at all. It is the key used to search the
> NHLFE. Some implementations dont allow setting of such a parameter (one
> of the vendors i looked at did actually) - they will tell you what it
> is. Essentially it is an identifier of a NHLFE entry (not index). 
> A collection of these NHLFE entries could be used by the same LSP.
> There is a further entry that can be used to store extra LSP info
> (refer to parameter "index")
> 
> Given the above info, suggest a new name. Maybe NHid?
> 
> > 
> > 
> > "ILM and FTN derive a FECid from their respective lookups"
> > 
> > I would propose :  "ILM and FTN derive a [list of - multipath] NHLFE index
> > [es] from their respective lookups [...] These indexes and incoming
> > labelspaces are then used to lookup the NHLFE to determine how to forward
> > the packet."
> > 
> 
> 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.
> 
> > A standard structure for NHLFE contains:
> > - FEC id 
> > 
> > RCAS: Is this field really necessary)? a NHLFE entry could be shared by
> > several 'FECsId'...
> > 
> 
> Look at my description above.
> 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
> the point of NHLFE entry selection this value is used to override/select
> the NHLFE entry.
> 
> 
> > And a couple of questions (please consider them as questions from someone
> > who has limited experience in kernel programming)
> > 
> > * I think that adding struct mpls_nhlfe_route *mpls to a dst_entry is a
> >   little intrusive, and somehow the "genericity" of the DST is being lost.
> >   Would not it be better to use :
> > 
> > struct mpls_dst 
> > {
> > 	union
> > 	{
> > 		struct dst_entry        dst;
> > 		struct mpls_dst        *md_next;
> > 	} u;
> > 	....
> > 
> > and manage MPLS dsts from the mpls subsystem? I understand that using your
> > approach it is easier to get MPLS information from skb->dst->mpls but I
> > don't know, it seems a too strong coupling between MPLS and generic dst
> > management. Well, just food for thoughts.
> 
> 
> 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.
> 
> cheers,
> jamal

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