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