Re: [mpls-linux-devel] Current state of dst stacking on davem implementation
Status: Beta
Brought to you by:
jleu
From: Jamal H. S. <ha...@zn...> - 2004-03-24 05:10:00
|
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. > 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? > 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 |