<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>