Hi Joel,
In my opinion the motivation behind section 5.8.2 is to make sure that, if a
PCC needs to request a path to be computed by PCE immediately, PCC should use
the existing PCReq message to achieve that.
Can the PCC delegate an unsignalled LSP to PCE via PCRpt message? In my
interpretation it can, in some cases[1]. I would let the authors confirm on
this.
Thanks,
Dhruv
[1] https://mailarchive.ietf.org/arch/msg/pce/bexK_Nc2wHgQzV-XUC8lqMec8zY
-----Original Message-----
From: Joel M. Halpern [mailto:jmh(_at_)joelhalpern(_dot_)com]
Sent: 17 February 2017 10:13
To: Dhruv Dhody <dhruv(_dot_)dhody(_at_)huawei(_dot_)com>;
gen-art(_at_)ietf(_dot_)org
Cc: draft-ietf-pce-stateful-pce(_dot_)all(_at_)ietf(_dot_)org;
pce(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: [Pce] Review of draft-ietf-pce-stateful-pce-18
So it is intentional that this draft prohibits that behavior (PCE driven
establishment)?
Yours,
Joel
On 2/16/17 11:35 PM, Dhruv Dhody wrote:
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-bounces(_at_)ietf(_dot_)org] On Behalf Of Joel
Halpern
Sent: 17 February 2017 09:08
To: gen-art(_at_)ietf(_dot_)org
Cc: draft-ietf-pce-stateful-pce(_dot_)all(_at_)ietf(_dot_)org;
pce(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/pce