I completely agree with Oscar. The statefull PCE as defined in RFC 4655 is clearly different from statefull PCE as defined in Ed's documents. The cleanest way to think about the latter IMO is a combination of stateless PCE and a network controller, which is a very reasonable combination, but is hardly something to be discussed in PCE working group unless it does not go beyond purely path computation issues.
Igor -----Original Message----- From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Oscar González de Dios Sent: Thursday, November 08, 2012 5:28 PM To: Julien Meuric Cc: pce@ietf.org Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Hi Julien Thanks for the reply. As you said, there where several parts of the message. I will now limit to cover the discussion of the scope of LSP delegation and LSP incitation procedures in the charter. For the rest, I will reply in separate mails, in private if you want, in sake of advancing the discussions, and my apologies if my words have been misunderstood or sounded harsh. Comments inline "Then, concerning our current scope, you certainly should have a fresh look at RFC 4655. E.g., section 6.12: "It may be that the PCC-PCE communications (see Section 6.6) can be usefully extended beyond a simple request/response interaction.[...] Additionally, the protocol could be used to collect and report information in support of a stateful PCE." We are not machines, but as chairs, we consider that the original draft-crabbe-pce-stateful-pce, which was adopted by the WG, was consistent with this statement (which, since included in an RFC, passed IESG review)." [Oscar]: The state synchronization functions, aimed at (citing literally) provide a checkpoint-in-time state replica of a PCC's LSP state in a PCE are consistent with this statement, they are beyond simple request/response interactions and collect and report information in support of a stateful PCE. Thus, this function is perfectly OK with RFC 4555. However, I see that the LSP delegation function goes beyond reporting information to support a stateful PCE. It instructs the PCE to take control of the LSP, and, during the life-time of the LSP, citing literally "the PCC grants to a PCE the right to update LSP attributes on one or more LSPs; the PCE becomes the authoritative source of the LSP's attributes as long as the delegation is in effect". Thus, delegation function clearly is not used to provide information to support later path computation. So... unless I have mistaken the read of RFC 4655, it is explicitly mentioned that the PCE architecture is aimed at solving the problem of path computation. I may have jumped over some paragraph where it says that the role of a Path Computation Element (stateful o not stateful) is to take care of the control of an LSP... but I honestly cannot find such statement anywhere. So... could you give me some arguments why the delegation of control is in scope of current RFC 4655? (Of course the scope can be widened in future, so let's try to stick to current RFC 4655) Best Regards, Óscar ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
