<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font face="Ubuntu">Hello Brad,</font></p>
<p><font face="Ubuntu">Thanks a lot for opening the git repo. I'll
have a look to both pathd & pceplib against ODL. I'll take
you inform about the result.</font></p>
<p>I take the opportunity to re-transcript the proposal I made
following a discussion we have with Sébastien about the RFC 8231
conformity versus Cisco and Juniper implementation.</p>
<p><i>The spirit of PCReport and thus synchronisation is to report
network LSP state, not LSP configuration. So, in normal
situation, I mean day life of an operator, the router is fire
up, PCEP session is established (so it reports 0 LSP) and then
when operator configures new LSP for which LSP need a valid ERO.
This ERO could be obtain in 3 different way:</i></p>
<ul>
<li><i>Static configuration,</i></li>
<li><i>Local computation,</i></li>
<li><i>Remote Computation.</i></li>
</ul>
<i>1 & 2 depend of PCC while 3 depends of PCE. If the LSP is
marked as delegated & dynamic path, then in respect of RFC
8231 section 5.8 (and in particular 5.8.1 & 5.8.2) the PCC
must first sends a PCreq message to obtain the valid ERO prior ro
send a PCReport for this LSP.</i>
<p><i>Of course we need to manage special case. In particular when
LSP are created before PCEP session is established. Always in
RFC 8231 section 6.1 this time, the PCReport message definition
mention that the PCC may report LSP with an empty ERO.</i></p>
<p><i>But, all in all, this is at the end implementation specific. I
mean that, if some LSP have no valid ERO, PCC is not obliged to
report them. These LSPs exist only in the configuration, not in
the network. And PCEP is here to control network LSP not
configuration. PCEP is not a management protocol like NetConf.</i></p>
<p><i>So, when the PCC synchronizes LSP after opening a PCEP
session, it could report only LSPs that have a valid ERO, and
then send PCReq message for these LSPs to get a valid ERO if
configuration of LSPs are done prior to the establishment of the
PCEP session.</i><i> <br>
</i></p>
<p><i>If the PCC decides to report these LSPs, the RFC 8231 doesn't
guarantee that the PCC will receive a valid path with a PCUpdate
message in turn. Again, the RFC 8231 doesn't forbid this
scenario, but it is implementation specific. Juniper and Cisco
do that, ODL not.</i><i> </i><i>What it is explicitly
forbidden, is to use a PCReport to request a Path Computation
and to use a PCReq while the LSP is delegate</i><i>d.<br>
</i><i><br>
</i><i>Now, regarding the compatibility with both RFC and vendor
specific implementation, I would suggest to not synchronize LSPs
that have not a valid ERO. And for these LSPs, start by sending
a PCReq message and start a timer. If the PCC get a PCRep
message with a valid ERO, then it could enforce the tunnel (SR
or RSVP-TE) and sends a PCReport accordingly. If the PCC get a
NO-PATH object with the PCRep, it must just change the status of
the LSP. So that the operator could see that there is no valid
path when performing a show tunnel ... CLI. If the timer
expires, then the PCC sends a PCReport with an empty ERO and
again start a timer. If the PCC get a PCUpdate message with a
valid ERO, it processes it as for the PCRep message. If the
timer expires, the PCC do the same as for the NO-PATH object.</i></p>
<p><i>Once the PCEP session is established, whe a new LSP is
created, the PCC starts by sending a PCReq message to get a
valid ERO, arming again a timer. If PCC receives a PCRep
message, it enforces the LSP with the valid ERO or mark LSP with
'invalid Path' if it gets a NO-PATH Object. If the the timer
expires, the PCC continue by sending the PCReport with an Empty
ERO and arm again a timer. If it received a valid ERO through a
PCEUpdate message, it enforces the LSP with the valid path and
if the timer expires, it mark the LSP with 'invalid Path'. </i><br>
</p>
<p>I think we are compatible with both standard and non standard PCE
with this scenario.<br>
</p>
<p>Fill free to comments.</p>
<p>Regards</p>
<p>Olivier<br>
</p>
<div class="moz-cite-prefix">Le 28/05/2020 à 18:11, Brady Johnson a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CALFzoMEofd6MRpq5sZgcPSXkABO4eDpV7-8cYF8JNR=co7ygjQ@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="ltr"><br>
<div>Hello,</div>
<div><br>
</div>
<div>This is my first email to FRR :)</div>
<div><br>
</div>
<div>I work for Volta Networks and I am based out of Madrid,
Spain.</div>
<div><br>
</div>
<div>Yesterday in the FRR Telco meeting, Sebastien from Netdef
presented the work we have been doing together on the
pathd daemon for SR-TE and a PCEP PCC. We mentioned the
PCEPlib library that I wrote that pathd links-in for the PCEP
protocol communication. We mentioned that we would be
upstreaming the PCEPlib library soon. Well, I created a repo
in our public github with the PCEPlib code [1] The PCEPlib is
LGPL 2 licensed.</div>
<div><br>
</div>
<div>The PCEPlib has 3 branches:</div>
<div>- master (no dev allowed here)</div>
<div>- devel (new development here)</div>
<div>- devel-1.0 (release branch)</div>
<div><br>
</div>
<div>The devel-1.0 branch is the latest tested version used with
pathd.</div>
<div><br>
</div>
<div>The devel branch is where new development happens, but it
has not been completely tested with pathd yet.</div>
<div><br>
</div>
<div>When designing and developing the PCEPlib, I had a
requirement that it MUST work without FRR, so you will notice
that it has its own timers and socket handling. I have new
code in the devel branch that allows for callbacks to be
plugged-in to the PCEPlib so that it uses memory, timers, and
socket infrastructure from FRR. There are more details about
this in the README [2].</div>
<div><br>
</div>
<div>We can discuss the next steps forward with the PCEPlib when
we discuss merging the pathd. Meanwhile, constructive comments
are welcome :)</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>Brady</div>
<div><br>
</div>
<div>[1] <a href="https://github.com/volta-networks/pceplib"
moz-do-not-send="true">https://github.com/volta-networks/pceplib</a></div>
<div>[2] <a
href="https://github.com/volta-networks/pceplib/tree/devel#pceplib-threading-model"
moz-do-not-send="true">https://github.com/volta-networks/pceplib/tree/devel#pceplib-threading-model</a></div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
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>
</pre>
</blockquote>
<div class="moz-signature">-- <br>
<a style="text-decoration:none;" href="http://www.orange.com"> <img
style="border:none;margin-top: 5px;margin-bottom: 3px;"
alt="Orange logo" src="cid:part3.8C7C5F09.85E8204E@orange.com">
</a>
<p style="line-height:10px;margin:0px"> </p>
<span style="font-weight:bold;font-family:Arial,
sans-serif;font-size:10pt;color:#000000;"> Olivier Dugeon<br>
</span> <span style="font-family:Arial,
sans-serif;font-size:10pt;color:#000000;"> Orange Expert, Future
Networks <br>
Open Source Referent <br>
Orange/IMT/OLN/WTC/IEE/iTeQ<br>
</span>
<p style="line-height:20px;margin:0px"> </p>
<span style="font-family:Arial,
sans-serif;font-size:10pt;color:#000000"> fixe : +33 2 96 07 28
80<br>
mobile : +33 6 82 90 37 85<br>
</span> <span style="margin:0px 0 20px 0;"> <a style="margin:0px
0 20px 0;font-family:Arial,
sans-serif;font-size:10pt;color:#FF6600;text-decoration:none;"
href="mailto:olivier.dugeon@orange.com">olivier.dugeon@orange.com</a>
</span> </div>
<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>