Thank you Andrew for the detailed review and the suggestions. Please see replies inline with <RG>..
On Tue, Nov 18, 2025 at 2:06 PM Andrew Stone (Nokia) <andrew.stone= [email protected]> wrote: > Hi authors, PCE WG. > > The draft appears to be well structured, and pretty clear in its > instructions. Some comments/feedback: > > > - I’m still a bit unclear on the use case why a PCC needs to know > "status and all other path related information”. Knowing the ERO > information is clearer to me, but knowing all state info for the LSP is a > bit unclear. Perhaps it’s just because I didn’t dive deeper into the > related documents… > > <RG> You are right, PCC doesn't need all the information about the reverse LSP, except the ERO. <RG> I think Samuel also commented along the same line. https://mailarchive.ietf.org/arch/msg/pce/ylEPl6MC9XfqBDokzss0fv8rjyc/ <RG> Do you agree that it could just use the reverse ERO from the multi-path draft? https://www.ietf.org/archive/id/draft-ietf-pce-multipath-16.txt > > - > > > > - The document points to a lot of other RFC details, while good, means > jumping and scanning. Would be useful if some of the references pointed to > specific sections of detailed relevancy - specifically to details found in > RFC9059 since it’s tightly related. > > <RG> Acking. > > - > - > - Section 3.1 - Says a SR path must not be part of more than one > 'Double-Sided Bidirectional with Reverse LSP Association'. If this happens > (misconfig), what should the resulting action be? IMO simply stating the > PCE should not send down reverse path information to any PCC is likely > sufficient, but it would be worth describing an expected outcome. > > <RG> How about following? * An SR Path (forward or reverse) MUST NOT be part of more than one 'Double-Sided Bidirectional with Reverse LSP Association'. A PCE, upon detecting this condition, MUST NOT send the reverse SR Path to ingress node PCC. > - > - > - Section 4.2 - to confirm my understanding: for PCC-initiated > forward LSP config, the LSP must be pre-configured on PCC with the > Double-Sided Bidirectional with Reverse LSP Association values. > > <RG> Right. > > - When PCE notifies the PCC about the reverse path info, it then > re-uses these same association values, this is what will allow the PCC (and > another PCE) to correlate which is the "information-only" LSP info? > > <RG> Right. > > - i.e so the original PCC-init config is not blank and is > pre-established with an association identifier? If so, sounds good. > > <RG> I am not 100% clear on "the original PCC-init config is not blank" part. Just wanted to make sure I am not missing anything. > > - > - > - Section 3.1.1 - it says it "uses" the Bidirectional LSP Association > group TLV. Should this be changed to MUST INCLUDE for the reverse path? > since RFC9059 indicates the TLV is optional and when omitted means the path > is a forward LSP and not co-routed? in other words, when PCE uses PCE-INIT > to inform a PCC about the reverse path, it MUST carry the Bidirectional LSP > Association group TLV. > > <RG> How about following? 3.1.1. Bidirectional LSP Association Group TLV When a PCE informs ingress node PCC about the reverse SR Path using the 'Double-Sided Bidirectional with Reverse LSP Association', it MUST include the 'Bidirectional LSP Association Group TLV' to indicate the reverse direction and the co-routed path properties as defined in Section 4.2 of [RFC9059]. All fields and processing rules for this association group are followed as per Section 4 of [RFC9059]. > > - > > > Nit: > > > - Abstract last sentence says "can also" but I'm not sure what "also" > references here. Perhaps simply: The mechanisms defined in this document > are applicable to both stateless and stateful PCEs for PCE-initiated and > PCC-initiated LSPs. > > <RG> Fixed. Thanks, Rakesh (for authors) > > - > > > Thanks! > Andrew > > *From: *Dhruv Dhody <[email protected]> > *Date: *Sunday, November 9, 2025 at 1:53 AM > *To: *[email protected] <[email protected]> > *Cc: *[email protected] < > [email protected]> > *Subject: *[Pce] WGLC for draft-ietf-pce-sr-bidir-path-16 > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > > > Hi WG, > > This email marks the start of the working group last call > for draft-ietf-pce-sr-bidir-path - > https://datatracker.ietf.org/doc/draft-ietf-pce-sr-bidir-path/ > > Please indicate your support or concern for this draft. If you are opposed > to the progression of the draft to RFC, please articulate your concern. If > you support it, please indicate that you have read the latest version and > it is ready for publication in your opinion. As always, review comments and > nits are most welcome. > > The WG LC will end on Monday 24th Nov 2025. > > *A general reminder to the WG to be more vocal during the > last-call/adoption.* > > Thanks, > Dhruv & Julien > _______________________________________________ > Pce mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
