Hello Brad, Thanks a lot for opening the git repo. I'll have a look to both pathd & pceplib against ODL. I'll take you inform about the result. I take the opportunity to re-transcript the proposal I made following a discussion we have with Sébastien about the RFC 8231 conformity versus Cisco and Juniper implementation. /The spirit of PCReport and thus synchronisation is to report network LSP state, not LSP configuration. So, in normal situation, I mean day life of an operator, the router is fire up, PCEP session is established (so it reports 0 LSP) and then when operator configures new LSP for which LSP need a valid ERO. This ERO could be obtain in 3 different way:/ * /Static configuration,/ * /Local computation,/ * /Remote Computation./ /1 & 2 depend of PCC while 3 depends of PCE. If the LSP is marked as delegated & dynamic path, then in respect of RFC 8231 section 5.8 (and in particular 5.8.1 & 5.8.2) the PCC must first sends a PCreq message to obtain the valid ERO prior ro send a PCReport for this LSP./ /Of course we need to manage special case. In particular when LSP are created before PCEP session is established. Always in RFC 8231 section 6.1 this time, the PCReport message definition mention that the PCC may report LSP with an empty ERO./ /But, all in all, this is at the end implementation specific. I mean that, if some LSP have no valid ERO, PCC is not obliged to report them. These LSPs exist only in the configuration, not in the network. And PCEP is here to control network LSP not configuration. PCEP is not a management protocol like NetConf./ /So, when the PCC synchronizes LSP after opening a PCEP session, it could report only LSPs that have a valid ERO, and then send PCReq message for these LSPs to get a valid ERO if configuration of LSPs are done prior to the establishment of the PCEP session.// / /If the PCC decides to report these LSPs, the RFC 8231 doesn't guarantee that the PCC will receive a valid path with a PCUpdate message in turn. Again, the RFC 8231 doesn't forbid this scenario, but it is implementation specific. Juniper and Cisco do that, ODL not.////What it is explicitly forbidden, is to use a PCReport to request a Path Computation and to use a PCReq while the LSP is delegate//d. // //Now, regarding the compatibility with both RFC and vendor specific implementation, I would suggest to not synchronize LSPs that have not a valid ERO. And for these LSPs, start by sending a PCReq message and start a timer. If the PCC get a PCRep message with a valid ERO, then it could enforce the tunnel (SR or RSVP-TE) and sends a PCReport accordingly. If the PCC get a NO-PATH object with the PCRep, it must just change the status of the LSP. So that the operator could see that there is no valid path when performing a show tunnel ... CLI. If the timer expires, then the PCC sends a PCReport with an empty ERO and again start a timer. If the PCC get a PCUpdate message with a valid ERO, it processes it as for the PCRep message. If the timer expires, the PCC do the same as for the NO-PATH object./ /Once the PCEP session is established, whe a new LSP is created, the PCC starts by sending a PCReq message to get a valid ERO, arming again a timer. If PCC receives a PCRep message, it enforces the LSP with the valid ERO or mark LSP with 'invalid Path' if it gets a NO-PATH Object. If the the timer expires, the PCC continue by sending the PCReport with an Empty ERO and arm again a timer. If it received a valid ERO through a PCEUpdate message, it enforces the LSP with the valid path and if the timer expires, it mark the LSP with 'invalid Path'. / I think we are compatible with both standard and non standard PCE with this scenario. Fill free to comments. Regards Olivier Le 28/05/2020 à 18:11, Brady Johnson a écrit :
Hello,
This is my first email to FRR :)
I work for Volta Networks and I am based out of Madrid, Spain.
Yesterday in the FRR Telco meeting, Sebastien from Netdef presented the work we have been doing together on the pathd daemon for SR-TE and a PCEP PCC. We mentioned the PCEPlib library that I wrote that pathd links-in for the PCEP protocol communication. We mentioned that we would be upstreaming the PCEPlib library soon. Well, I created a repo in our public github with the PCEPlib code [1] The PCEPlib is LGPL 2 licensed.
The PCEPlib has 3 branches: - master (no dev allowed here) - devel (new development here) - devel-1.0 (release branch)
The devel-1.0 branch is the latest tested version used with pathd.
The devel branch is where new development happens, but it has not been completely tested with pathd yet.
When designing and developing the PCEPlib, I had a requirement that it MUST work without FRR, so you will notice that it has its own timers and socket handling. I have new code in the devel branch that allows for callbacks to be plugged-in to the PCEPlib so that it uses memory, timers, and socket infrastructure from FRR. There are more details about this in the README [2].
We can discuss the next steps forward with the PCEPlib when we discuss merging the pathd. Meanwhile, constructive comments are welcome :)
Regards,
Brady
[1] https://github.com/volta-networks/pceplib [2] https://github.com/volta-networks/pceplib/tree/devel#pceplib-threading-model
_______________________________________________ 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> _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
