The MPLS WG Archive

[Dan Tappan <tappan@cisco.com>]

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.