<div dir="ltr">Olivier,<div><br></div><div>The main concern I have with making a PCC daemon (PCCd) is the performance impacts involved with the daemon acting as a relay and having to send messages on to another process (zebra) which itself will send them on to the destination process (either pathd or RSVPd). Instead of 1 simple decode if the PCEPlib was included in pathd, now the messages would need to be decoded, encoded again to be sent to zebra, which hopefully wont decode/encode them, then sent on again to the final destination which will need to decode it. Or in other words: 1 decode and no extra hops compared to 2 decodes and 1 encode and 2 extra message hops.</div><div><br></div><div>Also, what would the format of these messages sent between the PCCd and pathd/RSVPd? Hopefully it would just use the existing PCEP message/object/TLVs struct's already defined in the PCEPlib and not recreate some sub-set of the PCEP protocol.</div><div><br></div><div>Regarding the excerpt you quoted from the RFC spec: I think that is referring to creating multiple PCEP sessions on the same TCP connection, which is not what I was suggesting. What I was proposing in the meeting last week was for pathd and RVSPd to each link in the PCEPlib, and each open independant TCP connections towards the PCE. As you mentioned in the meeting, this could be a problem to have multiple PCEP connections from the same IP, but that could be easily solved by using different source IPs for the pathd and RSVPd. </div><div><br></div><div>Regards,</div><div><br></div><div>Brady</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 16, 2020 at 4:36 PM <<a href="mailto:olivier.dugeon@orange.com">olivier.dugeon@orange.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <pre><tt>Dear all,</tt></pre>
    <pre><tt>Following our last Telco meeting, here it is some answer regarding the PCEP protocol.

First, as mention in RFC5440 section 4.2.1 </tt><tt><a href="https://tools.ietf.org/html/rfc5440#section-4.2.1" target="_blank">https://tools.ietf.org/html/rfc5440#section-4.2.1</a>

<i>   Only one PCEP session can exist between a pair of PCEP peers at any</i><i>
</i><i>   one time.  Only one TCP connection on the PCEP port can exist between</i><i>
</i><i>   a pair of PCEP peers at any one time.</i>

It is not authorized to setup more than one PCEP session between a PCC router and a PCE server.

Second, regarding SR Policy, this is related to an individual draft (WG adoption is on-going) </tt>
<tt><a href="https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/" target="_blank">https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/</a> that aims to give
the possibility to configure SR Policy defined in Segment Routing Policy Architecture
</tt><a href="https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/</a> through PCEP protocol.

However, this is specific to Segment Routing. Policies are always defined for RSVP-TE and thus
part of PCE standards. Of course, name and type of policy differ. Some are implicit due to the
signalling nature of RSVP-TE i.e. some parameters of the RSVP-TE tunnel are convey by the RSVP
protocol, thus each routers on the RSVP-TE tunnel path are aware about the intrinsic
characteristics of the RSVP-TE tunnel.

SR Policies have been defined to circumvent the lake of signalling of Segment Routing which
of course greatly simplify the architecture, but as a counter part need a centralised server
e.g. a PCE server to correctly manage Segment Paths in particular when bandwidth reservations
are requested.

So, there is no risk to have duplicate code if we go to a clear separation between PCELib and
pathd. PCEPLib could serve as the basis of creating a PCCd daemon in charge of the PCEP protocol
while pathd remains in charge of Segment Path & Segment Routing Policies. When RSVP-TE daemon
will be ready, it could also take benefit of the PCCd daemon to interact with a PCE server.

Finally, regarding the new project facilities offered by GitHub platform, I will initialize such
project and will try to evaluate the benefit of them. But, instead of Northbound project, I will
split our various activities into different project to keep the number of card small per project,
and thus improve readability. The list of projects is as follow:

 * Segment Routing
 * Traffic Engineering
 * BGP-LS
 * Backup Path
 * PCEP

We could create new project when needed as well as close project when there will be finished.

Feel free to comment the proposal.

Regards

Olivier

</pre>
    <div>Le 09/06/2020 à 18:41,
      <a href="mailto:olivier.dugeon@orange.com" target="_blank">olivier.dugeon@orange.com</a> a écrit :<br>
    </div>
    <blockquote type="cite">
      
      <pre><tt>Dear all,</tt></pre>
      <pre><tt>Next Telco meeting is tomorrow Wednesday 10th of June 16h - 17h Paris time.</tt></pre>
      <pre><tt>Here it is the agenda. Perhaps we'll not have time to go through all points, but we'll try to do our best.</tt></pre>
      <pre><tt> - Status on Segment Routing PR and next steps
 - Status on Traffic Engineering (TED)
 - Presentation of Backup Paths (PR 6530) by Mark
 - Discussion about the new project facilities on GitHub to follow Telco actions (similar to what northbound call do)
 - Discussion on Pathd & PCELib
</tt></pre>
      <pre><tt>Regards</tt></pre>
      <pre><tt>Olivier</tt><font face="Ubuntu">
</font></pre>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
dev mailing list
<a href="mailto:dev@lists.frrouting.org" target="_blank">dev@lists.frrouting.org</a>
<a href="https://lists.frrouting.org/listinfo/dev" target="_blank">https://lists.frrouting.org/listinfo/dev</a>
</pre>
    </blockquote>
    <div>-- <br>
      <a style="text-decoration:none" href="http://www.orange.com" target="_blank"> <img style="border: none; margin-top: 5px; margin-bottom: 3px;" alt="Orange logo" src="cid:172bde8aa634c5fe79e1">
      </a>
      <p style="line-height:10px;margin:0px"> </p>
      <span style="font-weight:bold;font-family:Arial,sans-serif;font-size:10pt;color:rgb(0,0,0)"> Olivier Dugeon<br>
      </span> <span style="font-family:Arial,sans-serif;font-size:10pt;color:rgb(0,0,0)"> 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:rgb(0,0,0)"> fixe : +33 2 96 07 28
        80<br>
        mobile : +33 6 82 90 37 85<br>
      </span> <span style="margin:0px 0px 20px"> <a style="margin:0px 0px 20px;font-family:Arial,sans-serif;font-size:10pt;color:rgb(255,102,0);text-decoration:none" href="mailto:olivier.dugeon@orange.com" target="_blank">olivier.dugeon@orange.com</a>
      </span> </div>
  </div>

_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.frrouting.org" target="_blank">dev@lists.frrouting.org</a><br>
<a href="https://lists.frrouting.org/listinfo/dev" rel="noreferrer" target="_blank">https://lists.frrouting.org/listinfo/dev</a><br>
</blockquote></div>