The MPLS WG Archive

["James R. Leu" <jleu@mindspring.com>]

I've been quietly following this thread, but I would like to add my $.02(US).

One of the proposed solutions to this problem is to add a 4 bit nibble after
the label stack.  What if we trimmed it to 3 bits and threw it in the bottom
most labels EXP bits?  A side effect of this is that networks that utilized
hierarchical E-LSPs would be forced to convert the inner LSPs to L-LSPs.
Although I thought at one point EXP bits were being "promoted" to the outer
most label, but I'd have to go back add read the diffserv draft to verify.
If this were still the case then this would free up the EXP bits for all
labels below the top of the stack (thus alleviating the necessity to convert
inner E-LSPs to L-LSPs).  Even if EXP bits are not being "promoted" forcing
networks to switch to L-LSPs I think is a minimal cost to gain a finer
granularity of ECMP.

Some might consider it a hack some might consider it an optimization, I
like to think of it as a compromise ;-)

Jim

On Wed, Apr 02, 2003 at 10:01:43AM -0500, Dan Tappan wrote:
> At 09:15 AM 4/1/2003 -0500, David Allan wrote:
> 
> >1) are we going to permanently break the paradigm where labels are PIDs?, 
> >because that's where we're headed. IMHO that's fairly fundamental. MPLS 
> >cannot just carry "anything" via signalled convention, because 
> >intermediate boxes are making their own assumptions as to what the payload is.
> 
> I believe that I addressed this point:
> I wrote:
> >  As I see it there are two possible approaches:
> >
> >1. Require that an LSP set up for an IP L3PID or IP FEC carry  IP packets.
> >2. Allow non-IP packets on such an LSP, but  require that they 
> >be  distinguishable.
> 
> The immediate situation is that we have cases where a TE LSP is signalled 
> using L3PID==IP, or an LDP LSP is setup for an IP FEC, but the encapsulated 
> data (under a multi-level label stack) is not IP.
> 
> You seem to be arguing in favor of [1] - requiring a strict interpretation 
> of the L3PID, which means those packets should never be injected into that 
> LSP. That's an internally consistent model, and it's the one which was used 
> during the arguments which removed the L3PID from the original MPLS 
> encapsulation. Unfortunately it seems to fail the reality test - if there 
> were not operational benefit in violating [1] then we would not be having 
> this discussion.
> 
> >2) if we codify snooping the first nybble, it still does not fix ECMP 
> >hashing of reserved labels, we're still in the woods. We also hang out to 
> >dry work in PWE3 and other SDOs that are not compliant with this "new" 
> >convention.
> 
> Either I'm missing your point or this is a red herring. Fundamentally, any 
> ECMP algorithm needs to be designed to avoid misordering flows. If someone 
> implements an algorithm that uses a hash of the label stack then it needs 
> to avoid fields which are not constant for a flow. IF we codify standards 
> which require arbitrarily inserting additional labels into a stack then it 
> can certainly impact an ECMP algorithm which depends on the contents of the 
> stack. So we can have a whole separate argument about whether that is a 
> good idea.
> 
> BUT, that is all orthogonal to the issue of whether it 
> should-be/needs-to-be possible to distinguish an IP from a non-IP packet on 
> an IP LSP.
> 

-- 
James R. Leu