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 protected]
https://www.ietf.org/mailman/listinfo/pce
