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

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

On Mon, Mar 29, 2004 at 09:04:14AM -0500, Jamal Hadi Salim wrote:
> Hi guys,
> 
> I am gonna stop apologizing for not responding on timely fashion. 
> Currently, this is beyond my control with the new baby.
> 
> On Fri, 2004-03-26 at 09:10, Ramon Casellas wrote:
> 
> > On Fri, 26 Mar 2004, Jamal Hadi Salim wrote:
> > 
> > > 
> > > Is this _always_ the case or mostly the exception?
> > 
> > To the best of my knowledge, it happens quite often,
> 
> Good enough; my experiences are it is on the exception side however
> if you guys say it aint then it aint.

I have never seen nor heard of a RFC or even a draft which describs
a protocol which distributes more then one level of label.

> > > > 3) The layer of indirection cause by the 'stacked' NHLFE allows
> > > > for fast fail-over by modifying only the bottom most NHLFE.
> > > 
> > > Isnt editing that NHLFE entry sufficient?
> > 
> > I have always thought that being able to specify the last instruction 
> > of a NHLFE 'a' to be "and now go follow NHLFE 'c'" provides a great amount 
> > of flexibility. I vote for being able to "chain" opcodes. In two cases:
> > 
> > - In instructions are chained to a NHLFE instructions
> > 
> > - NHLFEntries may refer to another NHLFE
> > 
> > NHLFE a:
> >  push 10
> >  goto c
> > 
> > NHLFE b:
> >  push 11
> >  goto c
> > 
> > NHLFE c:
> >  push 40
> >  fwd
> > 
> > by changing c I can engineer at the same time a and b. As James stated: 
> > path protection, LSP modification, even if it is not *strictly* required I 
> > think it may be good design and does not impact (noticiably) performance.
> > 
> 
> This is fine for fast failover; challenge is it may end up being an
> expensive thing when trying to scale (2 lookups instead of 1 for one
> that says "goto c" - the cost could really add up at high speeds).
> Also, from a semantic view - doesnt the view of what a nhlfe change now
> with "goto c" syntax.
> We should still strive to have the MIB modelling as example apply
> (NHLFE table, ILM table etc). 

The data stored with the FWD instruction would be a pointer the the
next NHLFE.  Therefore no lookup is done.

> > > Ok, generally i understand what you are proposing (i think) - to
> > > reiterate 
> > > 1) both the ILM and NHLFE should have opcodes in them 
> > 
> > yes. In instructions and out instructions.
> > 
> 
> For the sake of progress i would say lets move on and have this in.
> So where do we go next?
> I am going ot setup the uml thing on my laptop. Actually i need
> to install Fedora on a PC at home and use that as the real environment
> for this.
> 
> > 
> > > 2) a tunnel device
> > 
> > nice to have.
> > 
> > So DaveM code + In/Out instructions + tunnels + stacking entries = JLeu 
> > code + DaveM improvements. I agree that some parts are indeed not required 
> > (procfs, sysfs) but they are there for historical reasons and in the 
> > process of getting migrated.
> 
> Lets leave sysfs and profs last; i think we need to iron out the issue
> listed. We should really shoot to integrate something soon into the
> 2.6.x kernel. Lets make small releases - any suggestions?
> Ramon, do you wanna list all outstanding issues discussed so far - so we
> can see which one we attack incrementally?
> I dont think Davem will have any issues with the dst stacking code so
> that could be one of the first things that goes in;

I have created a seperate branch off of 'mpls-kernel-davem' called
'mpls-kernel-merger'.  It is where we can submit changes.  Every once in a
while we can look at the diff between 'mpls-kernel-davem' and
'mpls-kernel-merger' and decide what gets propogated to 'mpls-kernel-davem'.

This next week is going to be very busy for me, so I will not be able to
do much development.  Here is how I propose we start:

-I will submit the dst stacking code.
-rename all structures to proper names
    s/mpls_nhlfe_route/mpls_nhlfe/
    s/ltable/mpls_ilm/
-add instruction list to ILM and NHLFE
-move NHLFE label and nexthop to instructions
-move ILM -> NHLFE connection to instructions
-modify netlink to better take advantage of the new structure

I was planning to take much of the code from our implementation and
modify it to work in the DaveM code.

> cheers,
> jamal
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

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