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