The MPLS WG Archive

[Luca Martini <luca@level3.net>]

Too late, I wish we stop calling those bits EXP, they really are Class of 
service (COS).


James R. Leu wrote:
> 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.

yes they are , exp bits are copied to the pushed label.

> 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.
> 
this is mush more difficult then simply identifying MPLS frames as non-ip. I 
would like to remind you that 99% of the MPLS traffic is IP. And even the 
current implementations of the martini protocol that are deployed end up 
transporting 99% IP over some layer2 protocol. SO it's probably easier to adapt 
the emerging PWE3 application then to try to change the existing base.


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