<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font face="Ubuntu">Hi Donald, all,</font></p>
<p><font face="Ubuntu"><font face="Ubuntu">Things are evolving in
the <font face="Ubuntu">good way as </font>I solve all my
bugs, except <font face="Ubuntu">the</font> initial condition
which make me crazy.</font></font></p>
<p><font face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu">I
mean that the new CLI command</font></font>s <font
face="Ubuntu">I introduce are not correctly handle. <font
face="Ubuntu">Some of them work fine and other one are
simply not recognize even if help string </font></font>are
correctly han<font face="Ubuntu">dle. So, it is very hard to
start correctly OSPF with segment routing enable. I must <font
face="Ubuntu">add extra</font> code to force some commands.</font></font></p>
<p><font face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu">So,
tomorrow I will rebase my code on <font face="Ubuntu">a fre<font
face="Ubuntu">sh master branch to see if this problem
will be solved.</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">In
the mean time, I have one problem, but that seems
general. I can't add a new FEC for a given prefix<font
face="Ubuntu">. Only MPLS label are correctly taken
into account. I also try to setup a static route
with a label i.e. more or les<font face="Ubuntu">s
the same action I perform when trying to install a
new FEC<font face="Ubuntu">, and it <font
face="Ubuntu">also failed. I mea<font
face="Ubuntu">n that all go<font
face="Ubuntu"> smoothly without any error,
but, <font face="Ubuntu">the <font
face="Ubuntu">prefix route is not inst<font
face="Ubuntu">all in the kernel. I
will also try to use a fresh kernel
(I'm currently using a 4.4.6) to see
if improve things. Do you observe
this problem ?<br>
</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">I
will update my git tomorrow and
proposed a first version of the PR<font
face="Ubuntu"> for review.</font></font><br>
</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></p>
<p><font face="Ubuntu"><font face="Ubuntu">Regards</font></font></p>
<p><font face="Ubuntu"><font face="Ubuntu"><font face="Ubuntu">Olivier</font></font><br>
</font></p>
<br>
<div class="moz-cite-prefix">Le 03/01/2018 à 16:40, Donald Sharp a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAK989ycCrmOB19VoZ5Kta63pV=99kyB-aEV8Bv2e+jdpBTa29w@mail.gmail.com">
<pre wrap="">Olivier -
Thanks for pointing me at the code changes. I've taken a look and
added my review comments. Let us know when it is ready to go.
thanks!
donlad
On Fri, Dec 22, 2017 at 11:08 AM, Olivier Dugeon
<a class="moz-txt-link-rfc2396E" href="mailto:olivier.dugeon@orange.com"><olivier.dugeon@orange.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Donald,
OK. Thank you very much to give me more time.
You could start having a look on my FRR fork:
<a class="moz-txt-link-freetext" href="https://github.com/Orange-OpenSource/frr/tree/SR-Routing">https://github.com/Orange-OpenSource/frr/tree/SR-Routing</a>
I just push my code. But not yet ready for the Pull Request.
In particular, I need to find a proper way to know that a re-routing occurs
i.e. that OSPF recompute / reinstall a new routing table in order to update
accordingly the Segment Routing MPLS FIB. I look to LDP code, but not found
useful information. Previously it was done by adding a hook when OSPF send
new routing table to Zebra, but I don't love too much this way of proceed.
If someone has a better idea, I'll take it with pleasure.
Nothing will happen next week. I'll inform on progress first week of
January.
Regards
Olivier
Le 22/12/2017 à 16:48, Donald Sharp a écrit :
Olivier -
I think we'll wait. There are a couple of other issues we are trying
to resolve as well which have not happened yet. Keep us updated!
donald
On Fri, Dec 22, 2017 at 9:07 AM, <a class="moz-txt-link-rfc2396E" href="mailto:olivier.dugeon@orange.com"><olivier.dugeon@orange.com></a> wrote:
Hi Donald, all,
Unfortunately, remaining bugs have won despite all my efforts and my best
wish. I have to throw in the towel by KO :-(
I'm going on vacation for two weeks, and completely off between Christmas
and New Year. I will resume the fight early January and this time, I will
win the game.
In the meantime, I will push in my personal FRR fork with SR-Routing branch
the code as it is in one or two hours. If anyone wants to take a look at it.
<a class="moz-txt-link-freetext" href="https://github.com/Orange-OpenSource/frr">https://github.com/Orange-OpenSource/frr</a>
I let you take the decision to create the branch 4.0 now or wait a little
longer.
All my best wishes to you and your family.
Regards
Olivier
Le 20/12/2017 à 22:08, Donald Sharp a écrit :
Olivier -
We can wait.
thanks!
donald
On Wed, Dec 20, 2017 at 1:10 PM, Olivier Dugeon
<a class="moz-txt-link-rfc2396E" href="mailto:olivier.dugeon@orange.com"><olivier.dugeon@orange.com></a> wrote:
Hello Donald,
I just finish re-factoring my code on fresh frr/master.
Now, I need to check indentation, update ospfd documentation for the new SR
CLI and perform my tests.
Tomorrow, I have several meetings, so, I'll not finish all my tasks before
Friday.
If it is too late, just skip it and publish 4.0 branch. I'll publish my PR
later, and we could decide if we backport it to the upcoming 4.0 release.
Regards
Olivier
Le 19/12/2017 à 19:36, Donald Sharp a écrit :
Olivier -
Any update here on your SR patch?
donald
On Wed, Dec 13, 2017 at 10:25 AM, Olivier Dugeon
<a class="moz-txt-link-rfc2396E" href="mailto:olivier.dugeon@orange.com"><olivier.dugeon@orange.com></a> wrote:
Hi Donald, all
I hope finishing our Segment Routing patch by a week.
So, is it possible to wait for it to be included in 4.0 branch ?
Regards
Olivier
Le 13/12/2017 à 14:04, Donald Sharp a écrit :
I am currently waiting on PR #1533( Addition of Linux Realms ) to get
in in order to pull the 4.0 branch. *IF* you want a feature to go in
to 4.0 this is your absolute last chance to make it happen.
thanks!
donald
On Thu, Dec 7, 2017 at 10:45 AM, Donald Sharp
<a class="moz-txt-link-rfc2396E" href="mailto:sharpd@cumulusnetworks.com"><sharpd@cumulusnetworks.com></a> wrote:
All -
I intend to pull the 4.0 branch early next week. Now is the time for
any last minute additions before we create it.
Additionally I would like to create a 3.0.3 version with bug-fixes by
the new years. So if you are missing anything or have a bug fix
submitting it would be good.
donald
_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a>
<a class="moz-txt-link-freetext" href="https://lists.frrouting.org/listinfo/dev">https://lists.frrouting.org/listinfo/dev</a>
_________________________________________________________________________________________________________________________
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>
</blockquote>
<pre wrap="">
</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>