Hello,
I competely agree with Dhruv.
Design goal for stateful extension was to minimize control plane
overhead for the usual case of steady state, so that PCE resources
(which talks typically to many head end nodes) are used towards
resolving failures. This concern was always the first one raised by both
PCE and PCC implementations I talked to.
The resynchronization mechanism proposed is meant to be used as a
background maintenance task, which 'scrubs' the TED and takes a back
seat to recovering the network when LSPs churn. This cannot be done if
the PCCs re-publish the same steady state over and over -- for a network
of 1M LSPs with 1 hour refresh that amounts to ~278 PCRpt/s just to
maintain steady state. PCE implementations I have talked to have found
this mechanism sufficient to maintain enough consistency to keep
operating even in face of such bugs not being caught by QA.
Anyway, the specification does not prohibit this behavior on PCC part
and if a need arises for the PCE to request this functionality, it can
be negotiated as a separate extension at session startup.
Bye,
Robert
On 10/22/2015 06:58 AM, Dhruv Dhody wrote:
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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
