[dev] [frr] 2 MPLS Questions

[Olivier Dugeon]

Hi David,

Good news. Thanks for your effort.


Le 06/04/2017 à 15:36, David Ahern a écrit :
> net-next tree has the patch set increasing number of labels. Allows up
> to 30 labels for ingress (ip->mpls) and routing (mpls->mpls).
>
> An mpls_route is limited to 4096 bytes (number of nexthops + labels); an
> lwt (ingress) route is under 128 bytes. With the latest set users of
> N-labels takes the performance hit of each additional label.
>
Well, I'm not sure to correctly understand.

Is this means that we could manage for example 136 segment paths of 30 labels each, 256 segment paths of 16 labels each, 1024 segment paths of 4 labels, ... In other words, the sum of all label stacks of all segment paths must fit under the 4k bytes limit. I understand that we must put a limit, but 4k bytes is short. Very short. At the maximum it only authorizes 4k connexions with only one label i.e. only 4K LDP, RSVP-TE or MP-BGP paths.

Or is this means that the total size of the packet + labels must not increase 4k bytes ? That's enough for standard 1500 bytes packets, but not sufficient for jumbo frames.

Or is this means that the total information per mpls_route must not exceed 4k bytes ? In this case, it is largely enough as label stacks in segment routing replace the number of nexhops. I means that, then you describe an mpls_route in segment routing, the stack of label is the path and nexthops are the label. So, no needs to have both nexhops and labels.

Can you precise which of my interpretation is correct, or if I'm completely wrong ?

Regards

Olivier
> On 3/23/17 1:34 PM, Amine Kherbouche wrote:
>> Olivier,
>>
>>     The best for me, is to have the possibility to recompile the MPLS
>>     kernel module with the new value the MAX_LABEL_STACK and then let
>>     our Segment Routing implementation read this value to determine
>>     what's feasible.
>>
>> Yes but we still need a default value.
>> You have also to see the perf impact, now the current mpls entry size in
>> linux kernel is under
>> a cache line, even using 12 stacked labels, we are always under a cache
>> line but beyond
>> this value we're going to see performance issue.
>>