Hi Dhruv,

If the PCE keeps a "stale state" from the PCC, in the framework of state-sync, 
we need a way to indicate to other PCEs that the state is stale, so if the 
master PCE is another PCE, it will not try to update the state for this LSP 
until  the PCC is back online.

Brgds,


From: Dhruv Dhody [mailto:dhruv.dh...@huawei.com]
Sent: Thursday, June 22, 2017 11:23
To: LITKOWSKI Stephane OBS/OINIS; Alexander Vainshtein; adr...@olddog.co.uk
Cc: Marina Fizgeer; Michael Gorokhovsky; pce@ietf.org; j...@cisco.com; 
Alexander Ferdman
Subject: RE: [Pce] Is there any activity related to PCE graceful restart?

Hi Stephane, Sasha,

I agree with your overall assessment.

Finer point inline...

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>
Sent: 22 June 2017 13:44
To: Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
Cc: Marina Fizgeer 
<marina.fizg...@ecitele.com<mailto:marina.fizg...@ecitele.com>>; Michael 
Gorokhovsky 
<michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; j...@cisco.com<mailto:j...@cisco.com>; 
Alexander Ferdman 
<alexander.ferd...@ecitele.com<mailto:alexander.ferd...@ecitele.com>>
Subject: Re: [Pce] Is there any activity related to PCE graceful restart?

Hi Sasha,

As Dhruv mentioned, restarting a PCE is not a big deal, we have already the 
mechanism defined to handle this without traffic disruption.
Your email mentions also, PCC control plane restart which is a bit more tricky 
IMO.

>From a PCC point of view, I think you request the PCC to keep the dataplane 
>intact when the PCC process or RSVP process or IS-IS is getting down (during 
>failure or restart or upgrade...). For the PCC process, I think this could be 
>addressed by a purely local mechanism.
[[Dhruv Dhody]] I agree. IMO the PCC process can rebuild its state from a local 
mechanism, say by data plane (SR label stack), by learning from TE manager, 
RSVP-TE process etc. The session establishment with PCE should be triggered 
once the state is build, so that state synchronization (and optimizations) work 
well.
And incase this is not possible, the traffic can continue to flow in the old 
path till a new path is signaled after restart. Is there a case where the 
traffic gets impacted and a protocol mechanism can solve it?

Now I see a case where the PCE needs to keep the state from a PCC when the PCC 
restarts =>
[[Dhruv Dhody]] Also, when to delete the state learned from the PCC at the 
Stateful PCE is also a local matter of the PCE. The State time out is specified 
from PCC point of view, at PCE the behavior is up to the implementation. For 
disjoint cases, good to keep the state longer at PCE :)

Regards,
Dhruv

my favorite disjointness use case or any other use case where LSPs on other 
PCCs depends on the LSP of the PCC which is restarting.

Let's say that PCC1 owns LSP1, PCC2 owns LSP2.
LSP1 and LSP2 depends of each other.
If the PCE loses the state of LSP1 because PCC1 restarts, it may reroute LSP2 
on a path that does not fulfill the dependency of the two LSPs anymore while at 
the same time LSP1 was kept intact by PCC1 from a forwarding plane point of 
view.

Is it a critical issue ? During a transient period (the PCC restart), some LSPs 
may not fulfil their constraint anymore. Does it justify extensions to the 
protocol ?
I do not have a strong opinion on that: it's always a question of complexity to 
introduce vs gain.


Adrian, Dhruv, did I miss something ? Am I wrong ?

Brgds,

Stephane


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Monday, June 19, 2017 14:48
To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
Cc: Michael Gorokhovsky; j...@cisco.com<mailto:j...@cisco.com>; 
pce@ietf.org<mailto:pce@ietf.org>; Marina Fizgeer; Alexander Ferdman
Subject: Re: [Pce] Is there any activity related to PCE graceful restart?

Adrian,
Lots of thanks for a prompt response.

However, our primary interest is the control plane (including PCC) restart in a 
network element with separated  control and forwarding planes.

Specifically, my colleagues and I try to understand, how to make such a restart 
non-traffic affecting while:

