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

[Jamal H. S. <ha...@zn...>]

James,
My std apologies for late response ;-<

On Wed, 2004-03-24 at 00:36, James R. Leu wrote:

> The very nature of LSPs (uni-directional) means that an ingress LER
> only TXs on a LSP. (ie only needs a NHLFE).  A separate LSP must be
> setup going in the reverse direction (with completely independent
> label values), and the egress LER will only RX on that LSP (ie only has
> an ILM).  Does that make sense?

Yes it does make sense; the value i saw of NHLFE knowing all details of 
the NH is so that in a purely ingress LER, there will be no ILM
table setup but now i am realizing even in your case there is no need
for any ILM setup.

> > I think we did touch on this - and i did see the value of the tunnel
> > device. For stacking though, why would it be an issue to have all the
> > labels in the same NHLFE entry? You seem to indicate that you need to
> > separate them?
> 
> 1) Separate signaling protocols distribute the label for each layer
> of the hierarchy.  No one protocol has all of the label information
> available to build the entire stack.

Is this _always_ the case or mostly the exception?

> 2) Each layer of the hierarchy can act on its own. (ie the outer most LSP
> can send traffic for the inner LSPs and IPv4 traffic.) Thus the outer
> LSP (bottom NHLFE) might be TXing packets with any number of labels, all
> of which were pushed at this LSR.  The number of labels pushed depends
> on the FEC to NHLFE mapping.

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?

Ok, generally i understand what you are proposing (i think) - to
reiterate 
1) both the ILM and NHLFE should have opcodes in them 
2) a tunnel device

#1 i think was the controvesial part (re the current code) but you
explained the practicality of it. Did i get this correct?

cheers,
jamal