<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><font face="Ubuntu">Hi Amine,</font></p>
<p><font face="Ubuntu">8 is fine for VPN, but not sufficient for
Segment Routing see: <a
href="http://ieeexplore.ieee.org/document/7778603/">http://ieeexplore.ieee.org/document/7778603/</a><br>
</font></p>
<p><font face="Ubuntu">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.<br>
</font></p>
<p>Regards</p>
<p>Olivier<br>
</p>
<br>
<div class="moz-cite-prefix">Le 23/03/2017 à 17:59, Amine Kherbouche
a écrit :<br>
</div>
<blockquote
cite="mid:CAEn71cDFxtEdPLMVPOOeFbM4hhO_KXZ0OR28x7F1S7EgmSfDKA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">
<div>
<div>
<div>Hi David,<br>
<br>
</div>
I think that 8 stacked labels are more than enough, I cannot
imagine a core network with 8 stacked MPLS-VPNs. <br>
Let's see the others if they share my opinions.<br>
<br>
<br>
</div>
Regards,<br>
</div>
Amine<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 23 March 2017 at 17:47, David Ahern
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:dsa@cumulusnetworks.com" target="_blank">dsa@cumulusnetworks.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<div class="HOEnZb">
<div class="h5"><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 be<br>
>>>>> > allowed in the kernel?<br>
>>>>> ><br>
>>>>><br>
>>>>> I don't understand why iproute2 and
kernel are not sync when it comes to<br>
>>>>> the max stacked labels, iproute2
should export kernel headers.<br>
>>>>><br>
>>>> <a moz-do-not-send="true"
href="https://marc.info/?l=linux-netdev&m=146913202123729&w=2"
rel="noreferrer" target="_blank">https://marc.info/?l=linux-<wbr>netdev&m=146913202123729&w=2</a><br>
>>>><br>
><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">Amine<br>
</div>
</div>
</div>
</blockquote>
<br>
<PRE>_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
</PRE></body>
</html>