Skip to main content

Last Call Review of draft-ietf-pce-stateful-pce-auto-bandwidth-09
review-ietf-pce-stateful-pce-auto-bandwidth-09-rtgdir-lc-hardwick-2019-06-18-00

Request Review of draft-ietf-pce-stateful-pce-auto-bandwidth
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2019-06-18
Requested 2019-05-31
Requested by Deborah Brungard
Authors Dhruv Dhody , Rakesh Gandhi , Udayasree Palle , Ravi Singh , Luyuan Fang
Draft last updated 2019-06-18
Completed reviews Rtgdir Last Call review of -09 by Jonathan Hardwick (diff)
Secdir Last Call review of -10 by Daniel Fox Franke (diff)
Genart Last Call review of -10 by Erik Kline (diff)
Tsvart Last Call review of -10 by David L. Black (diff)
Opsdir Last Call review of -10 by Joe Clarke (diff)
Tsvart Telechat review of -11 by David L. Black (diff)
Comments
Prep for Last Call.
Assignment Reviewer Jonathan Hardwick
State Completed
Review review-ietf-pce-stateful-pce-auto-bandwidth-09-rtgdir-lc-hardwick-2019-06-18
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/992_Rcq5PcYuSysqlQWS2BJc_oM
Reviewed revision 09 (document currently at 12)
Result Has Nits
Completed 2019-06-18
review-ietf-pce-stateful-pce-auto-bandwidth-09-rtgdir-lc-hardwick-2019-06-18-00
Hi there

I have reviewed this draft for the routing directorate as part of preparing it
for IETF last call and IESG review.

I was familiar with this document from the time that I chaired the PCE working
group, but this was the first time I read it all the way through and paid
attention to all details.  I found it easy to read and understand.  I think it
is basically ready to go with a few small clarifications and nits, below.

Cheers
Jon

Document: draft-ietf-pce-stateful-pce-auto-bandwidth-09
Reviewer: Jon Hardwick
Review Date: 18 June 2019
IETF LC End Date: LC not started yet
Intended Status: Standards Track

Comments
Section 3 is somewhat redundant IMO.
4.1 you should ideally provide a reference for how to do MBB signalling.
4.3 "Similarly, if a PCC gets overwhelmed due to signaling churn, it can notify
the PCE to temporarily suspend new LSP setup requests."  I think this is
covered by 5.7 as well as the PCE case, but you only refer to 5.7 for the
latter. Please point to 5.7 for both cases. 5.1 Not a big deal, but I wonder if
there is any practical reason to differentiate the final two bullets. 5.6 Why
are AUTO-BANDWIDTH-ATTRIBUTES required (MUST) in the LSPA object of a PCRpt? 
If the LSP is PCE-initiated, then the PCE already knows what attributes were
specified.  If the LSP is PCC-Initiated, then the attributes are the PCC's
business - the PCE can't change them (per 5.5) and I don't think the PCE even
needs to know what they are. 7.2 Misuses RFC 2119 language to request an action
from a working group.  In other documents (when there is not already a draft in
progress to do it) we have reworded this as "the YANG / MIB could be updated"
etc.

Nits
5: "Extensions to the PCEP" would sound better as "PCEP Extensions"
7: In RFC 6123 it says "The Manageability Considerations section SHOULD be
placed immediately before the Security Considerations section in any
Internet-Draft." - but here, it comes after.