Oscar, comments inline.
> In the last PCE meeting, it was mentioned by the WG > chairs that the function of LSP initiation by the PCE (presented in the > draft draft-crabbe-pce-pce-initiated-lsp-00) is out of the scope of current > WG charter. Current IETF stateful PCE draft () supports the function of > delegation, which is an operation to grant a PCE temporary rights to modify > a subset of tunnel parameters on one or more PCC's tunnels. However, > current charter (http://datatracker.ietf.org/wg/pce/charter/) says > nothing about this function, but the draft was (surprisingly) quickly > accepted as WG document. Current charter says “The PCE Working Group is > chartered to specify the required protocols so as to enable a Path > Computation Element (PCE)-based architecture for the computation of paths > for MPLS and GMPLS Point to Point and Point to Multi-point Traffic > Engineered LSPs.” That is “computation”, not control… So, could you > explain why initiation is not in charter and delegation of control is in > charter? > IMO: they're the same thing, the only difference is directionality and asynchrony. > My opinion in the matter of the stateful PCE is that we > should separate the functionality is different functional elements, in the > same way as it was done in the Framework for PCE-Based Inter-Layer MPLS and > GMPLS Traffic Engineering (RFC 5623) between a VNTM and the PCE. In such > RFC, the roles of each functional element are clearly distinguished. Let be > the stateful PCE a Path Computation element using the traffic engineering > database and the LSP database, and then, define another functional element > (call it LSP controller, call it manager) that is in care of the control > issues. > This argument is orthogonal to the previous paragraph regarding the charter; let's separate the two discussions. ;) w/r/t *element* separation: I think that's a poor idea, sorry. It makes total sense to me that a given PCE would be able to negotiate and support stateful or stateless functionality. > Said that, I must say that I like the new functionalities > proposed , and I think they solve problems (and people also did like them, > as the stateful draft was supported by the WG people). What I do not like > at all is how it is being handled. There has been a solution quickly > adopted without taking any care in the architectural/functional > implications. In my opinion we should handle them now. > Define quickly man? The original draft went through multiple rounds of review both on list and in multiple (technically two but really three) IETF meetings before acceptance. It has received, as you said, broad support and review by many people on the list, including you. ;) It is at a relatively low rev count and is still a work in progress. best, -ed
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
