Subject: [Gen-art] Review of draft-ietf-pce-stateful-pce-18

From: "Joel Halpern" <[email-masked]>
Date: Thu, 16 Feb 2017 19:37:58 -0800

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.

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 17 Feb 2017 04:35:56 +0000

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:[email-masked]] On Behalf Of Joel Halpern
> Sent: 17 February 2017 09:08
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Pce] Review of draft-ietf-pce-stateful-pce-18
> 
> Reviewer: Joel Halpern
> 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.
> 
>    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:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 16 Feb 2017 23:42:30 -0500

So it is intentional that this draft prohibits that behavior (PCE driven 
establishment)?

Yours,
Joel

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 17 Feb 2017 12:10:47 +0000

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

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: 17 February 2017 10:13
> To: Dhruv Dhody <[email-masked]>; [email-masked]
> Subject: Re: [Pce] Review of draft-ietf-pce-stateful-pce-18
> 
> >> Is the intention to prohibit the driving of LSP creation from the
> >> PCE?
> >
> > https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07
> > (document expired recently, authors should refresh it)
> >
> > Thanks,
> > Dhruv
> >
> >> 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.
> >>
> >> 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.
> >>
> >> 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
> >> 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?
> >>
> >> 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:

---

From: Robert Varga <[email-masked]>
Date: Fri, 17 Feb 2017 13:48:13 +0100

> 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. 

Yes, it can.

The second paragraph on 5.8.2 is not intended to restrict usage of
delegation, but rather highlight the scenario where the LSP is
established without PCE's help.

Regards,
Robert

---

From: Robert Varga <[email-masked]>
Date: Fri, 17 Feb 2017 13:52:23 +0100

> So it is intentional that this draft prohibits that behavior (PCE driven

Yes, it is intentional. pce-stateful-pce is designed so that the PCC
remains the ultimate master of state, in line with RFC5440.

Regards,
Robert

---

From: Robert Varga <[email-masked]>
Date: Fri, 17 Feb 2017 14:12:12 +0100

> 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