Hi Olivier, Wanted to bring "PCE triggered re-syncronization" [ https://tools.ietf.org/html/draft-ietf-pce-stateful-sync-optimizations-03#section-6] to your notice. This can be used by a PCE to periodically re-synchronize the database without bringing down the PCEP session.
Will this not cover the issue you have in mind? Regards, Dhruv On Wed, Oct 21, 2015 at 3:29 PM, Olivier Dugeon <[email protected]> wrote: > Dear authors of draft-ietf-pce-stateful and > draft-ietf-pce-stateful-sync-optimizations, > > I know that we are in the last miles before publish PCE Stateful draft > collection as RFCs, but regarding the chairs' review, I have a global > interrogation about synchronisation. Even I-Ds try to avoid it, I'm afraid > that there will different cases where de-synchronisation is not avoided > between PCCs and PCEs. In particular, in case of problem, not a real > failure, more a bug, memory saturation or whatever mal-function could occur > on the PCE or PCC side, a PCE could miss a PCRpt message from a PCC or > respectively a PCC could miss to send a PCRpt message to a PCE. I'm also > afraid, after a long live period (say, several weeks or months) that some > orphan LSPs appear in the PCE LSPs database without the possibility to > detect them and remove them. > > To go back in a full sync state, it is then necessary to restart properly > the PCEP session, i.e. force a re-synchronisation. But, to do that, you > need to discover the problem. That's another topic. > > So, my question is why do you not have use a similar mechanism to routing > protocol, i.e. OSPF, IS-IS or BGP, to periodically send LSPs state from the > PCC to the PCE. Using an 'out of date' indication will allow the PCE to > remove in its LSP-DB 'out of date' LSPs like OSPF do when it flushes an LSA > with ageing equal to 3600 in its TED. > > What it is sufficient is to add a new statement in draft-ietf-pce-stateful > (e.g., in section 9.1. Control Function and Policy) telling that: > - the PCC MUST send PCRpt message on a regular basis, before MAX_AGE > expire. > - the PCE MUST ignore LSPs that are not refresh since a period of time > greater than MAX_AGE. > > Then, two cases are possible: > a) MAX_AGE is fixed in the RFC e.g. to 3600 seconds like in OSPF (seems > reasonable) > b) Negotiate/exchange during PCEP session establishment or when PCRpt > message is sent > > If option (a) is quiet simple but not flexible, it has the great advantage > to not introduce new PCEP Object while option (b) need new PCEP Object > definition, but provide a greater flexibility. > > If we agree on the statement above, I think that option (a) is sufficient > and just need additional text in current draft while if we want to support > option (b), I could work on a new draft. > > Regards, > > Olivier > -- > logo Orange <http://www.orange.com> > > Olivier Dugeon > Orange Expert, Future Networks > Open Source Referent > Orange/IMT/OLN/WTC/IEE/OPEN > > fixe : +33 2 96 05 28 80 > mobile : +33 6 82 90 37 85 > [email protected] <mailto:[email protected]> > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
