[dev] Telco meeting agenda

Brady Johnson brady at voltanet.io
Tue Jun 16 16:30:10 UTC 2020


Olivier,

The main concern I have with making a PCC daemon (PCCd) is the performance
impacts involved with the daemon acting as a relay and having to send
messages on to another process (zebra) which itself will send them on to
the destination process (either pathd or RSVPd). Instead of 1 simple decode
if the PCEPlib was included in pathd, now the messages would need to be
decoded, encoded again to be sent to zebra, which hopefully
wont decode/encode them, then sent on again to the final destination which
will need to decode it. Or in other words: 1 decode and no extra hops
compared to 2 decodes and 1 encode and 2 extra message hops.

Also, what would the format of these messages sent between the PCCd and
pathd/RSVPd? Hopefully it would just use the existing PCEP
message/object/TLVs struct's already defined in the PCEPlib and not
recreate some sub-set of the PCEP protocol.

Regarding the excerpt you quoted from the RFC spec: I think that is
referring to creating multiple PCEP sessions on the same TCP connection,
which is not what I was suggesting. What I was proposing in the meeting
last week was for pathd and RVSPd to each link in the PCEPlib, and each
open independant TCP connections towards the PCE. As you mentioned in the
meeting, this could be a problem to have multiple PCEP connections from the
same IP, but that could be easily solved by using different source IPs for
the pathd and RSVPd.

Regards,

Brady


On Tue, Jun 16, 2020 at 4:36 PM <olivier.dugeon at orange.com> wrote:

> 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 Architecturehttps://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 listdev at lists.frrouting.orghttps://lists.frrouting.org/listinfo/dev
>
> --
> [image: 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
> _______________________________________________
> dev mailing list
> dev at lists.frrouting.org
> https://lists.frrouting.org/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20200616/1b0b1b17/attachment-0001.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/1b0b1b17/attachment-0001.png>


More information about the dev mailing list