<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font face="Ubuntu">Hello Jeff</font></p>
<p><font face="Ubuntu"><font face="Ubuntu">Up to know, I start
coding the Node MSD as for me, Link MSD as no<font
face="Ubuntu"> se<font face="Ubuntu">nse. But, I could add
the corre<font face="Ubuntu">sponding TLV/Sub-TLV for
decoding purpose when receiving such information<font
face="Ubuntu">. Now, regarding the value of Node MSD,
I will do 2 things:</font></font></font></font></font></font></p>
<p><font face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu">1/ fulfil the default MSD at
compilation time by fixing the default MSD value
with the kernel value.</font></font></font></font></font></font></font></p>
<p><font face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu">2/ give the
possibility to modify the MSD value with dedicated
new CLI command<font face="Ubuntu">, but by
checking that the administrative value is not
greater than the default MSD value provided at <font
face="Ubuntu">compilation time.</font></font></font></font></font></font></font></font></font></font></p>
<p><font face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu">Unfortunately, if the kernel
is recompile with a different value or if
the kernel on which FRR is running as a
different value compared to the one where
the compilation has been done, we manage a
wrong value. It is why I add the <font
face="Ubuntu">possibility</font> to modify
it through CLI. <br>
</font></font></font></font></font></font></font></font></font></font></font></p>
<p><font face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu">For a more
dynamic MSD <font face="Ubuntu">assignment</font>,
<font face="Ubuntu">we must look at <font
face="Ubuntu">the running kernel. But
again, <font face="Ubuntu">kernel
header are not necessary install on
the <font face="Ubuntu">host where
FRR is running. <font
face="Ubuntu">So, even if it is
a technical solution, it is not
sure that we could collect the
MSD value. For me, the best is
the <font face="Ubuntu">possibility</font>
to collect the MSD value via the
/proc or /sys file system. But,
this need some modification in
the <font face="Ubuntu">linu<font
face="Ubuntu">x kernel
module to fulfil this valu<font
face="Ubuntu">e<font
face="Ubuntu">. Another
<font face="Ubuntu">possibility</font>,
is through IOCTL, but
again this imply some
extra coding in the <font
face="Ubuntu">MPLS
Module. And, <font
face="Ubuntu">this
cover only Linux
Kernel. I don't know
for *BSD.</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></p>
<p><font face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu">Regards</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></p>
<p><font face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu"><font
face="Ubuntu">Olivier</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font><br>
</p>
<br>
<div class="moz-cite-prefix">Le 04/07/2017 à 01:50, Jeff Tantsura a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:F834F280-F9A6-4F37-98D2-38925117A6AF@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Hi Olivier,
<div class=""><br class="">
</div>
<div class="">I’m the author of MSD drafts, let me know if I can
help.</div>
<div class="">Drafts are stable and will go to WGLC after Prague
(IETF99), </div>
<div class="">My thinking - to keep it simple, only Base MSD has
been defined and pre-allocated by IANA, all other types will be
defined in another documents.</div>
<div class="">In most cases, MSD is limited by the underlying HW,
obviously SW has to support larger stack too. </div>
<div class="">I have discussed an API that could be used to derive
MSD value (could be more than 1 by using new MSD type) by
querying it with BCM and Barefoot, both agreed on the need to do
so.</div>
<div class=""><br class="">
</div>
<div class="">As I said before - there’s no free lunch in fast
path universe, there’s a price to pay in latency, reduced
throughput, number of additional features, etc</div>
<div class="">Sane limits are healthy and protect a system from
abuse.</div>
<div class=""><br class="">
</div>
<div class="">From implementation prospective - extensions to
OSPF/ISIS/BGP-LS are needed to signal MSD, while on x86 platform
link MSD doesn’t make much sense, please do implement it for the
completeness. </div>
<div class="">HW MSD, when available thru an API call should
become the node/link MSD, otherwise should be configured under
“routing protocol/interface” stanza.</div>
<div class=""><br class="">
</div>
<div class="">Have you looked into entropy labels yet? <br
class="">
<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 Jul 3, 2017, at 06:13, <a
href="mailto:olivier.dugeon@orange.com" class=""
moz-do-not-send="true">olivier.dugeon@orange.com</a>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<p class=""><font class="" face="Ubuntu">Hello,</font></p>
<p class=""><font class="" face="Ubuntu"><font class=""
face="Ubuntu">This limit must not be avoided. But,
fix looking up to what<font class="" face="Ubuntu">
the kernel support.</font></font></font></p>
<p class=""><font class="" face="Ubuntu"><font class=""
face="Ubuntu"><font class="" face="Ubuntu"><font
class="" face="Ubuntu">In addition, for
Segment Routing, there <font class=""
face="Ubuntu">is a ne<font class=""
face="Ubuntu">w draft (</font></font></font></font></font></font>draft-ietf-ospf-segment-routing-msd-05.txt<font
class="" face="Ubuntu"><font class="" face="Ubuntu"><font
class="" face="Ubuntu"><font class=""
face="Ubuntu"><font class="" face="Ubuntu"><font
class="" face="Ubuntu">) that could be
used to adverti<font class=""
face="Ubuntu">s</font>e the Maxim<font
class="" face="Ubuntu">um Stack Depth.
It is on my TODO list for OSPF Seg<font
class="" face="Ubuntu">ment Routing
support in FRR.</font><br class="">
</font></font></font></font></font></font></font></p>
<p class=""><font class="" face="Ubuntu"><font class=""
face="Ubuntu"><font class="" face="Ubuntu"><font
class="" face="Ubuntu"><font class=""
face="Ubuntu"><font class="" face="Ubuntu"><font
class="" face="Ubuntu"><font class=""
face="Ubuntu">Regards</font></font></font></font></font></font></font></font></p>
<p class=""><font class="" face="Ubuntu"><font class=""
face="Ubuntu"><font class="" face="Ubuntu"><font
class="" face="Ubuntu"><font class=""
face="Ubuntu"><font class="" face="Ubuntu"><font
class="" face="Ubuntu"><font class=""
face="Ubuntu"><font class=""
face="Ubuntu">Olivier</font></font></font></font></font></font></font></font></font><br
class="">
</p>
<br class="">
<div class="moz-cite-prefix">Le 03/07/2017 à 14:37,
Алексей Болдырев a écrit :<br class="">
</div>
<blockquote type="cite"
cite="mid:1174331499085421@web22j.yandex.ru" class="">
<pre class="" wrap="">By the way, kernel 4.12 is already available: (<a class="moz-txt-link-freetext" href="https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.12.tar.xz" moz-do-not-send="true">https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.12.tar.xz</a>)
In this kernel, according to the developers, the number of MPLS tags on the stack is 30.
Therefore, I suggest that this limit in Zebra should be avoided.
<a class="moz-txt-link-freetext" href="https://github.com/FRRouting/frr/issues/776" moz-do-not-send="true">https://github.com/FRRouting/frr/issues/776</a>
_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org" moz-do-not-send="true">dev@lists.frrouting.org</a>
<a class="moz-txt-link-freetext" href="https://lists.frrouting.org/listinfo/dev" moz-do-not-send="true">https://lists.frrouting.org/listinfo/dev</a>
</pre>
</blockquote>
<br class="">
<pre class="">_________________________________________________________________________________________________________________________
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>
</div>
_______________________________________________<br
class="">
dev mailing list<br class="">
<a href="mailto:dev@lists.frrouting.org" class=""
moz-do-not-send="true">dev@lists.frrouting.org</a><br
class="">
<a class="moz-txt-link-freetext" href="https://lists.frrouting.org/listinfo/dev">https://lists.frrouting.org/listinfo/dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</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>