Re: [mpls] Question regarding MPLS reserved label with ECMP

[Kireeti Kompella <[e-mail]>]

On Aug 21, 2012, at 6:52 , Curtis Villamizar wrote:

> In message <[e-mail]>
> Kireeti Kompella writes:
> 
>> On Aug 18, 2012, at 4:45 , Vivek Kumar wrote:
>> 
>>> Hi ,
>>> I have one question regarding whether MPLS reserved label should be used or skipped when Transit LSR is doing hashing on full label stack which has some reserved label.
>> 
>> draft-ietf-mpls-entropy-label, section 4.3:
>> 
>>   If a transit LSR recognizes the ELI, it MAY choose to load balance
>>   solely on the following label (the EL); otherwise, it SHOULD use as
>>   much of the whole label stack as feasible as keys for the load
>>   balancing function, with the exception that reserved labels MUST NOT
>>   be used.
>> 
>>>  RFC 6391 , section 7 , says " Note that, depending on the number of labels hashed by the LSR, the
>>>  inclusion of the Router Alert label may cause the OAM packet to be
>>>  load-balanced to a different path from that taken by the data packets
>>>  with identical flow and PW labels".
>>> 
>>> The above comment implies that reserved label is used by LSR when doing hashing for ECMP.
>>> 
>>> Is there any other RFC which states what should be the correct behavior.
>>> 
>>> The draft " draft-ietf-mpls-entropy-label-05" section 4.3 , says reserved label should not be used by LSR when doing hashing on label stack.
>>> 
>>> 
>>> Regards,
>>> Vivek
> 
> 
> Kireeti,
> 
> entropy-label may be the first place where this advice has been given
> and it is good that it is finally somewhere.
> 
> If there is a GAL that is also a reason not to hash on a reserved
> label.  The path with or without GAL should be the same.
> 
> The word "may" in "may cause" in the quoted statement from RFC 6391 is
> significant.  Some routers hash on everything they find.  This is a
> bad practice, but exists.

This is one of the main reasons for including the above caveat.

In general, as far as I can tell, the IETF has been reluctant to specify what fields to load balance on, as this is to some extent an implementation choice.  Perhaps specifying the set of allowable fields, indirectly saying Thou SHALT NOT (*) load balance on other fields until an RFC says you MAY, might be a reasonable way of dealing with this.  This would be across a number of technologies -- IP (in its myriad guises: GRE, IP-in-IP, L2TPv2,3,..., LISP), MPLS, etc., and a number of what we call transport fields (TCP, UDP, that thing SIP uses, ...).  Trouble is, every new encaps (e.g., NVGRE) will mandate an update.  Maybe that's a good thing, though -- load balancing may not be optimal until the update, but at least it won't be "wrong", spraying flows indiscriminately across paths.

Kireeti

(*) Adrian will point out that this is not RFC 2119 language.  It SHOULD be, though.  I'll have a serious talk with SOB.

> Curtis