[RTG-DIR] RtgDir review: draft-ietf-pce-association-bidir-09.txt

[Harish Sitaraman <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or
routing-related drafts as they pass through IETF last call and IESG
review. The purpose of the review is to provide assistance to the
Routing ADs. For more information about the Routing Directorate,
please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir.

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Last Call comments that you receive, and strive to resolve them
through discussion or by updating the draft.

Document: draft-ietf-pce-association-bidir-09.txt
Reviewer: Harish Sitaraman
Review Date: 30 December 2020
IETF LC End Date: 8 January 2021
Intended Status: Standards Track

Summary:
This document is basically ready for publication, but has nits that
should be considered prior to publication.

Comments:
This document is clearly written. It required a closer read due to
sentences that appear similar but differ on PCC/PCE
(initiated/delegated).

Major Issues:
No major issues found.

Minor Issues:
Section 3.1 and 3.2: The last paragraphs refers to “As specified in
[RFC8537]” for the FRR procedures. From the title of the referred RFC,
it appears to be for co-routed LSPs though from the RFC sections
2.2.1/2.2.2, it is applicable for regular single-sided and
double-sided LSPs too. Since this draft opts to mention FRR procedures
and refers to RFC 8537 unchanged, would it be better to update section
3.3 too?

Section 3.2.1: For readability, it might be better to clarify “Both
endpoint (PCC) nodes report the forward LSP1 and LSP2 to the PCE.” as
done in earlier section 3.1 to specifically call out reporting LSP1 by
node A and LSP2 by node D. The sentence as is can be read as both
nodes report both LSPs.

Section 4.1: “A Bidirectional LSP Association SHOULD NOT have more
than two unidirectional LSPs.” - it seems like this should be MUST
NOT. Is there a reason why it shouldn’t be?
Section 4.1: Were there any early allocation of IANA code points for
this draft? I’m asking in relation to section 6.1 though technically
this is outside the scope of this document.

Section 4.2: Is the F flag set if the forward LSP is not co-routed? If
yes, an explicit statement will help, similar to how the C/R flags are
clarified.

Section 6.1: It is unclear what is the use of this section as there
aren’t any details on the level of support or potential backwards
compatibility issues once IANA assigns code points. I understand how
that might be out of scope of this document, but I can’t find any use
for this section as is. Maybe the section is a need from the WG
perspective.

Nits:

Section 5.7: “Associations defined in this document and it does not
support; the”… misplaced ; instead of comma. Better to remove “and it
does not support;”.
Section 4.1: "Similarly, for both PCE Initiated and PCC Initiated
single-sided case, these associations are also dynamically created on
thee remote endpoint node using the information received from the RSVP
message from the originating node." => s/thee/the. In the first pass,
I read it as three and was wondering if there is a 3rd endpoint node
:-).

--
Harish