[mpls-linux-devel] XFRM (was Re: 2.6 Spec: Random comments.)
Status: Beta
Brought to you by:
jleu
From: James R. L. <jl...@mi...> - 2004-02-13 14:48:49
|
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... |