-          The network uses Segment Routing for setting up paths computed by 
the PCE. This means that these paths are only known to their respective 
head-end nodes. This situation is different from the scenario where RSVP-TE is 
used to signal these paths, since they cannot be re-learned from the neighbors 
as part of the RSVP-TE graceful restart procedures

-          The protocols used for distributing SR-related information (i.e., 
IGP and BGP SR extensions) are GR-capable, and GR for them is enabled in the 
network

-          The PCE is an active stateful PCE, i.e., it instructs the head-end 
node, which paths should be set up without any requests coming from the nodes.

Hopefully this clarifies the context for our question.

It may well be that the requirement for non-traffic affecting control plane 
restart can be addressed without any changed to the existing protocols. 
Alternatively, it  is possible that some minor changes (like making the PCE 
aware of separation between the control and forwarding planes, negotiation of 
GR capabilities and grace periods etc.) are required.

Any inputs would be highly appreciated.

Regards, and lots fo thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Sunday, June 18, 2017 8:34 PM
To: Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>; 
j...@cisco.com<mailto:j...@cisco.com>; 
julien.meu...@orange.com<mailto:julien.meu...@orange.com>
Cc: Marina Fizgeer 
<marina.fizg...@ecitele.com<mailto:marina.fizg...@ecitele.com>>; Michael 
Gorokhovsky 
<michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; Alexander Ferdman 
<alexander.ferd...@ecitele.com<mailto:alexander.ferd...@ecitele.com>>
Subject: RE: [Pce] Is there any activity related to PCE graceful restart?

Sasha,

What are you hoping to achieve?

That a restarting PCE can retain its TED and LSP-DB?
That a restarting PCE can synch state with the network?
That a restarting PCE with outstanding (unanswered) messages in either 
direction can not need to resend them?
That a restarting PCE can resend outstanding (unanswered) messages without 
problems caused by duplication?

I think you may want to read around the definition of the request-id. Although 
5440 doesn't make it explicit, a lot comes from how you process the request-id. 
That "a lot" arose from consideration of parallel sessions and distilled to not 
needing to write about restart.

Cheers,
Adrian (resurrecting old memories, possibly not entirely accurately)

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: 18 June 2017 16:43
To: jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>; 
j...@cisco.com<mailto:j...@cisco.com>; 
julien.meu...@orange.com<mailto:julien.meu...@orange.com>
Cc: Marina Fizgeer; Michael Gorokhovsky; pce@ietf.org<mailto:pce@ietf.org>; 
Alexander Ferdman
Subject: Re: [Pce] Is there any activity related to PCE graceful restart?

Re-sending with the correct WG mailing list address...

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: Alexander Vainshtein
Sent: Sunday, June 18, 2017 6:41 PM
To: 'jonathan.hardw...@metaswitch.com' 
<jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>>; 
'j...@cisco.com' <j...@cisco.com<mailto:j...@cisco.com>>; 
'julien.meu...@orange.com' 
<julien.meu...@orange.com<mailto:julien.meu...@orange.com>>
Cc: 'p...@ietf.prg' <p...@ietf.prg<mailto:p...@ietf.prg>>; Michael Gorokhovsky 
<michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>; 
Marina Fizgeer <marina.fizg...@ecitele.com<mailto:marina.fizg...@ecitele.com>>; 
Alexander Ferdman 
<alexander.ferd...@ecitele.com<mailto:alexander.ferd...@ecitele.com>>
Subject: Is there any activity related to PCE graceful restart?

Hi all,
My colleagues and I tried to find any work in the PCE WG related to PCEP 
graceful restart.
So far, we did not succeed. This could mean one of the following:

-          Our search did not go deep enough. In this case pointers to any 
specific documents would be highly appreciated

-          Such work does not exist because (for some reason) it is not 
required. This looks problematic to me, especially if we deal with a stateful  
active PCE and the path computed by the PCE was implemented using Segment 
Routing (so that only the head end of the computed path is aware of the path). 
However, I could have missed something obvious, and any clarifications would be 
highly appreciated

-          Such work is required but, so far, nobody has taken care of it. The 
implications are obvious:-(.

Your feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___________________________________________________________________________

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Reply via email to