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@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@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@orange.com <mailto:olivier.dugeon@orange.com>
