<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><i><font face="Ubuntu">grep '#define MAX_NEW_LABELS' internal.h |
awk -e '{print $3}'</font></i></p>
<p>But I'm not sure it answers your question <span
class="moz-smiley-s3"><span>;-)</span></span><br>
</p>
<p>Olivier<br>
</p>
<br>
<div class="moz-cite-prefix">Le 23/03/2017 à 18:21, Jeff Tantsura a
écrit :<br>
</div>
<blockquote
cite="mid:05006AE4-B015-4442-B095-53B354CDC973@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
while on topic, can I please get an API to query data plane for
MSD supported?
<div class="">Use
case: draft-ietf-isis-segment-routing-msd/ draft-ietf-ospf-segment-routing-msd/ draft-tantsura-idr-bgp-ls-segment-routing-msd<br
class="">
<div class="">
<div class=""><br class="webkit-block-placeholder">
</div>
<div class="">
Many thanks!</div>
<div class=""><br class="Apple-interchange-newline">
<span style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
display: inline !important; float: none;" class="">Cheers,</span><br
style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;"
class="">
<span style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
display: inline !important; float: none;" class="">Jeff</span><br
style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;"
class="">
<br style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;"
class="">
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Mar 23, 2017, at 10:07, Vincent Jardin
<<a moz-do-not-send="true"
href="mailto:vincent.jardin@6wind.com" class="">vincent.jardin@6wind.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<div style="" class="">
<p style="margin: 0px 0px 1em;" class="">+Jeff</p>
<div style="margin: 0px 0px 1em; font-family:
sans-serif;" class=""><br
class="webkit-block-placeholder">
</div>
<p style="margin: 0px 0px 1em; font-family:
sans-serif;" class="">Le 23
mars 2017 5:59:21 PM Amine Kherbouche <<a
moz-do-not-send="true"
href="mailto:amine.kherbouche@6wind.com"
class="">amine.kherbouche@6wind.com</a>> a
écrit :</p>
<p style="margin: 0px 0px 1em; font-family:
sans-serif;" class="">>
Hi David,<br class="">
><br class="">
> I think that 8 stacked labels are more than
enough, I cannot imagine a
core<br class="">
> network with 8 stacked MPLS-VPNs.<br class="">
> Let's see the others if they share my
opinions.</p>
<p style="margin: 0px 0px 1em;" class=""><br
class="">
</p>
<p style="margin: 0px 0px 1em;" class="">I think too
that 8 is a good
upper limit. </p>
<p style="margin: 0px 0px 1em; font-family:
sans-serif;" class=""><br class="">
><br class="">
><br class="">
> Regards,<br class="">
> Amine<br class="">
><br class="">
> On 23 March 2017 at 17:47, David Ahern <<a
moz-do-not-send="true"
href="mailto:dsa@cumulusnetworks.com" class="">dsa@cumulusnetworks.com</a>>
wrote:<br class="">
><br class="">
>> I have the MPLS code changes to bump the
number of labels. What
did we<br class="">
>> want to use for the max? 12? 16?<br
class="">
>><br class="">
>> This limit is really only capping what we
take from userspace.
Kernel<br class="">
>> side memory allocations are done based on
the actual number of
labels in<br class="">
>> the route.<br class="">
>><br class="">
>><br class="">
>> On 3/16/17 10:49 AM, Olivier Dugeon
wrote:<br class="">
>> > Hi David,<br class="">
>> ><br class="">
>> > Well, frankly speaking, I don't see
where is the problem
regarding the<br class="">
>> > performance.<br class="">
>> ><br class="">
>> > IMHO, the patch add an extra size of
the array i.e. from 8
bytes (2<br class="">
>> > labels) to 64 bytes (16 labels)
which is completely
negligible compared<br class="">
>> > to the size of a IP packet, and of
same magnitude order as a
VxLan<br class="">
>> > encapsulation and twice less as an
IPv6 header.<br class="">
>> ><br class="">
>> > In addition, only the edge router as
to push the label stack.
Then,<br class="">
>> > subsequent router just look at the
top label. So, no more no
less that a<br class="">
>> > packet with only 2 labels in the
stack.<br class="">
>> ><br class="">
>> > I think that dealing with a dynamic
MPLS STACK DEPTH i.e.
dynamic memory<br class="">
>> > allocation of space regarding the
number of labels are push
in from of<br class="">
>> > the IP packet will certainly add
more overhead and more CPU
cycles<br class="">
>> > rather than just manage a fix amount
of byte in an array.<br class="">
>> ><br class="">
>> > Finally, the default value for the
MPLS_LABEL_STACK could be
equal to 2<br class="">
>> > and let peoples want to deal with
Segment Routing recompile
the kernel<br class="">
>> > with a larger value.<br class="">
>> ><br class="">
>> > From my side, your patch will not
only increase the label
stack, it also<br class="">
>> > re-arrange the MPLS structure in
order to solve the problem
of corrupted<br class="">
>> > third label. And, this is the more
important things.<br class="">
>> ><br class="">
>> > In any case, let me know what I can
do to help you.<br class="">
>> ><br class="">
>> > Regards<br class="">
>> ><br class="">
>> > Olivier<br class="">
>> ><br class="">
>> ><br class="">
>> > Le 16/03/2017 à 16:10, David Ahern a
écrit :<br class="">
>> >> I made the kernel patch to help
you move along with your
MPLS work.<br class="">
>> >><br class="">
>> >> In the kernel thread discussing
the increase in number of
labels Eric<br class="">
>> >> Biederman mentions performance
concerns about just
increasing the size<br class="">
>> >> of the array; he wanted a much
more complicated change
and I have not<br class="">
>> >> gotten around to it.<br class="">
>> >><br class="">
>> >><br class="">
>> >> On 3/16/17 3:31 AM, Olivier
Dugeon wrote:<br class="">
>> >>> Hi all,<br class="">
>> >>><br class="">
>> >>> The problem is not between
the kernel and iproute2.
The problem comes<br class="">
>> >>> when stacking more than 2
labels: the LSB byte of the
third label is<br class="">
>> >>> replaced by 0x03 value i.e.
the implicit Null Label
value. See attached<br class="">
>> >>> thread.<br class="">
>> >>><br class="">
>> >>> Following this, David
propose a new patch that we
integrated and tested<br class="">
>> >>> successfully (See second and
third attached mail).<br class="">
>> >>><br class="">
>> >>> But, after that, I got no
news and never seen this
patch merge into the<br class="">
>> >>> Linux Kernel release. So, we
just ask when this patch
could be merge<br class="">
>> >>> into the Linux Kernel.<br
class="">
>> >>><br class="">
>> >>> For the second problem about
PHP, it is also
described in the first<br class="">
>> >>> attached thread. But, agree,
that this issue is more
tricking to solve.<br class="">
>> >>><br class="">
>> >>> Regards,<br class="">
>> >>><br class="">
>> >>> Olivier<br class="">
>> >>><br class="">
>> >>><br class="">
>> >>> Le 15/03/2017 à 16:59, David
Ahern a écrit :<br class="">
>> >>>> On 3/15/17 9:57 AM,
Amine Kherbouche wrote:<br class="">
>> >>>>> > 1) More
than 2
labels in the kernel at a time, when will this<br
class="">
>> be<br class="">
>> >>>>> > allowed in
the
kernel?<br class="">
>> >>>>> ><br class="">
>> >>>>><br class="">
>> >>>>> I don't understand
why iproute2 and kernel
are not sync when it<br class="">
>> comes to<br class="">
>> >>>>> the max stacked
labels, iproute2 should
export kernel headers.<br class="">
>> >>>>><br class="">
>> >>>> <a
moz-do-not-send="true"
href="https://marc.info/?l=linux-netdev&m=146913202123729&w=2"
class="">https://marc.info/?l=linux-netdev&m=146913202123729&w=2</a><br
class="">
>> >>>><br class="">
>> ><br class="">
>><br class="">
><br class="">
><br class="">
><br class="">
> -- <br class="">
> Amine<br class="">
><br class="">
><br class="">
><br class="">
> ----------<br class="">
>
_______________________________________________<br
class="">
> frr mailing list<br class="">
> <a moz-do-not-send="true"
href="mailto:frr@lists.nox.tf" class="">frr@lists.nox.tf</a><br
class="">
> <a moz-do-not-send="true"
href="https://lists.nox.tf/listinfo/frr"
class="">https://lists.nox.tf/listinfo/frr</a><br
class="">
</p>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
frr mailing list
<a class="moz-txt-link-abbreviated" href="mailto:frr@lists.nox.tf">frr@lists.nox.tf</a>
<a class="moz-txt-link-freetext" href="https://lists.nox.tf/listinfo/frr">https://lists.nox.tf/listinfo/frr</a>
</pre>
</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>