Hi Rakesh, Thanks for the updates and clarifications below and in the -18 revision, looks good to me.
Only one thing remaining: I think some updates are needed to Section 3.2 to reflect the changes. Section 3.2 Step 2 indicates Stateful pce "MUST update" via a "PcInitiate message" (emphasis mine) or PcUpd message. For PCC-Initiated, since this is carried in the reverse path ERO now, there's no interaction here with PCInitiate message therefore its use can be just omitted. Extending on this, the example in figure 3b displays PCInitiate but in this situation it would just be a PcUpd of PLSPID 100 to inform R2, and PLSPID 200 to inform R1. Lastly -> note that the PcUpdate MUST CONTAIN both the forward and reverse EROs (all or nothing) in the update. Thanks! Andrew From: Samuel Sidor (ssidor) <[email protected]> Date: Friday, November 28, 2025 at 3:41 AM To: Rakesh Gandhi <[email protected]>, Andrew Stone (Nokia) <[email protected]> Cc: Dhruv Dhody <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [Pce] Re: 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. Thanks a lot, Rakesh. Updated version looks fine to me (I support WGLC). Regards, Samuel From: Rakesh Gandhi <[email protected]> Date: Friday, 28 November 2025 at 01:58 To: Andrew Stone (Nokia) <[email protected]>, Samuel Sidor (ssidor) <[email protected]> Cc: Dhruv Dhody <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [Pce] Re: WGLC for draft-ietf-pce-sr-bidir-path-16 Hi Andrew, Samuel, WG, Attaching the further updated draft that uses Reverse ERO instead of Reverse LSP for an associated bidir SR path. Hope this addresses your suggestions. Please advise your review comments on these updates. Thanks, Rakesh (for authors) On Mon, Nov 24, 2025 at 5:28 PM Rakesh Gandhi <[email protected]<mailto:[email protected]>> wrote: 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) <[email protected]<mailto:[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]<mailto:[email protected]>> Date: Sunday, November 9, 2025 at 1:53 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[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<http://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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
