The MPLS WG Archive

[Dan Tappan <tappan@cisco.com>]

At 02:40 PM 3/31/2003 -0800, Shahram Davari wrote:
>I agree with Lloyd. Sniffing IP packets in the middle of an MPLS network 
>is fundamentally wrong, and is impossible to do for all ECMP 
>implementations such as the one that I described
>in earlier emails in which both the first nibble and the CRC are used to 
>detect IP.
>
>The best way to solve this problem is to do ECMP only based on label stack.

You keep talking about using the label stack. Consider the case:
- at the end of an LSP, where the forwarding operation is "pop and forward"
- and where the packets being carried are IP
- and there is ECMP on the output paths

How is one supposed to make the ECMP decision in that case? There's only 
one label, so hashing on the label stack will only choose a single path.

And don't say "well, it's ok to look at the IP packet in that case". If 
it's "fundamentally wrong" to look at the data, as opposed to the label(s), 
in the packet to make an ECMP decision in the middle of the LSP, then it's 
"fundamentally wrong" at the end.

Or is that case acceptable, because the particular pre-standard 
implementation that you're trying to protect won't encounter it?

Is it a layer violation for an IP ECMP implementation to look at the 
TCP/UDP ports when spreading the traffic over paths? Or to look under an 
IPinIP tunnel header? Or for a WFQ implementation to look at any packet 
fields? Maybe, but there can be practical value in doing so.

For that matter, if we're worrying about layer violations, why is it ok to 
look below the top label (as in "hash the label stack"). Isn't that also a 
layer violation?

If your answer is "you know what the labels are, but you don't know that 
what the encapsulated data is" then that's the whole point of this PID 
discussion.

IMO, if you want to make an argument based on architectural purity and 
"layering" then you need to stick with the top label. In any other case 
we've decided what we are,  we're just arguing over the price.

But, in fact I don't accept that any of these are layer violations. In all 
these cases, the fundamental forwarding decision is on the outermost 
header. Any examination of underlying data is simply selecting finer 
granularity of flows.  In most of these discussions "layer violation" is 
simply a debating trick, holding out for OSI architectural purity as when 
all else fails.

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 simple facts are:
- it turns out that [2] has value operationally, otherwise we wouldn't be 
having this discussion
-  there is a proposal on the table which provides a backward compatible 
way to achieve [2], without affecting any fielded, standardized, 
implementations.
-  the only negative impact of the proposal is on existing implementations 
of pre-standard drafts. And we all know the risks of implementing prior to 
standardization. Even there, an operator can deploy the pre-standard 
implementation, as long as they avoid [2].

Why isn't this a no-brainer?