Cyril, Thank you for the review and discussion, please see inline ###.
On Tue, Nov 3, 2015 at 1:09 AM, Cyril Margaria <[email protected]> wrote: > Hi, > > My comments on the document are: > > > 1) The format goes in the good,direction, but is not yet fully aligned > with rfc6780, is this planned for a future revision? > ### Yes, as we discussed with Loa at the IETF, we are changing the format, a new version of the document will be published next week. > 2) My concern is the following statements: > > "For both > cases, the association is uniquely identified by the combination of > an association identifier and the address of the PCE peer that > created the association." > > "Association Source: 4 or 16 bytes - An IPv4 or IPv6 address, which is > associated to the PCE peer that originated the association." > > Those statement are not aligned with the RSVP association is managed. > The reason stated is that the association state is tied to that PCE. > > Is this related to the fact that about any PCC/PCE can create association on > a LSP? > > ### Same as above > 3) Association control : the PCC and any PCE can create associations: > this diverge from the existing mechanism from the statefull document. > In my opinion this aspect makes the control and state maintenance more > complicated. The use cases behind this multiple-controller model is not > very clear. > > If the association is under the control a single entity (PCC or PCE), as > in the stateful document, the association state then become part of the PCE > state and the rules described in the stateful document applies (it up to > the PCE who as delegation to set the association. > > This would also allow to get rid of the R bit, as mentioned by adrian (to > remove an association: simply not send it) > ### I disagree, the ability to have either create an association and allocate an identifier was a key requirement (you may recall that version 00 only allowed the PCE to create such associations, and we received a lot of feedback asking to lift this limitation). > > Which use cases will not be permitted by that mode of operation? > > > >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
