[Pce] Questions about PCE Stateful Synchronisation

[Olivier Dugeon <[e-mail]>]

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 : [phone]
mobile : [phone]
[e-mail] <mailto:[e-mail]>