[Pce] I-D Action: draft-ietf-pce-stateful-pce-21.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 Stateful PCE
Authors : Edward Crabbe
  Ina Minei
  Jan Medved
  Robert Varga
Filename: draft-ietf-pce-stateful-pce-21.txt
Pages   : 54
Date: 2017-06-20

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.

   Although PCEP explicitly makes no assumptions regarding the
   information available to the PCE, it also makes no provisions for PCE
   control of timing and sequence of path computations within and across
   PCEP sessions.  This document describes a set of extensions to PCEP
   to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.


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

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

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


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?

[Jeff Tantsura]

+1 Adrian.
complexity associated with GR (additional state/signaling/etc) wouldn’t be 
justified, given existing means to provide synchronization. 
 
Cheers,
Jeff
 

On 6/19/17, 08:21, "Pce on behalf of Adrian Farrel"  wrote:

Hi Sasha,

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

Yup. I assumed control plane restart was the issue.

> 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

OK, so you are less worried about PCE restart than about restart of control
plane elements in the network.
But you are using SR so there is no state (or rather only routing state) in 
the
network. The state for the path is at the PCE and at the headend, and 
nowhere
else.
So, if a network node restarts, it doesn't matter.
If the headend loses state it must relearn it from the PCE. If the PCE loses
state it must relearn it from the headend.

> - 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

Right. So that is additional reason to not worry about restart elsewhere 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. 

This makes life easier because we know that the PCE has pushed all of the 
paths.
So restart is just  matter of pushing all of those paths again.

It is an implementation question whether the restart has preserved 
forwarding
plane state. In this case, forwarding plane state is "classification"
information, that is "packets of this type get this SID stack".

If the forwarding state is saved, data can continue to flow. Restart is 
about
making sure that the PCE and headend are in synch.
If forwarding state is not saved, the PCE must resynch the state before the
headend can use it.

It is certainly the case that the failure of a PCEP session does not result 
in
discard of headend state. That is, the headend can continue to operate 
using any
state that was pushed by a PCE even after that PCE has failed. This might be
termed "non-stop forwarding" in some protocols in the middle of the 
network, but
is just normal business for a stateful active PCE.

> Hopefully this clarifies the context for our question.

It does.

> 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.

My take-away from the swamp of text above is that:
- Network nodes don't need to do anything special except in their
   relationship with the PCE
- A stateful PCE needs to resynch pushed paths for all paths that it has
   responsibility for upon reconnection with a network node

Now we can go and look at the stateful I-D and the PCE-initiated I-D to see
whether we already have enough stuff in the protocol. My belief is that we 
do.

Cheers,
Adrian

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



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