[Pce] PCE working group secretary

[Jonathan Hardwick]

This email is to announce that Dan King is standing down as secretary to the 
PCE working group.  The chairs would like to place on record our thanks and 
heartfelt gratitude to Dan for all of the work he did in this role.  We look 
forward to Dan's involvement with PCE continuing long into the future as a 
technical contributor.  Thank you, Dan!

Dhruv Dhody has kindly agreed to become our new working group secretary, with 
immediate effect.  Please join us in welcoming Dhruv to the role!

All the best
Jon, Julien & JP


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

[Pce] I-D Action: draft-ietf-pce-pce-initiated-lsp-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element of the IETF.

Title   : PCEP Extensions for PCE-initiated LSP Setup in a 
Stateful PCE Model
Authors : Edward Crabbe
  Ina Minei
  Siva Sivabalan
  Robert Varga
Filename: draft-ietf-pce-pce-initiated-lsp-10.txt
Pages   : 18
Date: 2017-06-22

Abstract:
   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.

   The extensions for stateful PCE provide active control of
   Multiprotocol Label Switching (MPLS) Traffic Engineering Label
   Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates
   control over one or more locally configured LSPs to the PCE.  This
   document describes the creation and deletion of PCE-initiated LSPs
   under the stateful PCE model.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pce-initiated-lsp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-10
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pce-initiated-lsp-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pce-initiated-lsp-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [Pce] Is there any activity related to PCE graceful restart?

[stephane.litkowski]

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.
Now I see a case where the PCE needs to keep the state from a PCC when the PCC 
restarts => 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
Cc: Michael Gorokhovsky; j...@cisco.com; 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

From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Sunday, June 18, 2017 8:34 PM
To: Alexander Vainshtein 
>; 
jonathan.hardw...@metaswitch.com; 
j...@cisco.com; 
julien.meu...@orange.com
Cc: Marina Fizgeer 
>; Michael 
Gorokhovsky 
>; 
pce@ietf.org; Alexander Ferdman 
>
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;