Subject: [Pce] Control vs Computation

From: Edward Crabbe <[email-masked]>
Date: Fri, 9 Nov 2012 14:18:06 -0500

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 <[email-masked]>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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Oscar González de Dios
> Sent: Thursday, November 08, 2012 5:28 PM
> To: Julien Meuric
> Cc: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>