Happy New Year! Many thanks Harish for the RtgDir review. Please see replies inline with <RG>…
From: Harish Sitaraman <[email protected]> Date: Wednesday, December 30, 2020 at 6:07 PM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: RtgDir review: draft-ietf-pce-association-bidir-09.txt 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? <RG> We can add following sentence in Section 3.3. The procedure specified in [RFC8537] for fast reroute bypass tunnel assignment is also applicable to the Co-routed Associated Bidirectional LSPs. 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. <RG> Ok. <Old> Both endpoint (PCC) nodes report the forward LSP1 and LSP2 to the PCE. <New> The endpoint node A (PCC) reports the forward LSP1 and endpoint node D reports the forward LSP2 to the PCE. 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? <RG> During MBB, there can be more than one LSP. May be we should remove this sentence as it can be confusing. 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. <RG> No IANA code-points were allocated. 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. <RG> We can add following sentence: O When "Bidirectional LSP Association Group TLV" is present, the F flag MUST be set for the forward LSP for both co-routed and non co-routed LSPs. 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. <RG> No IANA code-points were allocated. This section will be removed before publication. 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;”. <RG> <New> If a PCEP speaker receives a different PST value for the Bidirectional LSP Associations than defined in this document, the PCE speaker MUST return a PCErr message with Error-Type = 26 (Association Error) and Error-Value = TBD6 (Bidirectional LSP Association - Path Setup Type Not Supported). 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 :-). <RG> Yes, will fix ‘thee’ to ‘the’. Thanks, Rakesh -- Harish
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
