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 protected]> 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 > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
