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
Attachment:
signature.asc
Description: OpenPGP digital signature