The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <3E8B675D.6010204@level3.net>, Luca Martini writes:
> 
> Too late, I wish we stop calling those bits EXP, they really are Class of 
> service (COS).


Maybe the experiment is over.  In any case they are not the only way
to support service classes and we'd have to rename unsignaled E-LSP to
unsignaled C-LSP, etc.

Curtis


> 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 afte
> r
> > the label stack.  What if we trimmed it to 3 bits and threw it in the botto
> m
> > 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 conver
> t
> > 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 ada
> pt 
> 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.
> >>
> > 
> > 
> 
> 
>