Igor et al Can we please separate the discussions, as Oscar made multiple unrelated arguments in the original post? I'm renaming this thread.
On Fri, Nov 9, 2012 at 9:28 AM, Igor Bryskin <ibrys...@advaoptical.com>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. 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 >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
