Hi Joel, Regarding your comment -
> Is the intention to prohibit the driving > of LSP creation from the PCE? This capability is described in - https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07 (document expired recently, authors should refresh it) Thanks, Dhruv > -----Original Message----- > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Joel Halpern > Sent: 17 February 2017 09:08 > To: gen-...@ietf.org > Cc: draft-ietf-pce-stateful-pce....@ietf.org; pce@ietf.org; i...@ietf.org > Subject: [Pce] Review of draft-ietf-pce-stateful-pce-18 > > Reviewer: Joel Halpern > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > the IETF Chair. Please treat these comments just like any other last call > comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-pce-stateful-pce-?? > Reviewer: Joel Halpern > Review Date: 2017-02-16 > IETF LC End Date: 2017-02-28 > IESG Telechat date: 2017-03-16 > > Summary: > > Major issues: > > Minor issues: > At the end of section 5.4, the text talks about a PCE accepting status > updates even if the stateful capability has not been negotiated. Which is > fine. But as written, the text seems to say that doing so means that the > PCE will be able to "build and maintain an up to date view of the state of > the PCC's LSPs". However, if the capability has not been negotiated, I do > not see how the PCE can count on getting full and timely state reports. > Trying > to infer why a PCC is sending such a report in the absence of the agreement > seems problematic. > > 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 have looked but I can not find the text explaining the significance > and use of the Symbolic path name. It is mandated by the draft. There seems > to be an implicit assumption taht it is needed by the PCE. If the explanation > of how or why it is needed is not present, it should be. > > Nits/editorial comments: > Should the text on the S bit in section 7.3 (the LSP Object > definition) note that it should be set to 0 on all messages sent by the PCE? > Should that also be stated for the R bit? And the O bits? > > Section 9.2 seems very odd. It states that the IETF "SHOULD" do some > additional work. I understand why teh work is needed. But this does not > seem to match the RFC 2119 meaning of SHOULD as it does not apply to eitehr > the implementor or the implementation. > > > _______________________________________________ > 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
