On 02/17/2017 04:37 AM, Joel Halpern wrote:
This comment may be a misunderstanding or mis-expectation on my
part. I would have expected one of the ways o using an active PCE is
to have the PCE decide (under suitable circumstances) that an LSP is
needed between two PCCs. As far as I can tell, the text in section
5.8.2 and 5.8.3 prohibits that. A PCE is only allowed to send an LSP
Update Request (in a PCUpd message) for an LSP that has been delegated
to it. At that point I thought that a PCC could delegate a block of
unsetup LSPs to the PCE. But then looking at 5.8.2, the text states
that for each delegation, the PCC must request an initial path. That
seems to prohibit delegating a block of LSPs for future updates. Is
the intention to prohibit the driving of LSP creation from the PCE?
I think this may be a case consistency rotting over the years this draft
has been out there, which also affects my recollection of reasoning
behind the text.
Sections 5.8.1 and 5.8.2 govern how to transition from 'passive
stateful' mode of operation, where the PCC uses PCRpt to communicate
state and PCReq to solicit updates. They are not meant (or at least not
when they were originally written) to restrict the delegation procedure.
The wording of 5.8.2's first paragraph has an implicit unstated goal of
ensuring that the LSP will be set up, i.e. the PCC first makes an
explicit request to acquire the parameters needed to signal the LSP and
then delegates the LSP, thus ensuring a computation is made.
I think it is still valid for PCC to delegate an LSP without performing
5.8.1, in which case the PCE decides when (and if) to push the
parameters required to make the LSP operational.
I do see this as a problem, as the PCC is free to revoke the delegation,
based solely on its local policy, if the PCE fails to fill in the LSP
parameters in a reasonable time frame -- reverting to either local
control or to 5.8.1 mechanics.
Regards,
Robert
signature.asc
Description: OpenPGP digital signature