Subject: Re: Load balancing draft

From: Alia Atlas <[email-masked]>
Date: Tue, 19 Nov 2002 10:54:47 -0500

The concept of avoiding the reserved labels in an MPLS hash as a "best way" 
makes some sense, though it would probably only be gradually available as 
hardware changes.  Doing this would make OAM work for pseudo-wires, where 
there is no underlying packet information which can be examined and where 
the TTL is fixed.

But this does change fast-path hardware...

Doing JUST that doesn't have bad impact on load-balancing of microflows (or 
identifying as small a microflow as possible).

Alia

At 07:36 AM 11/19/2002 -0800, Shahram Davari wrote:
>Hi,
>
>One of the criticism for this draft was that it is designed to overcome
>Y.1711 limitation, in which a reserved label is used. As I mentioned
>in the meeting the MPLS-Ping also requires usage of an extra reserved
>label for non-IP carrying LSPs:
>
>   "To test an LSP that carries non-IP traffic, before injecting ICMP and
>    MPLS ping messages into the LSP, the IPv4 Explicit NULL label should
>    be prepended to such messages."
>
>So this draft is equally applicable to MPLS-ping.
>
>Yours,
>Shahram

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 19 Nov 2002 13:27:07 -0500

>The concept of avoiding the reserved labels in an MPLS hash as a "best 
>way" makes some sense,

         Does this mean that we then have to mandate how IP (L2TPV3) does
traffic distribution too?  What is next?    I think that this solution looks
good in theory, but in practice there are huge problems with it.

>though it would probably only be gradually available as hardware changes.

         Kireeti or you made a good point that
this solution is not evolutionary; it is revolutionary as it will require
hardware changes.  On the surface it might sound reasonable to
say that well, hardware will evolve and as it does it must support
this sort of load-balancing. However, the fact of the matter is that
one size does not fit all in this case, and thus this will be a burden
on both existing and future implementations.

         --Tom

>Doing this would make OAM work for pseudo-wires, where there is no 
>underlying packet information which can be examined and where the TTL is fixed.
>
>Doing JUST that doesn't have bad impact on load-balancing of microflows 
>(or identifying as small a microflow as possible).
>
>Alia
>

Success is relative; the more success, the more relatives. -Anonymous

---

From: Alia Atlas <[email-masked]>
Date: Tue, 19 Nov 2002 13:43:26 -0500

The idea is not to mandate how traffic distribution is done.  It's to say 
that the reserved labels should be excluded from consideration in 
determining that.  I'm certainly against anything which increases the size 
of the microflows which can be load-balanced - this doesn't do that, b/c 
only the OAM packets would have those reserved labels.

Which huge problems are you seeing with this?  I'm not saying that it 
should be mandated in anyway, simply that it may be superior design, if one 
chose to implement it thusly.

Absolutely, this isn't something to be required and it is revolutionary in 
that it requires hardware changes.  I don't see how it is a burden on 
existing and future implementations; it is a suggestion for how to make the 
ECMP friendlier.  Didn't we also have discussions about how routers should 
do microflow classification for the load-balancing instead of doing 
round-robin to avoid microflow reordering?  And that  is not what all 
routers do or, probably, will ever do depending on where in the network 
they are...

Alia

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 19 Nov 2002 17:56:20 -0500

At 01:43 PM 11/19/2002 -0500, Alia Atlas wrote:
>should be mandated in anyway, simply that it may be superior design, if 
>one chose to implement it thusly.

         I think it might be a great design if EVERYONE implemented it.
However, I think that is a not possible.

>existing and future implementations; it is a suggestion for how to make 
>the ECMP friendlier.

         It is a burden because some hardware from vendors may not be able to
support the algorithm (i.e.: look at that many labels).  Also your point of
wanting to look at more labels than might be mandated would prohibit
better load sharing behavior.

         --Tom

>  Didn't we also have discussions about how routers should do microflow 
> classification for the load-balancing instead of doing round-robin to 
> avoid microflow reordering?  And that  is not what all routers do or, 
> probably, will ever do depending on where in the network they are...
>
>Alia
>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 19 Nov 2002 22:48:18 -0500

At 05:56 PM 11/19/2002 -0500, Thomas D. Nadeau wrote:
>>determining that.  I'm certainly against anything which increases the 
>>size of the microflows which can be load-balanced - this doesn't do that, 
>>b/c only the OAM packets would have those reserved labels.
>>

The fewer places where the OAM label causes the streams to diverge, the 
better.  This isn't an all-or-nothing.   What I am saying is simply that 
not including reserved MPLS labels in a label hash for load-balancing would 
be a better way of doing the hardware.

It's proprietary now; this is still something which can be proprietary.   I 
am NOT suggesting that the draft go forward and certainly not the way it 
is.  I am simply saying that just as it is "known" that if one is 
load-balancing IP, it is good not to reorder microflows, it makes sense to 
have it "known" that if one is load-balancing MPLS based on the 
label-stack, it would be good not to include MPLS reserved labels.

>>Absolutely, this isn't something to be required and it is revolutionary 
>>in that it requires hardware changes.  I don't see how it is a burden on 

I do not think it is a good idea to control the depth of the labels looked 
at.  This is a vendor-proprietary detail, based on what the hardware can do 
and how much granularity they want in microflows.

Again, all I'm saying is if one is to look at labels for a hash for 
load-balancing, don't include the reserved MPLS labels.  That's it.

Alia

---

From: George Swallow <[email-masked]>
Date: Wed, 20 Nov 2002 09:58:09 -0500

> hardware changes.  

One should observe that the technique is not useful unless you are
100% sure that very box in the path from source to destination is
behaving this way.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Alia Atlas <[email-masked]>
Date: Wed, 20 Nov 2002 10:07:23 -0500

At 09:58 AM 11/20/2002 -0500, George Swallow wrote:
> way"

Why is it not incrementally useful?  Every LSR along the path that does 
this decreases the cases where an OAM packet may take a different route 
from the data packet.   It does require every LSR to implement to 
completely avoid OAM packets from taking different routes, but 
incrementally does simplify determining what happened to the OAM packets as 
compared to the data plane packets because there are fewer potential branch 
points.

Alia

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 20 Nov 2002 10:32:36 -0500

At 10:07 AM 11/20/2002 -0500, Alia Atlas wrote:
>incrementally does simplify determining what happened to the OAM packets 
>as compared to the data plane packets because there are fewer potential 
>branch points.

         There are cases where all LSRs need to understand
replies via the control plane in LSP Ping.  This may not
work unless everyone along the path understands what to
do.

         --Tom

---

From: Alia Atlas <[email-masked]>
Date: Wed, 20 Nov 2002 10:38:47 -0500

>work unless everyone along the path understands what to

Tom,

Now I am confused.  We are discussing the load-balancing done internally in 
an LSR.  This is currently proprietary and different between different 
LSRs.  How does recommending not including the OAM labels suddenly break 
MPLS ping?  This has nothing to do with understanding the replies via the 
control plane in MPLS ping.

If it did, then we'd already have a problem with MPLS ping, because the 
load-balancing algorithms currently extant are different.

Alia

---

From: George Swallow <[email-masked]>
Date: Wed, 20 Nov 2002 11:20:00 -0500

> compared to the data plane packets because there are fewer potential branch 

Well if you want your CV OAM to make you pretty sure, then yes, you
get surer as you incrementally deploy.  But most of the time you can
be pretty sure with much lighter overhead.  So I was assuming (perhaps
incorectly) that someone who want to send a CV OAM packet every second
wanted to be 100% sure.

...George