Subject: [Pce] FW: New Version Notification for draft-crabbe-pce-stateful-pce-01.txt

From: Jan Medved <[email-masked]>
Date: Mon, 31 Oct 2011 00:01:40 -0700

Hello,

We submitted a new version of the Stateful PCE draft, where we addressed
comments / suggestions from reviewers on the mailing list - many thanks to
all who reviewed & commented.

We to hope to have a good discussion of the draft in Taipei.

Thanks,
Ed+Jan+Robert

On 10/30/11 11:50 PM, "[email-masked]"
<[email-masked]> wrote:

>A new version of I-D, draft-crabbe-pce-stateful-pce-01.txt has been
>successfully submitted by Jan Medved and posted to the IETF repository.
>
>Filename:	 draft-crabbe-pce-stateful-pce
>Revision:	 01
>Title:		 PCEP Extensions for Stateful PCE
>Creation date:	 2011-10-30
>WG ID:		 Individual Submission
>Number of pages: 41
>
>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
>   synchronization or 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 this functionality,
>   providing stateful control of Multiprotocol Label Switching (MPLS)
>   Traffic Engineering Label Switched Paths (TE LSP) via PCEP.
>
>
>                  
>        
>
>
>The IETF Secretariat

---

From: Ina Minei <[email-masked]>
Date: Mon, 31 Oct 2011 16:27:47 -0700

All, 

Some thoughts around the extensibility of the stateful PCE capability negotiation mechanism defined in this draft. Stateful PCE capability is currently advertised as a single bit in the PCE capability TLV. This works well under two assumptions: 1) all implementations of the draft support setting the attributes currently defined, and 2) no new attributes (or support for vendor-specific attributes) will be added in the future. 

In the event more attributes need to be supported in the future, there needs to be a way to ensure that the PCC and the PCE can agree on what is supported by each end.  One way to accomplish this is by sending error messages when a request comes in for an unsupported attribute, and another is by explicitly advertising the supported attributes and agreeing on a common set (or closing the session if this is unacceptable). 

I believe explicit negotiation gives more flexibility and cleaner implementation.  Here is strawman proposal: 

*	Capabilities are advertised at the time the session is set up, in a  capabilities tlv, with sub-tlvs for every attribute supported.  
*	When receiving the advertisement, each end has to decide if they like what the other end supports, and may choose to close the session and send an error message if it doesn't like the capabilities supported by the other end. 
*	After the advertisements, it is assumed that each end will honor what the other end advertised.  However, if this is not the case, the request is ignored and an error sent.  For example, if capability A, B were advertised, but PCE sets A, B, C, then the entire request is ignored and error sent (this would be the result of a software bug). 

Thank you, 

Ina