<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-pce-stateful-pce-app-06" ipr="trust200902">
  <front>
    <title abbrev="Applicability for a Stateful PCE">
    Applicability of a Stateful Path Computation Element (PCE) </title>

	<author fullname="Xian Zhang" initials="X." surname="Zhang" role="editor">
      <organization>Huawei Technologies</organization>
      <address>
	<postal>
	  <street>F3-5-B R&amp;D Center, Huawei Industrial Base, Bantian, Longgang District
</street>
	  <city>Shenzhen</city>
	  <region>Guangdong</region>
	  <code>518129</code>
	  <country>P.R.China</country>
	</postal>
	<email>zhang.xian@huawei.com</email>
      </address>
    </author>
	
	 <author fullname="Ina Minei" initials="I." surname="Minei" role="editor">
      <organization>Google, Inc.</organization>
      <address>
	<postal>
	  <street>1600 Amphitheatre Parkway</street>
	  <city>Mountain View</city>
	  <region>CA</region>
	  <code>94043</code>
	  <country>US</country>
	</postal>
	<email>inaminei@google.com</email>
      </address>
    </author>
	

    <date day="07" month="July" year="2016" />


    <workgroup>PCE Working Group</workgroup>

    <abstract>
	<t>
	A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) 
	characteristics and resource usage within a network in order to provide traffic engineering 
	calculations for its associated Path Computation Clients (PCCs).  This document describes general 
	considerations for a stateful PCE deployment and examines its applicability and benefits, as well
	as its challenges and limitations through a number of use cases.  PCE Communication Protocol 
	(PCEP) extensions required for stateful PCE usage are covered in separate documents.
	</t>
    </abstract>

  </front>

  <middle>
	
   
   <section title="Introduction">
      <t><xref target="RFC4655"/> defines the architecture for a Path Computation Element 
	  (PCE)-based model for the computation of Multiprotocol Label Switching (MPLS) and 
	  Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs).  
	  To perform such a constrained computation, a PCE stores the network topology 
	  (i.e., TE links and nodes) and resource information (i.e., TE attributes) in
	  its TE Database (TED).  <xref target="RFC5440"/> describes the Path Computation Element
      Protocol (PCEP) for interaction between a Path Computation Client (PCC) and a PCE, 
	  or between two PCEs, enabling computation of TE LSPs. Extensions for support of GMPLS in 
	  PCEP are defined in <xref target='I-D.ietf-pce-gmpls-pcep-extensions'></xref>.</t>
	  
	  <t> 
	  As per <xref target="RFC4655"/>, a PCE can be either stateful or stateless.  A stateful PCE
	  maintains two sets of information for use in path computation.  The first is the Traffic 
	  Engineering Database (TED) which includes the topology and resource state in the network. 
	  This information can be obtained by a stateful PCE using the same mechanisms as a stateless 
	  PCE (see <xref target="RFC4655"/>).  The second is the LSP State Database (LSP-DB), 
	  in which a PCE stores attributes of all active LSPs in the network, such as their paths 
	  through the network, bandwidth/resource usage, switching types and LSP constraints.
	  This state information allows the PCE to compute constrained paths while considering individual LSPs 
	  and their inter-dependency.  However, this requires reliable state synchronization mechanisms
	  between the PCE and the network, between the PCE and the PCCs, and between cooperating PCEs,
	  with potentially significant control plane overhead and maintenance of
     a large amount of state data, as explained in <xref target="RFC4655"/>. 
	  </t>	 
	  
	  <t> This document describes how a stateful PCE can be used to solve various problems
	  for MPLS-TE and GMPLS networks, and the benefits it brings to such deployments.  
	  Note that alternative solutions relying on stateless PCEs may also be
	  possible for some of these use cases, and will be mentioned for completeness 
	  where appropriate.
	  </t> 
	  
    </section> <!-- Introduction -->

    <section title="Terminology">
      <t>This document uses the following terms defined in <xref
      target="RFC5440"/>: PCC, PCE, PCEP peer.</t>
     
      <t>This document uses the following terms defined in 
	  <xref target='I-D.ietf-pce-stateful-pce'></xref>: Passive Stateful
	  PCE, Active Stateful PCE, Delegation, Revocation, Delegation Timeout Interval, 
	  LSP State Report, LSP Update Request, LSP State Database. </t>

	 <t> This document defines the following term:
	 <list style="hanging">
		<t hangText="Minimum Cut Set:"> the minimum set of links for a specific
		source destination pair which, when removed from the network, results in
		a specific source being completely isolated from specific destination.  
		The summed capacity of these links is equivalent to the maximum capacity
		from the source to the destination by the max-flow min-cut theorem.</t>
     </list>
     </t>
    </section> <!-- Terminology -->

	<section anchor="Stateful-PCE-overview" title="Overview of the Stateful PCE Protocol Extensions">
	
	<t> This section is included for the convenience of the reader, please refer to the 
	referenced documents for details of the operation. </t>
	
	  <t> <xref target='I-D.ietf-pce-stateful-pce'></xref>
	  specifies a set of extensions to PCEP to enable stateful
      control of LSPs within and across PCEP sessions in compliance with
      <xref target="RFC4657"/>.  It includes mechanisms to effect LSP state
      synchronization between PCCs and PCEs, delegation of control over LSPs to
      PCEs, and PCE control of timing and sequence of path computations within
      and across PCEP sessions.</t>
	  
	  <t><xref target='I-D.ietf-pce-stateful-pce'></xref> applies equally to MPLS-TE and 
	  GMPLS LSPs and distinguishes between an active and a passive stateful PCE.  A passive
	  stateful PCE uses LSP state information to optimize path computations 
	  but does not actively update LSP state.  In contrast, an active stateful PCE may issue 
	  recommendations to the network.  For example, an active stateful PCE may update LSP 
	  parameters in those PCCs that delegated control over their LSPs to the PCE.</t>
	   
	   
	  <t>Several new functions are added in PCEP to support both active and passive stateful
		  PCEs. They are described in <xref target='I-D.ietf-pce-stateful-pce'></xref>.
		  A function can be initiated either from a PCC towards a PCE (C-E) or
		  from a PCE towards a PCC (E-C). The new functions are:

		  <list style="hanging">
			<t hangText="Stateful Capability negotiation (E-C,C-E):"> both the PCC and the
			PCE must announce during PCEP session establishment that they support
			 stateful PCE PCEP extensions.</t>

			<t hangText="LSP state synchronization (C-E):"> after the session between a PCC
			and a stateful PCE is initialized, the PCE can perform path computation and 
			update attributes in a PCC. However, if the goal of the PCE is to provide accurate
			path information based on the most up-to-date state of the network, 
			the PCE should wait until it learns the state of the PCC's LSP states before doing
			so.</t>

			<t hangText="LSP update request (E-C):"> A PCE requests the modification of
			one or more attributes (e.g., route) on a PCC's LSP.</t>

			<t hangText="LSP state report (C-E):"> a PCC sends an LSP state report
			to a PCE whenever the state of an LSP changes.</t>

			<t hangText="LSP control delegation (C-E,E-C):"> a PCC grants to a PCE
			the right to update LSP attributes on one or more LSPs; the PCE becomes
			the authoritative source of the LSP's attributes as long as the
			delegation is in effect; the PCC may withdraw the delegation or 
			the PCE may give up the delegation.</t>
		  </list>
		  </t>
	  	  
	<t> <xref target='I-D.ietf-pce-pce-initiated-lsp'></xref> provides extensions to PCEP which enable
        the setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model, 
		without the need for local configuration on the PCC, thus allowing for a dynamic network
		that is centrally controlled and deployed.</t>
		
	<t><xref target='I-D.ietf-pce-stateful-pce'></xref> defines the extensions 
	  needed to support auto-discovery of stateful PCEs when using IGP for PCE discovery.</t> 
	</section> <!-- Overview of stateful PCE --> 
	
	 <section anchor="Deployment-considerations" title="Deployment Considerations">

	 <t> This section discusses generic issues with stateful PCE deployments, and 
	 how specific protocol mechanisms can be used to address them. 
	 </t> 
	 
		 <section anchor="Mixed-deployment" title="Multi-PCE Deployments">
			<t>Stateless and stateful PCEs can co-exist in the same network and be in charge 
			of path computation of different types. To solve the problem of distinguishing between 
			the two types of PCEs, either discovery or configuration may be used.  
			The capability negotiation in <xref target='I-D.ietf-pce-stateful-pce'></xref> ensures 
			correct operation when the PCE address is configured on the PCC. </t>
			
			<t>Multiple stateful PCEs can co-exist in the same network. These PCEs may provide 
			redundancy for load sharing, resilience, or partitioning of computation features. 
			Regardless of the reason for multiple PCEs, an LSP is only delegated to one of the PCEs 
			at any given point in time. <xref target='I-D.ietf-pce-stateful-pce'></xref> describes 
			how LSPs can be re-delegated between PCEs, and the procedures on a PCE failure. 
			<xref target="RFC7399"></xref> discusses various approaches for 
			synchronizing state among the PCEs when multiple PCEs are used for load sharing or backup and
			compute LSPs for the same network.</t> 
		 </section> <!-- Multi-PCE deployments --> 
		 
		 <section anchor="LSP-DB-sync" title="LSP State Synchronization">
			<t> The population of the LSP-DB using information received from PCCs is supported by 
			the stateful PCE extensions defined in <xref target='I-D.ietf-pce-stateful-pce'></xref> 
			, i.e., via LSP state report messages. Population of the LSP database via other means 
			is not precluded.</t>
			
			<t>  Because the accuracy of the computations depends on the accuracy of the databases
			used, it is worth noting that the PCE view lags behind the true state of the network, 
			because the updates must reach the PCE from the network. Thus, the use of stateful
			PCE reduces but cannot eliminate the possibility of crankbacks, nor can it guarantee
			optimal computations all the time. <xref target="RFC7399"></xref> discusses
			these limitations and potential ways to alleviate them. </t>
			
			<t>  In case of multiple PCEs with different capabilities, co-existing in the 
			same network, such as a passive stateful PCE and an active stateful PCE, 
			it is useful to refer to a LSP, be it delegated or not, by a unique 
			identifier instead of providing detailed information (e.g., route, 
			bandwidth etc.) associated with it, when these PCEs	
 			cooperate on path computation, such as for load sharing. </t>
				
		 </section> <!-- LSP state synchronization --> 
		 
		 <section anchor="PCE-survivability" title="PCE Survivability">
			<t> For a stateful PCE, an important issue is to get the LSP state information 
			 resynchronized after a restart. <xref target='I-D.ietf-pce-stateful-pce'></xref> defines a 
			 synchronization function and procedure, allowing a PCC to synchronize its LSP 
			 state with the PCE and <xref target='I-D.ietf-pce-stateful-sync-optimizations'></xref> specifies 
			 optimizations to the synchronization procedure.  LSP state synchronization procedures can be applied 
			 equally to a network node or another PCE, allowing 
			 multiple ways of re-acquiring the LSP database on a restart.  Because synchronization
			 may also be skipped, if a PCE implementation has the means to retrieve its database in 
			 a different way (for example from a backup copy stored locally), the state can be restored 
			 without further overhead in the network. A hybrid approach where the bulk of the state is 
			 recovered locally, and a small amount of state is reacquired from the network, is also possible.
			 Note that locally recovering the state would still require some degree of resynchronization 
			 to ensure that the recovered state is indeed up-to-date. Depending on the resynchronization 
			 mechanism used, there may be an additional load on the PCE, and there may be a delay in reaching 
			 the synchronized state, which may negatively affect survivability. Different resynchronization 
			 methods are suited for different deployments and objectives. 
			 </t> 
		 </section> <!-- PCE survivability --> 
	 </section> <!-- Deployment considerations --> 

	 
	 <section anchor="Application-scenarios" title="Application Scenarios">
	     <t>In the following sections, several use cases are described, showcasing
		 scenarios that benefit from the deployment of a stateful PCE. </t>
	
      <section anchor="Global-visibility" title="Optimization of LSP Placement">
	 
	  <t>The following use cases demonstrate a need for visibility into
	  global LSP states in PCE path computations, and for a PCE
	  control of sequence and timing in altering LSP path characteristics
	  within and across PCEP sessions.  Reference topologies for the use
	  cases described later in this section are shown in Figures <xref
	  target="Reference-topology-1" format="counter"/> and <xref
	  target="Reference-topology-2" format="counter"/>.</t>

	  <t>Some of the use cases below are focused on MPLS-TE deployments, but may
	  also apply to GMPLS.  Unless otherwise cited, use cases assume that all LSPs
	  listed exist at the same LSP priority. </t> 
	  
	  <t>
	  The main benefit in the cases below comes from moving away from an asynchronous
	  PCC-driven mode of operation to a model that allows for central control over LSP
	  computations and maintenance, and focuses specifically on the active stateful PCE model 
	  of operation. </t>

	  <figure anchor="Reference-topology-1" title="Reference topology 1">
	  <artwork><![CDATA[
       +-----+
       |  A  |
       +-----+
              \
               +-----+                      +-----+
               |  C  |----------------------|  E  |
               +-----+                      +-----+
              /        \      +-----+      /
       +-----+          +-----|  D  |-----+
       |  B  |                +-----+
       +-----+
   	    ]]></artwork>
	  </figure>

	  <figure anchor="Reference-topology-2" title="Reference topology 2">
	  <artwork><![CDATA[
            +-----+        +-----+        +-----+
            |  A  |        |  B  |        |  C  |
            +--+--+        +--+--+        +--+--+
               |              |              |
               |              |              |
            +--+--+        +--+--+        +--+--+
            |  E  +--------+  F  +--------+  G  |
            +-----+        +-----+        +-----+
          
   	    ]]></artwork>
	  </figure>


	  
	  <section anchor="Bin-Packing" title="Throughput Maximization and Bin Packing">
	    <t> Because LSP attribute changes in <xref target="RFC5440"/> are
	    driven by Path Computation Request (PCReq) messages under control of a PCC's local timers, the
	    sequence of resource reservation arrivals occurring in the network will
	    be randomized. This, coupled with a lack of global LSP state
	    visibility on the part of a stateless PCE may result in suboptimal
	    throughput in a given network topology, as will be shown in the example
		below. 
		</t>
	    
	    <t>Reference topology 2 in <xref target="Reference-topology-2"/> and
	    Tables <xref target="Throughput-link-parameters" format="counter"/>
	    and <xref target="Throughput-demand" format="counter"/> show an
	    example in which throughput is at 50% of optimal as a result of lack
	    of visibility and synchronized control across PCC's.  In this
	    scenario, the decision must be made as to whether to route any
	    portion of the E-G demand, as any demand routed for this source and
	    destination will decrease system throughput. </t>

	    <texttable anchor="Throughput-link-parameters" 
		       title="Link parameters for Throughput use case">
	      <ttcol align="center">Link</ttcol>
	      <ttcol align="center">Metric</ttcol>
	      <ttcol align="center">Capacity</ttcol>
	      <c>A-E</c><c>1</c><c>10</c>
	      <c>B-F</c><c>1</c><c>10</c>
	      <c>C-G</c><c>1</c><c>10</c>
	      <c>E-F</c><c>1</c><c>10</c>
	      <c>F-G</c><c>1</c><c>10</c>
	    </texttable>

	    <texttable anchor="Throughput-demand" 
		       title="Throughput use case demand time series">
	      <ttcol align="center">Time</ttcol>
	      <ttcol align="center">LSP</ttcol>
	      <ttcol align="center">Src</ttcol>
	      <ttcol align="center">Dst</ttcol>
	      <ttcol align="center">Demand</ttcol>
	      <ttcol align="center">Routable</ttcol>
	      <ttcol align="center">Path</ttcol>
	      <c>1</c><c>1</c><c>E</c><c>G</c><c>10</c><c>Yes</c><c>E-F-G</c>
	      <c>2</c><c>2</c><c>A</c><c>B</c><c>10</c><c>No</c><c>---</c>
	      <c>3</c><c>1</c><c>F</c><c>C</c><c>10</c><c>No</c><c>---</c>
	    </texttable>

	    <t>In many cases throughput maximization becomes a bin packing
	    problem. While bin packing itself is an NP-hard problem, a number of
	    common heuristics which run in polynomial time can provide
	    significant improvements in throughput over random reservation event
	    distribution, especially when traversing links which are members of
	    the minimum cut set for a large subset of source destination pairs.
	    </t>

	    <t> Tables <xref target="BinPack-link-parameters" format="counter"/>
	    and <xref target="BinPack-demand" format="counter"/> show a simple
	    use case using Reference Topology 1 in <xref
	    target="Reference-topology-1"/>, where LSP state visibility and
	    control of reservation order across PCCs would result in significant
	    improvement in total throughput.</t>

	    <texttable anchor="BinPack-link-parameters" 
		       title="Link parameters for Bin Packing use case">
	      <ttcol align="center">Link</ttcol>
	      <ttcol align="center">Metric</ttcol>
	      <ttcol align="center">Capacity</ttcol>
	      <c>A-C</c><c>1</c><c>10</c>
	      <c>B-C</c><c>1</c><c>10</c>
	      <c>C-E</c><c>10</c><c>5</c>
	      <c>C-D</c><c>1</c><c>10</c>
	      <c>D-E</c><c>1</c><c>10</c>
	    </texttable>

	    <texttable anchor="BinPack-demand" 
		       title="Bin Packing use case demand time series">
	      <ttcol align="center">Time</ttcol>
	      <ttcol align="center">LSP</ttcol>
	      <ttcol align="center">Src</ttcol>
	      <ttcol align="center">Dst</ttcol>
	      <ttcol align="center">Demand</ttcol>
	      <ttcol align="center">Routable</ttcol>
	      <ttcol align="center">Path</ttcol>
	      <c>1</c><c>1</c><c>A</c><c>E</c><c>5</c><c>Yes</c><c>A-C-D-E</c>
	      <c>2</c><c>2</c><c>B</c><c>E</c><c>10</c><c>No</c><c>---</c>
	    </texttable>
	  </section> <!-- Bin packing --> 

	  <section anchor="Deadlock" title="Deadlock">
	    
	    <t>This section discusses a use case of cross-LSP impact under 
		degraded operation.  Most existing RSVP-TE implementations will not 
		tear down established LSPs in the event of the failure of the bandwidth
	    increase procedure detailed in <xref target="RFC3209"/>. This
	    behavior is directly implied to be correct in <xref
	    target="RFC3209"/> and is often desirable from an operator's
	    perspective, because either a) the destination prefixes are not
	    reachable via any means other than MPLS or b) this would result in
	    significant packet loss as demand is shifted to other LSPs in the
	    overlay mesh.</t>
		
		
	    <t>In addition, there are currently few implementations offering
	    dynamic ingress admission control (policing of the traffic volume mapped
		onto an LSP) at the label edge router (LER).  Having ingress admission control on a per LSP basis
		is not necessarily desirable from an operational perspective, as a) one must 
		over-provision tunnels significantly in order to avoid deleterious effects
	    resulting from stacked transport and flow control systems (for 
		example for tunnels that are dynamically resized based on current traffic) and b)
	    there is currently no efficient commonly available northbound interface for dynamic
		configuration of per LSP ingress admission control.</t>

	    <t>Lack of ingress admission control coupled with the behavior in
	    <xref target="RFC3209"/> may result in LSPs operating
		out of profile for significant periods of time.  It is reasonable to
		expect that these out-of-profile LSPs will be operating in a degraded
		state and experience traffic loss, but because they 
		end up sharing common network interfaces with other LSPs operating within
		their bandwidth reservations, thus impacting the operation
		of the in-profile LSPs, even when there is unused network capacity elsewhere
		in the network.  Furthermore, this behavior will cause information loss 
		in the TED with regards to the actual available bandwidth on the links 
		used by the out-of-profile LSPs, as the reservations on the links no longer
		reflect the capacity used.
		</t>

	    <t>Reference Topology 1 in <xref target="Reference-topology-1"/> and
	    Tables <xref target="Deadlock-link-parameters" format="counter"/>
	    and <xref target="Deadlock-demand" format="counter"/> show a use
	    case that demonstrates this behavior. Two LSPs, LSP 1 and LSP 2 are
	    signaled with demand 2 and routed along paths A-C-D-E and B-C-D-E
	    respectively. At a later time, the demand of LSP 1 increases to
	    20. Under such a demand, the LSP cannot be resignaled. However, the
	    existing LSP will not be torn down. In the absence of ingress
	    policing, traffic on LSP 1 will cause degradation for traffic of LSP
	    2 (due to oversubscription on the links C-D and D-E), as well as
	    information loss in the TED with regard to the actual network
	    state.</t>

	    <t>The problem could be easily ameliorated by global visibility of
	    LSP state coupled with PCC-external demand measurements and
	    placement of two LSPs on disjoint links. Note that while the demand
	    of 20 for LSP 1 could never be satisfied in the given topology, what
	    could be achieved would be isolation from the ill-effects of the
	    (unsatisfiable) increased demand.</t>
		
	    <texttable anchor="Deadlock-link-parameters" 
		       title="Link parameters for the 'Degraded operation' example">
	      <ttcol align="center">Link</ttcol>
	      <ttcol align="center">Metric</ttcol>
	      <ttcol align="center">Capacity</ttcol>
	      <c>A-C</c><c>1</c><c>10</c>
	      <c>B-C</c><c>1</c><c>10</c>
	      <c>C-E</c><c>10</c><c>5</c>
	      <c>C-D</c><c>1</c><c>10</c>
	      <c>D-E</c><c>1</c><c>10</c>
	    </texttable>

	    <texttable anchor="Deadlock-demand" 
		       title="Degraded operation demand time series">
	      <ttcol align="center">Time</ttcol>
	      <ttcol align="center">LSP</ttcol>
	      <ttcol align="center">Src</ttcol>
	      <ttcol align="center">Dst</ttcol>
	      <ttcol align="center">Demand</ttcol>
	      <ttcol align="center">Routable</ttcol>
	      <ttcol align="center">Path</ttcol>
	      <c>1</c><c>1</c><c>A</c><c>E</c><c>2</c><c>Yes</c><c>A-C-D-E</c>
	      <c>2</c><c>2</c><c>B</c><c>E</c><c>2</c><c>Yes</c><c>B-C-D-E</c>
	      <c>3</c><c>1</c><c>A</c><c>E</c><c>20</c><c>No</c><c>---</c>
	    </texttable>
	  </section> <!-- Deadlock -->

	  <section anchor="Minimum-Perturbation" title="Minimum Perturbation">
	    <t>As a result of both the lack of visibility into global LSP state
	    and the lack of control over event ordering across PCE sessions,
	    unnecessary perturbations may be introduced into the network by a
	    stateless PCE.  Tables <xref target="Minimum-Perturbation-link-parms"
	    format="counter"/> and <xref target="Minimum-Perturbation-LSPs"
	    format="counter"/> show an example of an unnecessary network
	    perturbation using Reference Topology 1 in <xref
	    target="Reference-topology-1"/>.  In this case an unimportant (high
	    LSP priority value) LSP (LSP1) is first set up along the shortest
	    path.  At time 2, which is assumed to be relatively close to time 1,
	    a second more important (lower LSP-priority value) LSP (LSP2) is
	    established, preempting LSP1, potentially causing traffic loss.  
		LSP1 is then reestablished on the longer A-C-E path.</t>

	    <texttable anchor="Minimum-Perturbation-link-parms" 
		       title="Link parameters for the 'Minimum-Perturbation' example">
	      <ttcol align="center">Link</ttcol>
	      <ttcol align="center">Metric</ttcol>
	      <ttcol align="center">Capacity</ttcol>
	      <c>A-C</c><c>1</c><c>10</c>
	      <c>B-C</c><c>1</c><c>10</c>
	      <c>C-E</c><c>10</c><c>10</c>
	      <c>C-D</c><c>1</c><c>10</c>
	      <c>D-E</c><c>1</c><c>10</c>
	    </texttable>

	    <texttable anchor="Minimum-Perturbation-LSPs" 
		       title="Minimum-Perturbation LSP and demand time series">
	      <ttcol align="center">Time</ttcol>
	      <ttcol align="center">LSP</ttcol>
	      <ttcol align="center">Src</ttcol>
	      <ttcol align="center">Dst</ttcol>
	      <ttcol align="center">Demand</ttcol>
	      <ttcol align="center">LSP Prio</ttcol>
	      <ttcol align="center">Routable</ttcol>
	      <ttcol align="center">Path</ttcol>
	      <c>1</c><c>1</c><c>A</c><c>E</c><c>7</c><c>7</c><c>Yes</c><c>A-C-D-E</c>
	      <c>2</c><c>2</c><c>B</c><c>E</c><c>7</c><c>0</c><c>Yes</c><c>B-C-D-E</c>
	      <c>3</c><c>1</c><c>A</c><c>E</c><c>7</c><c>7</c><c>Yes</c><c>A-C-E</c>
	    </texttable>
		
		<t> A stateful PCE can help in this scenario by computing both routes at the same
		time.  The advantages of  using a stateful PCE over exploiting a stateless PCE via 
		Global Concurrent Optimization(GCO) are three folds.
        First is the ability to accommodate concurrent path computation from different PCCs. 
		Second is the reduction of control plane overhead since the stateful PCE has the route 
		information of the affected LSPs. Thirdly, the stateful PCE can use the LSP-DB to 
		further optimize the placement of LSPs.	This will ensure placement of the more important 
		LSP along the shortest path, avoiding the setup and subsequent preemption of the lower 
		priority LSP.  Similarly, when a new higher priority
		LSP which requires preemption of existing lower priority LSP(s), 
		a stateful PCE can determine the minimum number of 
		lower priority LSP(s) to reroute using the make-before-break (MBB)
		mechanism without disrupting any service and then set up the higher 
		priority LSP.</t> 	
	  </section><!-- Minimum-perturbation -->

	  <section anchor="Predictability" title="Predictability">
	    <t>Randomization of reservation events caused by lack of control
	    over event ordering across PCE sessions results in poor
	    predictability in LSP routing.  An offline system applying a
	    consistent optimization method will produce predictable results to
	    within either the boundary of forecast error (when reservations are
	    over-provisioned by reasonable margins) or to the variability of the
	    signal and the forecast error (when applying some hysteresis in order
	    to minimize churn).  Predictable results are valuable for being able to
		simulate the network and reliably test it under various scenarios, especially under various
        failure modes and planned maintenances when predictable path characteristics are desired
        under contention for network resources.</t>

	    <t>Reference Topology 1 and Tables <xref
	    target="Predictability-link-parameters" format="counter"/>, <xref
	    target="Predictability-LSPs-1" format="counter"/> and <xref
	    target="Predictability-LSPs-2" format="counter"/> show the impact of
	    event ordering and predictability of LSP routing.</t>

	    <texttable anchor="Predictability-link-parameters" 
		       title="Link parameters for the 'Predictability' example">
	      <ttcol align="center">Link</ttcol>
	      <ttcol align="center">Metric</ttcol>
	      <ttcol align="center">Capacity</ttcol>
	      <c>A-C</c><c>1</c><c>10</c>
	      <c>B-C</c><c>1</c><c>10</c>
	      <c>C-E</c><c>1</c><c>10</c>
	      <c>C-D</c><c>1</c><c>10</c>
	      <c>D-E</c><c>1</c><c>10</c>
	    </texttable>

	    <texttable anchor="Predictability-LSPs-1" 
		       title="Predictability LSP and demand time series 1">
	      <ttcol align="center">Time</ttcol>
	      <ttcol align="center">LSP</ttcol>
	      <ttcol align="center">Src</ttcol>
	      <ttcol align="center">Dst</ttcol>
	      <ttcol align="center">Demand</ttcol>
	      <ttcol align="center">Routable</ttcol>
	      <ttcol align="center">Path</ttcol>
	      <c>1</c><c>1</c><c>A</c><c>E</c><c>7</c><c>Yes</c><c>A-C-E</c>
	      <c>2</c><c>2</c><c>B</c><c>E</c><c>7</c><c>Yes</c><c>B-C-D-E</c>
	    </texttable>

	    <texttable anchor="Predictability-LSPs-2" 
		       title="Predictability LSP and demand time series 2">
	      <ttcol align="center">Time</ttcol>
	      <ttcol align="center">LSP</ttcol>
	      <ttcol align="center">Src</ttcol>
	      <ttcol align="center">Dst</ttcol>
	      <ttcol align="center">Demand</ttcol>
	      <ttcol align="center">Routable</ttcol>
	      <ttcol align="center">Path</ttcol>
	      <c>1</c><c>2</c><c>B</c><c>E</c><c>7</c><c>Yes</c><c>B-C-E</c>
	      <c>2</c><c>1</c><c>A</c><c>E</c><c>7</c><c>Yes</c><c>A-C-D-E</c>
	    </texttable>
	  <t> As can be shown in the example, both LSPs are routed in both cases, 
	  but along very different paths. This would be a challenge if reliable simulation
	  of the network is attempted. A stateful PCE can solve this through control over 
	  LSP ordering.</t> 	  
	  </section> <!-- Predictability --> 
	  </section> <!-- Global-visibility Optimization of LSP placement --> 
	  
	   
	 <section anchor="bw-adjustment" title="Auto-bandwidth Adjustment">
		<t>
		The bandwidth requirement of LSPs often change over time, requiring resizing the LSP. In most 
		implementations available today, the head-end node performs this function by monitoring 
		the actual bandwidth usage, triggering
		a recomputation and resignaling when a threshold is reached.  This operation is referred as
		auto-bandwidth adjustment.  The head-end node either recomputes the path locally, or it requests a 
		recomputation from a PCE by sending a PCReq message.  In the latter case, 
		the PCE computes a new path and provides the new route suggestion.  Upon receiving the reply from 
		the PCE, the PCC re-signals the LSP in Shared-Explicit (SE) mode along the newly computed path.
		With a stateless PCE, the head-end node needs to provide the current used bandwidth and the route information via path computation request messages.
		Note that in this scenario, the head-end node is the one that drives the LSP resizing based 
		on local information, and that the difference between using a stateless and a passive 
		stateful PCE is in the level of optimization of the LSP placement as discussed in the previous 
		section. </t> 
		
		<t> A more interesting smart bandwidth adjustment case is one where the LSP resizing decision
		is done by an external entity, with access to additional information such as historical trending 
		data, application-specific information about expected demands or policy information, as well
		as knowledge of the actual desired flow volumes.  In this case an active stateful PCE provides
		an advantage in both the computation with knowledge of all LSPs in the domain and in the ability 
		to trigger bandwidth modification of the LSP. 
		</t>		
	 </section>
	 
	 <section anchor="BW-cal" title="Bandwidth Scheduling">
		
		
		<t> Bandwidth scheduling allows network operators to reserve resources in advance 
		according to the agreements with their customers, and allow them to transmit data with 
		specified starting time and duration, for example for a scheduled bulk data replication
		between data centers. </t>
		
		<t> Traditionally, this can be supported by network management system (NMS) operation through path pre-establishment
		and activation on the agreed starting time.  However, this does not provide efficient 
		network usage since the established paths exclude the possibility of being used by other 
		services even when they are not used for undertaking any service.  It can also be accomplished 
		through GMPLS protocol extensions by carrying the related request information (e.g., 
		starting time and duration) across the network.  Nevertheless, this method inevitably 
		increases the complexity of signaling and routing process. </t>
			
		<t> A passive stateful PCE can support this application with better efficiency since it can 
		alleviate the burden of processing on network elements. This requires the PCE to maintain 
		the scheduled LSPs and their associated resource usage, as well as the ability of head-ends 
		to trigger signaling for LSP setup/deletion at the correct time. This approach requires coarse time 
		synchronization between PCEs and PCCs. If an active stateful PCE is available, the PCE can
		trigger the setup/deletion of scheduled requests in a centralized manner, as specified
		<xref target='I-D.ietf-pce-pce-initiated-lsp'></xref>, 
		without modification of existing head-end behaviors, by notifying the PCCs to 
		set up or tear down the paths.</t> 
	 </section>
 	
	<section anchor="recovery" title="Recovery">
	
		
		<t> The recovery use cases discussed in the following sections show how leveraging a stateful PCE 
		 can simplify the computation of recovery path(s).  In particular, two characteristics 
		of a stateful PCE are used: 1) using information stored in the LSP-DB for determining 
		shared protection resources	and 2) performing computations with	knowledge 
		of all LSPs in a domain. 
		</t>
	
		<section anchor="protection" title="Protection">
		<t>
		If a PCC can specify in a request whether the computation is for a working path or for protection, 
		and a PCC can report the resource as a working or protection path, then the following text applies. 
		A PCC can send multiple requests to the PCE, asking for two LSPs and use them as working 
		and backup paths separately. Either way, the resources bound to backup paths can be shared by 
		different LSPs to improve the overall network efficiency, such as m:n protection or 
		pre-configured shared mesh recovery techniques as specified in <xref target="RFC4427"/>.  
		If resource sharing is supported for LSP protection, the information relating to existing LSPs
		is required to avoid allocation of shared protection resources to two LSPs that might fail 
		together and cause protection contention issues.  A stateless PCE can accommodate this use case by 
		having the PCC pass this information as a constraint in the path computation request.  
		A passive stateful PCE can more easily accommodate this need using the information stored in its LSP-DB. 
		Furthermore, an active stateful PCE can help with (re)-optimizization of protection 
		resource sharing as well as LSP maintenance operation with fewer impact on protection resources.
		</t>
		
		<figure anchor="Reference-topology-3" title="Reference topology 3">
	  <artwork><![CDATA[
              +----+  
              |PCE |  
              +----+  
              
         +------+          +------+          +------+
         |  A   +----------+  B   +----------+  C   |
         +--+---+          +---+--+          +---+--+
            |                  |                 |
            |        +---------+                 |
            |        |                           |
            |     +--+---+          +------+     |
            +-----+  E   +----------+  D   +-----+
                  +------+          +------+

   	    ]]></artwork>
	  </figure>
	  
	  <t> 
	  For example, in the network depicted in Figure <xref target="Reference-topology-3" format="counter"/>, 
	  suppose there exists LSP1 with working path LSP1_working following A->E and with backup path 
	  LSP1_backup following A->B->E. A request arrives asking for a working and backup path pair to be 
	  computed for LSP2 from B to E. If the PCE decides LSP2_working follows B->A->E, 
	  then the backup path LSP2_backup should not share the same protection resource with LSP1 
	  since LSP2 shares part of its resource (specifically A->E) with LSP1 (i.e., these two LSPs are in 
	  the same shared risk group).  There is no such constraint if B->C->D->E is
	  chosen for LSP2_working.
	  </t> 
	  
	 <t> If a stateless PCE is used, the head node B needs to be aware of the existence 
	 of LSPs which share the route of LSP2_working and of the details of their 
	 protection resources. B must pass this information to the PCE as a constraint 
	 so as to request a path with diversity.  Alternatively, a stateless PCE may able to 
	 compute Shared Risk Link Group (SRLG)-diversified paths if TED is extended so that it includes the SRLG information
	 that are protected by a given backup resource, but at the expense of a high complexity in routing.
	 On the other hand, a stateful PCE can get the LSPs information by itself given that the LSP
     identifier(s) and can achieve the goal 
	 of finding SRLG-diversified protection paths for both LSPs.  This is made possible by comparing 
	 the LSP resource usage exploiting the LSP-DB accessible by the stateful PCE. </t>
		</section>
		
		
		<section anchor="restoration" title="Restoration">
			
		<t>
		In case of a link failure, such as a fiber cut, multiple LSPs may fail at the same time. Thus, 
		the source nodes of the affected LSPs will be informed of the failure by the nodes detecting the 
		failure.  These source nodes will send requests to a PCE for rerouting.  In order to reuse the 
		resource taken by an existing LSP, the source node can send a PCReq message including the 
		Exclude Route Object (XRO) with Fail (F) bit set, together with the record route object (RRO) containing the 
		current route information, as specified in <xref target="RFC5521"/>.
		</t>
		
		<t>
		If a stateless PCE is used, it might respond to the rerouting requests separately if they 
		arrive at different times.  Thus, it might result in sub-optimal resource usage.  Even worse, 
		it might unnecessarily block some of the rerouting requests due to insufficient resources for 
		later-arrived rerouting messages.  If a passive stateful PCE is used to fulfill this task, the 
		procedure can be simplified. The PCCs reporting the failures can include LSP identifiers instead 
		of detailed information and the PCE can find relevant LSP information by inspecting the LSP-DB. 
		Moreover, the PCE can 
		re-compute the affected LSPs concurrently while reusing part of the existing LSPs resources 
		when it is informed of the failed link identifier provided by the first request.  This is made 
		possible since the passive stateful PCE can check what other LSPs are affected by the failed link and 
		their route information by inspecting its LSP-DB.  As a result, a better performance can be
		achieved, such as better resource usage or minimal probability of blocking upcoming new rerouting 
		requests sent as a result of the link failure. 
		</t>
			
		<t>
		If the target is to avoid resource contention within the time-window of high number of LSP rerouting
		requests, a stateful PCE can retain the under-construction LSP resource usage information for 
		a given time and exclude it from being used for forthcoming LSPs request.  In this way, 
		it can ensure that the resource will not be double-booked and thus the issue of resource 
		contention and computation crank-backs can be alleviated. 
		</t>
		</section>	
		
		<section anchor="srlg-diversity" title="SRLG Diversity">
		<t>
		An alternative way to achieve efficient resilience is to maintain SRLG disjointness between LSPs, 
		irrespective of whether these LSPs share the source and destination nodes or not.  This can be achieved
		at provisioning time, if the routes of all the LSPs are requested together, 
		using a synchronized computation of the different LSPs with SRLG disjointness constraint.  If the LSPs 
		need to be provisioned at different times, the PCC can specify, as constraints to the path computation a set 
		of SRLGs using the Exclude Route Object <xref target="RFC5521"/>.  
		However, for the latter to be effective, it is needed that the entity 
		that requests the route to the PCE maintains updated SRLG information of all the LSPs to which 
		it must maintain the disjointness.  A stateless PCE can compute an SRLG-disjoint path by inspecting
		the TED and precluding the links with the same SRLG values specified in the PCReq message sent by a PCC. 
		</t>
		<t>
		A passive stateful PCE maintains the updated SRLG information of the established LSPs
		in a centralized manner.  Therefore, the PCC can specify as constraints to the path 
		computation the SRLG disjointness of a set of already established LSPs by only providing the LSP
		identifiers.  Similarly, a passive stateful PCE can also accommodate disjointness using 
		other constraints, such as link, node or path segment etc.
		</t>
	
		
		</section>
	</section>
				
	
	<section anchor="VNT" title="Maintenance of Virtual Network Topology (VNT)">
	
	
	<t> 
	In Multi-Layer Networks (MLN), a Virtual Network Topology (VNT) 
	<xref target="RFC5212"/> consists of a set of one or more TE LSPs in the lower 
	layer which provides TE links to the upper layer. In 
	<xref target="RFC5623"/>, the PCE-based architecture is proposed to
	support path computation in MLN networks in order to achieve inter-layer TE. 
	</t>
	
	<t>
	The establishment/teardown of a TE link in VNT needs to take into
   consideration the state of existing LSPs and/or new LSP request(s) in
   the higher layer.  Hence, when a stateless PCE cannot find the
   route for a request based on the upper layer topology information, it
   does not have enough information to decide whether to set up or 
   remove a TE link or not, which then can result in non-optimal usage of 
   resource.  On the other hand, a passive stateful PCE can make a better
   decision of when and how to modify the VNT either to accommodate new LSP 
   requests or to re-optimize resource usage across layers irrespective 
   of the PCE models as described in <xref target="RFC5623"/>.  Furthermore, 
   given the active capability, the stateful PCE can issue VNT 
   modification suggestions in order to accommodate path setup requests
   or re-optimize resource usage across layers.
	</t> 
	</section>
	
	<section anchor="Reoptimization" title="LSP Re-optimization">
	
	 <t>
          In order to make efficient usage of network resources,
          it is sometimes desirable to re-optimize one or more 
		  LSPs dynamically.  
		  In the case of a stateless PCE, in order to optimize network
          resource usage dynamically through online planning, a PCC
          must send a request to the PCE together with
          detailed path/bandwidth information of the LSPs that need to
          be concurrently optimized.  This means the PCC must be able 
		  to determine when and which LSPs should be
          optimized.  
		  In the case of a passive stateful PCE, given the LSP state information in the LSP
		  database, the process of dynamic optimization of network resources
          can be simplified without requiring the PCC to supply detailed LSP state
          information.  Moreover, an active stateful PCE can even make the process
          automated by triggering the request since a stateful
          PCE can maintain information for all LSPs that are in the process of
          being set up and it may have the ability to control timing and
          sequence of LSP setup/deletion, the optimization procedures can be
          performed more intelligently and effectively.   A stateful PCE can also determine which LSP
		  should be re-optimized based on network events.  For example, when
		  a LSP is torn down, its resources are freed.  This can trigger 
		  the stateful PCE to automatically determine which LSP should
		  be reoptimized so that the recently freed resources may be allocated to it.
        </t>
		  
        <t>
          A special case of LSP re-optimization is GCO <xref target="RFC5557" />.  
          Global control of LSP operation sequence in <xref
          target="RFC5557" /> is predicated on the use of what is
          effectively a stateful (or semi-stateful) NMS.  The NMS can
          be either not local to the network nodes, in which case another
          northbound interface is required for LSP attribute changes,
          or local/collocated, in which case there are significant
          issues with efficiency in resource usage. 

          A stateful PCE adds a few features that:
          <list style="symbols">
            <t>  Roll the NMS visibility into the PCE and remove the 
			requirement for an additional northbound interface</t>
            <t> Allow the PCE to determine when re-optimization is 
			needed, with which level (GCO or a more incremental optimization) </t>
	        <t>Allow the PCE to determine which LSPs should be re-optimized</t>
            <t> Allow a PCE to control the sequence of events across multiple  
			PCCs, allowing for bulk (and truly global) optimization, LSP shuffling etc.</t>
          </list>
        </t>
	</section> 
	
	<section anchor="flex-grid" title="Resource Defragmentation">
		<t>
		If LSPs are dynamically allocated and released over time, 
		the resource becomes fragmented. In networks with link bundle, the overall available resource on 
		a (bundle) link might 
		be sufficient for a new LSP request, but if the available resource is not continuous, 
		the request is rejected.  In order to perform the defragmentation procedure, 
		stateful PCEs can be used, since global visibility of LSPs in the network is required to accurately 
		assess resources on the LSPs, and perform de-fragmentation while ensuring a minimal 
		disruption of the network.  This use case cannot be accommodated
		by a stateless PCE since it does not possess the detailed information of existing LSPs in the network. 
		</t>
		
		<t>
		Another case of particular interest is the optical spectrum defragmentation in flexible grid networks.
		In Flexible grid networks <xref target="RFC7698"/>, LSPs with different 
		optical spectrum sizes (such as 12.5GHz, 25GHz etc.) can co-exist so as to accommodate the 
		services with different bandwidth requests.  Therefore, even if the overall spectrum size can 
		meet the service request, it may not be usable if the available spectrum resource is not contiguous, 
		but rather fragmented into smaller pieces.  Thus, with the help of existing LSP state information, 
		a stateful PCE can make the resource grouped 
		together to be usable.  Moreover, a stateful PCE can proactively choose routes for upcoming 
		path requests to reduce the chance of spectrum fragmentation.
		</t>
	</section> <!--resource fragmentation -->
		
		<section anchor="P2MP" title="Point-to-Multi-Point Applications">
		<t> PCE has been identified as an appropriate technology for the determination of the paths
		of point-to-multipoint (P2MP) TE LSPs <xref target="RFC5671"/>. The application scenarios and 
		use-cases described in <xref target="Global-visibility"/>, 
		<xref target="recovery"/> and <xref target="Reoptimization"/>
		are also applicable to P2MP TE LSPs.</t>		
		<t> In addition to these, the stateful nature of a PCE simplifies the information conveyed in
		PCEP messages since it is possible to refer to the LSPs via an identifier. For P2MP, this is an
		added advantage, where the size of the PCEP message is much larger.  In case of stateless PCEs,
		modification of a P2MP tree requires encoding of all leaves along with the paths in PCReq message.
		But using a stateful PCE with P2MP capability, the PCEP message can be used to convey only the 
        modifications (the other information can be retrieved from the identifier via the LSP-DB).</t>		
	</section> <!--P2MP -->
	
	<section anchor="Impairment" title="Impairment-Aware Routing and Wavelength Assignment (IA-RWA)">
		<t>In Wavelength Switched Optical Networks (WSONs) <xref target="RFC6163"/>, a wavelength-switched 
		LSP traverses one or more fiber links. 
		The bit rates of the client signals carried by the wavelength LSPs may be the same or different.
		Hence, a fiber link may transmit a number of wavelength LSPs with equal or mixed bit rate signals.
		For example, a fiber link may multiplex the wavelengths with only 10Gb/s signals, mixed 10Gb/s and 
		40Gb/s signals, or mixed 40Gb/s and 100Gb/s signals. </t>
		
		<t> IA-RWA in WSONs refers to the process (i.e., lightpath computation) that takes 
		into account the optical layer/transmission imperfections by considering as additional 
		(i.e., physical layer) constraints.  To be more specific, linear and non-linear effects 
		associated with the optical network elements should be incorporated into the route and 
		wavelength assignment procedure.  For example, the physical imperfection can result in 
		the interference of two adjacent lightpaths.  Thus, a guard band should be reserved between 
		them to alleviate these effects.  The width of the guard band between two adjacent wavelengths 
		depends on their characteristics, such as modulation formats and bit rates.  Two adjacent 
		wavelengths with different characteristics (e.g., different bit rates) may need a wider guard 
		band and with same characteristics may need a narrower guard band.  For example, 
		50GHz spacing may be acceptable for two adjacent wavelengths with 40G signals. But for 
		two adjacent wavelengths with different bit rates (e.g., 10G and 40G), a larger spacing 
		such as 300GHz spacing may be needed.  Hence, the characteristics (states) of the existing 
		wavelength LSPs should be considered for a new RWA request in WSON. </t>
		
		<t> In summary, when stateful PCEs are used to perform the IA-RWA procedure, they need to 
		know the characteristics of the existing wavelength LSPs.  The impairment information relating 
		to existing and to-be-established LSPs can be obtained by nodes in WSON networks via external 
		configuration or other means such as monitoring or estimation based on a vendor-specific 
		impair model.  However, WSON related routing protocols, i.e.,  <xref target="RFC7688" />
		and  <xref target="RFC7580" />, 
		only advertise limited information (i.e., availability) of the existing wavelengths, 
		without defining the supported client bit rates.  It will incur substantial amount of control 
		plane overhead if routing protocols are extended to support dissemination of the new 
		information relevant for the IA-RWA process.  In this scenario, stateful PCE(s) would be a more 
		appropriate mechanism to solve this problem.  Stateful PCE(s) can exploit impairment 
		information of LSPs stored in LSP-DB to provide accurate RWA calculation. </t>
	</section> <!--IA-WSON -->
  </section>

  <section anchor="Security" title="Security Considerations">
    <t>The PCEP extensions in support of stateful PCE and the delegation of path control, 
	result in more information being available for a hypothetical adversary and a number 
	of additional attack surfaces which must be protected.
	<xref target="I-D.ietf-pce-stateful-pce"/> discusses different attack vectors and 
	defines protocol mechanisms to protect against them. It also lays out implementation 
	requirements for configuration capabilities that allow the operator to control the 
	PCC behavior when faced with an attack. This document does not introduce any 
	new security considerations beyond those discussed in 
	<xref target="I-D.ietf-pce-stateful-pce"/>.</t>
   </section> <!--Security -->

   <section anchor="IANA" title="IANA Considerations">
      <t>This document does not require any IANA action. </t>
   </section> <!--IANA-->

   <section anchor="Contributing-authors" title="Contributing Authors">
    <t>
	The following people all contributed significantly to this document and are listed below in 
	alphabetical order:
    </t>
    <t>
   Ramon Casellas<vspace blankLines='0'/>
   CTTC - Centre Tecnologic de Telecomunicacions de Catalunya<vspace blankLines='0'/>
   Av. Carl Friedrich Gauss n7<vspace blankLines='0'/>
   Castelldefels, Barcelona 08860<vspace blankLines='0'/>
   Spain<vspace blankLines='0'/>
   Email: ramon.casellas@cttc.es<vspace blankLines='0'/>
    </t>
    <t>
   Edward Crabbe<vspace blankLines='0'/>
   Email: edward.crabbe@gmail.com<vspace blankLines='0'/>
    </t>
    <t>
   Dhruv Dhody<vspace blankLines='0'/>
   Huawei Technology<vspace blankLines='0'/>
   Leela Palace<vspace blankLines='0'/>
   Bangalore, Karnataka 560008<vspace blankLines='0'/>
   INDIA<vspace blankLines='0'/>
   EMail: dhruv.dhody@huawei.com<vspace blankLines='0'/>
    </t>
    <t>
   Oscar Gonzalez de Dios<vspace blankLines='0'/>
   Telefonica Investigacion y Desarrollo<vspace blankLines='0'/>
   Emilio Vargas 6<vspace blankLines='0'/>
   Madrid,   28045<vspace blankLines='0'/>
   Spain<vspace blankLines='0'/>
   Phone: +34 913374013<vspace blankLines='0'/>
   Email: ogondio@tid.es<vspace blankLines='0'/>
    </t>
    <t>
   Young Lee<vspace blankLines='0'/>
   Huawei<vspace blankLines='0'/>
   1700 Alma Drive, Suite 100<vspace blankLines='0'/>
   Plano, TX  75075<vspace blankLines='0'/>
   US<vspace blankLines='0'/>
   Phone: +1 972 509 5599 x2240<vspace blankLines='0'/>
   Fax:   +1 469 229 5397<vspace blankLines='0'/>
   EMail: leeyoung@huawei.com<vspace blankLines='0'/>
    </t>
    <t>
   Jan Medved<vspace blankLines='0'/>
   Cisco Systems, Inc.<vspace blankLines='0'/>
   170 West Tasman Dr.<vspace blankLines='0'/>
   San Jose, CA  95134<vspace blankLines='0'/>
   US<vspace blankLines='0'/>
   Email: jmedved@cisco.com<vspace blankLines='0'/>
    </t>
    <t>
   Robert Varga<vspace blankLines='0'/>
   Pantheon Technologies LLC<vspace blankLines='0'/>
   Mlynske Nivy 56<vspace blankLines='0'/>
   Bratislava  821 05<vspace blankLines='0'/>
   Slovakia<vspace blankLines='0'/>
   Email: robert.varga@pantheon.sk<vspace blankLines='0'/>     
    </t>
    <t>
   Fatai Zhang<vspace blankLines='0'/>
   Huawei Technologies<vspace blankLines='0'/>
   F3-5-B R&amp;D Center, Huawei Base<vspace blankLines='0'/>
   Bantian, Longgang District<vspace blankLines='0'/>
   Shenzhen 518129 P.R.China<vspace blankLines='0'/>
   Phone: +86-755-28972912<vspace blankLines='0'/>
   Email: zhangfatai@huawei.com<vspace blankLines='0'/>
    </t>
    <t>
   Xiaobing Zi<vspace blankLines='0'/>
   Email: unknown<vspace blankLines='0'/>
    </t>
</section>
   <section anchor="Acknowledgements" title="Acknowledgements">
     <t>
	 We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur and Ravi Torvi for the useful comments and discussions.
	 </t>
    </section>
	</middle>

  <back>
    <references title="Normative References">
	  <?rfc include="reference.I-D.ietf-pce-stateful-pce"?>
	  <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7399.xml"?>
	  <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml"?>
   </references>
  

   <references title="Informative References">
     <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml"?>
     <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4427.xml"?>
     <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4657.xml"?>
     <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5212.xml"?>
     <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5521.xml"?>
     <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5557.xml"?>
	 <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5623.xml"?>
	 <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6163.xml"?>
	 <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5671.xml"?>
	 <?rfc include="reference.I-D.ietf-pce-gmpls-pcep-extensions"?>
	 <?rfc include="reference.I-D.ietf-pce-stateful-sync-optimizations"?>
	 <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7698.xml"?> 
	 <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7688.xml"?> 
	 <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7580.xml"?>
	 <?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp"?> 
     
	  </references>
  	
  </back>
  
  
</rfc>
