Subject: Re: [Pce] Comments on the capability negotiation in draft-crabbe-pce-stateful-pce-01.txt

From: Jan Medved <[email-masked]>
Date: Fri, 4 Nov 2011 17:58:47 -0700

Hi Ina,

Thanks for the suggestion, good point. We will incorporate it in the next
revision of the document.

/Jan

On 10/31/11 4:27 PM, "Ina Minei" <[email-masked]> wrote:

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