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

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

Hi Jamal,



See comments below,


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, and it may happen
even more often in the future with GMPLS. Different signalling protcols
may be used. You don't even need to be aware of GMPLS to need this (e.g.  
RSVP-TE for Traffic Engineered core and LDP/MP-iBGP for client route/pweid
signaling). Basically, I see it like an entity that pushes a label may not 
always know the stack depth. Anyway, James is more knowledgeable that I 
am, so he ay correct me if I'm wrong.







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








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



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



Regards,
R.