Thanks Andrew for reviewing the updates and also finding an omission. We have posted the updated draft to address your suggestion.
URL: https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir-path-19.txt Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sr-bidir-path-19 Thank you again, Rakesh (for authors) On Mon, Dec 1, 2025 at 12:51 PM Andrew Stone (Nokia) <[email protected]> wrote: > Sorry that should say “figure 2b” —> not 3b. > > *From: *Andrew Stone (Nokia) <[email protected]> > *Date: *Monday, December 1, 2025 at 12:49 PM > *To: *Samuel Sidor (ssidor) <[email protected]>, Rakesh Gandhi < > [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 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]> > 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) <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]
