<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" 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">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/">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/">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 class="moz-cite-prefix">Le 09/06/2020 à 18:41,
      <a class="moz-txt-link-abbreviated" href="mailto:olivier.dugeon@orange.com">olivier.dugeon@orange.com</a> a écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:d5274c27-43e6-0922-7098-649ced6f6969@orange.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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 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:part4.101CA940.C5D38020@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>
  </body>
</html>