[frr] 2 MPLS Questions

[Vincent Jardin]

+Jeff

Le 23 mars 2017 5:59:21 PM Amine Kherbouche <amine.kherbouche at 6wind.com> a 
écrit :

> Hi David,
>
> I think that 8 stacked labels are more than enough, I cannot imagine a core
> network with 8 stacked MPLS-VPNs.
> Let's see the others if they share my opinions.


I think too that 8 is a good upper limit.


>
>
> Regards,
> Amine
>
> On 23 March 2017 at 17:47, David Ahern <dsa at cumulusnetworks.com> wrote:
>
>> I have the MPLS code changes to bump the number of labels. What did we
>> want to use for the max? 12? 16?
>>
>> This limit is really only capping what we take from userspace. Kernel
>> side memory allocations are done based on the actual number of labels in
>> the route.
>>
>>
>> On 3/16/17 10:49 AM, Olivier Dugeon wrote:
>> > Hi David,
>> >
>> > Well, frankly speaking, I don't see where is the problem regarding the
>> > performance.
>> >
>> > IMHO, the patch add an extra size of the array i.e. from 8 bytes (2
>> > labels) to 64 bytes (16 labels) which is completely negligible compared
>> > to the size of a IP packet, and of same magnitude order as a VxLan
>> > encapsulation and twice less as an IPv6 header.
>> >
>> > In addition, only the edge router as to push the label stack. Then,
>> > subsequent router just look at the top label. So, no more no less that a
>> > packet with only 2 labels in the stack.
>> >
>> > I think that dealing with a dynamic MPLS STACK DEPTH i.e. dynamic memory
>> > allocation of space regarding the number of labels are push in from of
>> > the IP packet will certainly add more overhead and more CPU cycles
>> > rather than just manage a fix amount of byte in an array.
>> >
>> > Finally, the default value for the MPLS_LABEL_STACK could be equal to 2
>> > and let peoples want to deal with Segment Routing recompile the kernel
>> > with a larger value.
>> >
>> > From my side, your patch will not only increase the label stack, it also
>> > re-arrange the MPLS structure in order to solve the problem of corrupted
>> > third label. And, this is the more important things.
>> >
>> > In any case, let me know what I can do to help you.
>> >
>> > Regards
>> >
>> > Olivier
>> >
>> >
>> > Le 16/03/2017 à 16:10, David Ahern a écrit :
>> >> I made the kernel patch to help you move along with your MPLS work.
>> >>
>> >> In the kernel thread discussing the increase in number of labels Eric
>> >> Biederman mentions performance concerns about just increasing the size
>> >> of the array; he wanted a much more complicated change and I have not
>> >> gotten around to it.
>> >>
>> >>
>> >> On 3/16/17 3:31 AM, Olivier Dugeon wrote:
>> >>> Hi all,
>> >>>
>> >>> The problem is not between the kernel and iproute2. The problem comes
>> >>> when stacking more than 2 labels: the LSB byte of the third label is
>> >>> replaced by 0x03 value i.e. the implicit Null Label value. See attached
>> >>> thread.
>> >>>
>> >>> Following this, David propose a new patch that we integrated and tested
>> >>> successfully (See second and third attached mail).
>> >>>
>> >>> But, after that, I got no news and never seen this patch merge into the
>> >>> Linux Kernel release. So, we just ask when this patch could be merge
>> >>> into the Linux Kernel.
>> >>>
>> >>> For the second problem about PHP, it is also described in the first
>> >>> attached thread. But, agree, that this issue is more tricking to solve.
>> >>>
>> >>> Regards,
>> >>>
>> >>> Olivier
>> >>>
>> >>>
>> >>> Le 15/03/2017 à 16:59, David Ahern a écrit :
>> >>>> On 3/15/17 9:57 AM, Amine Kherbouche wrote:
>> >>>>>     > 1) More than 2 labels in the kernel at a time, when will this
>> be
>> >>>>>     > allowed in the kernel?
>> >>>>>     >
>> >>>>>
>> >>>>> I don't understand why iproute2 and kernel are not sync when it
>> comes to
>> >>>>> the max stacked labels, iproute2 should export kernel headers.
>> >>>>>
>> >>>> https://marc.info/?l=linux-netdev&m=146913202123729&w=2
>> >>>>
>> >
>>
>
>
>
> --
> Amine
>
>
>
> ----------
> _______________________________________________
> frr mailing list
> frr at lists.nox.tf
> https://lists.nox.tf/listinfo/frr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20170323/588d0f16/attachment.html>