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
