[dev] Telco meeting agenda

Tue Jun 16 17:11:08 UTC 2020

Hello Brady,

Answer inline

Olivier

Le 16/06/2020 à 18:30, Brady Johnson a écrit :
> 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.

[OD] The new ZAPI OPAQUE message proposed by Mark is here to exchange data between
daemon without the need to encode/decode data at the Zebra layer. So, the correct
estimation from performance issue is 1 decode and no extra hops versus 1 decode
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.

[OD] As the idea is to use the ZAPI OPAQUE message, you are free to send the PCEP
request as you want to pathd and/or RSVP-TE. I don't finish to look to the code of
pathd and PCEPlib, but from my understanding, PCEPLib and pathd exchange information
from dedicated structure and not PCEP message/objects/TLVs ... You could easily
reproduced the same behaviour. The main difference is that instead to call directly
a pathd function from PCEPLib and reciprocally, you will call a pccd_zebra function
that sends the data to the pathd daemon through zebra with the same structure as you
defined between PCEPlib and pathd.

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

[OD] Definitely not. I discuss this issue with my colleague Julien Meuric co-chair
of the PCE WG at IETF, and we achieved the same conclusion: this is forbidden.
All what you propose is feasible, but definitively not in the spirit of RFC5440.
So, this is not a viable solution as you will not find a PCE server that supports
this option.

>
> Regards,
>
> Brady
>
>
> On Tue, Jun 16, 2020 at 4:36 PM <olivier.dugeon at orange.com <mailto: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 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 <mailto: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 <mailto: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>
>     _______________________________________________
>     dev mailing list
>     dev at lists.frrouting.org <mailto: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/3b649afa/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/3b649afa/attachment-0001.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/3b649afa/attachment-0001.bin>