The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Dan,

I know that doing a fine level ECMP is best for load balancing. But it seems that
your ONLY goal is to preserve the fine level load balancing, without looking at other aspects which might be negatively affected by doing so. 

I don't believe people want to do perfect load balancing, at the expense of breaking other properties of MPLS. For example:

1) what would L3PID mean any more in MPLS signaling? would that
be deprecated? If not what happens if the L3PID in the signaling does not match the 
PID in the payload? Who is going to detect that and what error message or actions should be taken? 

2) what happens to other proprietary ECMP implementations? should only the implementations checking the first nibble to detect IP be supported or all others too? what if an ECMP implementation checks the checksum to detect IP (which is much more reliable than checking the first nibble)? if the PID is standardized to cater for the first nibble, then should it also
cater for the checksum too? In other words should we state that when standardizing a PID, octets 11 and 12 of the payload should not result a valid checksum over the first 20 bytes?

3) How do you solve the ECMP for the case that a reserved label is used is the stack?

4) What does IPv4/v6 null mean in the future if the PID is standardized? will they be irrelevant? if not what happens if the PID and explicit null don't match?

Please see specific comments in-line.

-Shahram

>-----Original Message-----
>From: Dan Tappan [mailto:tappan@cisco.com]
>Sent: Monday, March 31, 2003 7:42 PM
>To: Shahram Davari
>Cc: 'Lloyd Wood'; pwe3@ietf.org; mpls@UU.NET
>Subject: RE: [PWE3] MPLS PID 
>
>
>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"

I assume you mean PHP.

>- and where the packets being carried are IP

If you know that the payload is IP why do you need PID?

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

You could always use incoming label stack, or even incoming port
for ECMP decision. Or if as you said you know the payload is IP
the use the IP header (which would be non-standard).

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

If you know payload is IP use IP header, if you don't know then use
label stack.

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

As opposed to you, I have no implementation and am not protecting
anybody's implementation. I am just stating what is the right architectural
thing to do. 

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


Because you are trying to be backward compatible with some proprietary
implementations but do not want to be backward compatible with pre-standard
implementations? Has a proprietary implementation more weight that a pres-standard
implementation?

Also there are other reasons that I have stated at the beginning of this email.

-Shahram


>
>
>