Hi Olivier, IMHO PCEP is much closer to BGP (when compared to IGP), and in that PCE-triggered full re-sync is similar to BGP’s route-refresh mechanism. So I guess we are re-using a similar concept which scales well too :)
As you also mention that such issue might be seen on a long running session, this re-sync if needed, would be after a long time. IMHO sending PCRpt repeatedly say at every 3600 secs for all LSP would be costly too. I will leave it to the authors of the base draft to answer your other question. In the implementations that I am aware of, that is the local policy and usually set to report all LSPs. Regards, Dhruv From: Pce [mailto:[email protected]] On Behalf Of Olivier Dugeon Sent: 21 October 2015 19:43 To: Dhruv Dhody Cc: [email protected] Subject: Re: [Pce] Questions about PCE Stateful Synchronisation Hello Dhruv, Thanks pointing me this section, but I read the draft before asking my questions. For me, it is not completely cover this issue, and my answer is Yes and No. Yes, because the mechanism allow such re-synchronization without closing the PCEP session, but at the price of exchanging PCUpd / PCRpt message when only one PCRpt message is sufficient. It solves the problem of orphan LSP. In this case, I agree that when the PCE asks to update an orphan LSP it gets an error (I suppose as it is not specify in the draft). An No, because it not solves completely the issue if the PCE is not aware of an LSP. The PCE could not request an update about an LSPs it ignores. So, the only working solution for the PCE is to ask regularly all PCCs to send their complete LSP DB to be sure that it is always synchronized, but it is a very costly mechanism. In addition, I have some doubt that this mechanism scale well. For large networks, say more then 1000 PE routers, so more than 1000 PCEP sessions, with a full mesh of TE tunnels (I know it is an extreme case) this increase drastically the exchange between the PCE and PCCs and add extra CPU process for the PCE. The later must parse 1,000,000 tunnels in its LSPs DB and ask PCCs to refresh them. Or, asks all PCCs to update all their tunnels. In the first case the PCE spent its time to send PCUpd message waiting for the corresponding PCRpt answer and in the second case it spent its time to parse 1000 tunnels each time it asks a PCC for a full refresh. Flood periodically Link State in IGP protocol has proof for a long time that it scale well even in very large network. Why not re-using a similar concept ? And, last but not least, what's happen with LSP tunnels that are configured on router that are not PCEP enable ? There are simply ignored ? Regards, Olivier Le 21/10/2015 15:01, Dhruv Dhody a écrit : 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]<mailto:[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]> <mailto:[email protected]<mailto:[email protected]>> _______________________________________________ Pce mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
