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… * 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. * * 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. * * 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. 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? i.e so the original PCC-init config is not blank and is pre-established with an association identifier? If so, sounds good. * * 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. 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. 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]
