Gunter Van de Velde has entered the following ballot position for draft-ietf-pce-sr-bidir-path-23: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-sr-bidir-path/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-pce-sr-bidir-path-23 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir-path-23.txt # Many thanks to Dhruv for the Shepherd writeup and John for the early RTD DIR review. # I was to ballot a blocking DISCUSS, but decided NoObj instead, as as technically i believe the documented text is accurate. However i found sometimes abbreviations, or terminology assumptions, where the authors assume that a reader of this document knows exactly what a specific term means. I have identified some of them within he following comments and would appreciate for them to be considered # in general the draft reads well, thanks you for the hard work on the text. # COMMENTS # ======== 134 PCE. This document extends this procedure and allows grouping two 135 unidirectional SR LSPs into an associated bidirectional SR LSP for 136 co-routed and non-co-routed paths. This extension also utilizes the GV> I believe i understand what co-routed and non-co-routed means, but is there a more formal definition of this term? 191 * The PCC, upon receiving the PCInitiate for the SR LSP and the 192 associated reverse SR LSP EROs, locally assigns a PLSP-ID and 193 reports it to the PCE via a PCRpt message. GV> can PLSP be expanded? 199 Tunnel 1 (0) / \ Tunnel 2 (0) 200 LSP1 (F1, R2) / \ LSP2 (F2, R1) GV> What is the (0) representing between the brackets after the Tunnel 1/2? GV> What is F1 and F2 representing? 183 Step 1 - Stateful PCE Behaviour: 184 185 * Stateful PCE creates and updates the SR LSP and the associated 186 reverse SR LSP EROs, for the 'Bidirectional SR LSP Association' on 187 a PCC via PCInitiate and PCUpd messages, respectively. 188 189 Step 2 - PCC Behaviour: 190 191 * The PCC, upon receiving the PCInitiate for the SR LSP and the 192 associated reverse SR LSP EROs, locally assigns a PLSP-ID and 193 reports it to the PCE via a PCRpt message. GV> in the chapter that follow this text we see figures 1a/1b/2a and 2b. WHen reading the document it seems tha maybe the explanation is better placed with the relevant sections for consistency. When i was reading through the text i had to go look again why there a=was a 1a/1b as that was not obvu=ious at first glance 223 Association #1 / \ Association #1 260 Association #2 / \ Association #2 GV> In the diagrams we see Association #1 and #2? Is this explained somewhere what the 1 and the 2 is referring towards? 333 As there is no reverse SR LSP instantiated, the Reverse LSP (R flag) 334 MUST NOT be set for an associated bidirectional SR LSP and MUST be and 342 Association', it MUST include the 'PATH-ATTRIB' object with R 343 (reverse) flag set to 1 to indicate that the ERO is for the reverse GV> Can it be in both places be called the same? RFC9059 seems to call this "R Flag" (reverse LSP) 368 one from the egress node PCC. In the examples shown in Figure 1 and 369 Figure 2, the ingress node PCC S reports the Tunnel 1, LSP1 to the GV> There is no Figure 1 or 2, but there is however a Figure 1a, 1b and 2a and 2b 369 Figure 2, the ingress node PCC S reports the Tunnel 1, LSP1 to the GV> it seems more accurate that instead of assuming that S stands for Source, is to spell it out or explicitly document it somewhere in the body of the text Many thanks for this document, Kind Regards, Gunter Van de Velde Routing AD _______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
