The MPLS WG Archive

[Alia Atlas <aatlas@avici.com>]

At 05:56 PM 11/19/2002 -0500, Thomas D. Nadeau wrote:
>At 01:43 PM 11/19/2002 -0500, Alia Atlas wrote:
>>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.
>
>         I think it might be a great design if EVERYONE implemented it.
>However, I think that is a not possible.

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

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


>         --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
>>
>>At 01:27 PM 11/19/2002 -0500, Thomas D. Nadeau wrote:
>>
>>>>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.
>>>>
>>>>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
>>>
>>>Success is relative; the more success, the more relatives. -Anonymous
>
>Success is relative; the more success, the more relatives. -Anonymous
>
>