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

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@lists.frrouting.org
https://lists.frrouting.org/listinfo/dev

--

 

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@orange.com