[dev] Telco meeting agenda

olivier.dugeon at orange.com olivier.dugeon at orange.com
Tue Jun 16 14:34:21 UTC 2020


Dear all,

Following our last Telco meeting, here it is some answer regarding the PCEP protocol. First, as mention in RFC5440 section 4.2.1 https://tools.ietf.org/html/rfc5440#section-4.2.1 /  Only one PCEP session can exist between a pair of PCEP peers at any////one time. Only one TCP connection on the PCEP port can exist between////a pair of PCEP peers at any one time./ 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)
https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/ that aims to give the possibility to configure SR Policy defined in Segment Routing Policy Architecture https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ 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

Le 09/06/2020 à 18:41, olivier.dugeon at orange.com a écrit :
> Dear all,
> Next Telco meeting is tomorrow Wednesday 10th of June 16h - 17h Paris time.
> Here it is the agenda. Perhaps we'll not have time to go through all points, but we'll try to do our best.
> - 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
> Regards
> Olivier
>
> _______________________________________________
> dev mailing list
> dev at lists.frrouting.org
> https://lists.frrouting.org/listinfo/dev
-- 
Orange logo <http://www.orange.com>

 

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

 

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dugeon at orange.com <mailto:olivier.dugeon at orange.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20200616/f4ebc7a2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: small_logo.png
Type: image/png
Size: 219 bytes
Desc: not available
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20200616/f4ebc7a2/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5866 bytes
Desc: Signature cryptographique S/MIME
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20200616/f4ebc7a2/attachment.bin>


More information about the dev mailing list