Igor, On Nov 9, 2012, at 6:28 AM, Igor Bryskin wrote:
> 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. No it is not. Please see my emails to Oscar and Faital. > The cleanest way to think about the latter IMO is a combination of stateless > PCE and a network controller, draft-ietf-pce-stateful-pce does not change the architecture outlined in RFC4655. It proposes an extension to the PCEP protocol that allows the PCE to do both spatial *and* temporal LSP optimization. The need to add the timing aspect (i.e. the timing of LSP setups) to LSP optimization is amply documented in use cases presented in the draft (and use cases presented in other drafts as well). draft-ietf-pce-stateful-pce does not change the control of the LSPs - it still remains with the PCC. A network controller would have to be able to dynamically add/delete LSPs in order to fit in the model that you described above. draft-crabbe-pce-pce-initiated-lsp-00 goes there, but draft-ietf-pce-stateful-pce does not. > 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 > Thanks, Jan > -----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 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
