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

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

Please see comments in-line.

On Wed, Mar 24, 2004 at 12:09:48AM -0500, Jamal Hadi Salim wrote:
> James,
> On Tue, 2004-03-23 at 23:47, James R. Leu wrote:
> > Jamal,
> > 
> > Before we can talk about LSP hierarchy we need to discuss the
> > single array of instructions on the NHLFE versus an array of
> > instructions on the ILM and the NHLFE.
> > 
> > Their is one main reason for the 'dual' model, NHLFE re-use.
> > NHLFE re-use comes into play for an LSP which an LSR is ingress
> > and transit, and for LSP hierarchy.
> > 
> > In the case where a LSR is ingress and transit for an LSP, a single set
> > of instructions on the NHLFE results in needing to create two NHLFE,
> > one with an ADD instruction, which is used by the ingress code path, and
> > one which contains a XCHANGE instruction for the transit code path.  Where
> > as with a 'dual' model, the instructions on the ILM contain POP and the
> > instructions on the NHLFE contain a PUSH.  The ingress code path only hits
> > the PUSH in the NHLFE and the transit code path hits the POP on the ILM
> > and the PUSH on the NHLFE.
> 
> Ok, I think i understand what you are saying.
> Question: Is it possible that a device could be only interfacing 
> as an ingress LER; i.e it sends MPLS packets into the MPLS cloud,
> but it never receives back MPLS packets? In other words such a device
> may not have any need for a ILM but will need a NHLFE. If thats a yes,
> then there is clear value for the separation, no? I have never heard
> of a setup like this so just curious.

(Forgive me if I'm stating the obvious, it was the only way I could think
of answering your question.  If I missed you point, please elaborate.)

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?  (ie LSPs are not like ATM VCs or ethernet
VLANs where TX and RX occur on the same entity).

> > The reasoning for the 'dual' model with respect to LSP hierarchy is similar,
> > but pertains to NHLFE which are 'stacked'.  (an LSR which adds hierarchy
> > really is just a special case of an ingress LER/LSR, remember that hierarchy
> > can be added at any point in the MPLS domain, not just the edge) The NHLFE
> > for the hierarchy label (an example of a hierarchy label is a VPN label)
> > contains a PUSH and FWD to another NHLFE, which contains a PUSH for the
> > tunnel label.  With this separation the tunnel NHLFE can be used for a
> > transit LSP as well.  This separation also lends itself well to fast
> > fail over between primary and backup LSPs.  Image 1000s of VPN NHLFEs
> > pointing to the same tunnel NHLFE, if the tunnel NHLFE needs to be
> > changed (to fail over to a backup tunnel) we can change just one NHLFE
> > and all of the VPN NHLFEs start using the backup tunnel.
> 
> 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.

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.

3) The layer of indirection cause by the 'stacked' NHLFE allows
for fast fail-over by modifying only the bottom most NHLFE.

> > That is enough for now.  I'm not ignoring the rest of your email, but
> > we can address the other issues/questions/points after we talk about
> > this one.
> 
> np.
> 
> cheers,
> jamal

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