Thanks Rakesh for responding quickly, Please check response inline, marked with <S>.
Regards, Samuel From: Rakesh Gandhi <[email protected]> Date: Monday, 24 November 2025 at 23:41 To: Samuel Sidor (ssidor) <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [Pce] Re: WGLC for draft-ietf-pce-sr-bidir-path-16 Thank you Samuel for the detailed review and the suggestions. Please see the replies inline with <RG>... On Tue, Nov 18, 2025 at 8:23 AM Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>> wrote: Hi authors of draft-ietf-pce-sr-bidir-path, I have two comments regarding the draft, mostly for Section 4.1, though they may affect other sections as well: 1. Do we really need to create 2 LSPs (forward and reverse) on both - headend and tailend (so 4 LSPs just to setup single bidirectional policy with single candidate-path)? What is the purpose of encoding of reverse segment-list as separate LSP? I assume that we just need reverse segment-list for PM/BFD (the draft is already even saying that “This reverse direction LSP MUST NOT be instantiated on the PCC”) and not entire PCEP LSP. In this context, an additional segment-list/ERO should suffice and would be more efficient from an encoding perspective and most likely from resources POV in PCE LSP database, similar to the approach in draft-ietf-pce-multipath, which seems to be more efficient even for candidate-path with single SL. <RG> Yes, you are right, PCC just needs the ERO of the reverse LSP. The one defined in the multi-path draft would be sufficient, I think. <RG> I think Andrew also has a similar comment. 1. Tunnel is identified by PLSP-ID, LSP by fields from LSP-IDENTIFIERS TLV as explained in: https://www.ietf.org/archive/id/draft-ietf-pce-operational-01.html#name-structure But Figure 1b is describing 2 tunnels and at the same time describing 4 PLSP-IDs (“(100,200,300,400)=PLSP-IDs”). <RG> Do you mean it should look like the following? [Screenshot 2025-11-24 at 5.32.03 PM.png] <S> It depends on whether updated diagram is already considering comment above (but also similar comment from Andrew) that we don’t need dedicated reverse LSP. If updated diagram is just solving problem with incorrect usage of PLSP-IDs and LSP-IDs, then it looks fine to me - maybe you can just move PLSP-ID in PCRpt description into Tunnel, so it does not have to be repeated for each LSP - e.g. PCRpt: Tunnel 1 (100) LSP1 (F), LSP2 (R) Assiciation #2 If it is already trying to solve other comment about need to even create 2 LSPs on each headend, then I would say that correct diagram should be just showing: On left side: PCRpt: Tunnel 1 (100) LSP1 <= This LSP will have both forward and reverse ERO Association #2 On right side: PCRpt: Tunnel 2 (200) LSP1 Association #2 And it can be potentially extended that each LSP has forward and reverse ERO included. Note that this needs to be fixed on multiple places in the document, including complete section 4.5 <RG> How about following? 4.5. PLSP-ID Usage For a bidirectional LSP computation when using both direction LSPs on a node, the LSPs on a node would need to be identified using the same PLSP-ID based on the PCEP session to the ingress or the egress node. Note that the PLSP-ID space is independent at each PCC, the PLSP-ID allocated by the egress PCC might not be able to use for the LSP at the ingress PCC (PLSP-ID conflict may occur). In other words, a given LSP will be identified by PLSP-ID A at the ingress node while it will be identified by PLSP-ID B at the egress node. The PCE will maintain two PLSP-IDs for the bidirectional LSP. In the examples shown in Figure 1 and Figure 2, the ingress PCC S may report to PCE an LSP1 with PLSP-ID 100. the egress PCC D may report to PCE an LSP2 with PLSP-ID 200. Both of these LSPs are part of a bidirectional LSP. When PCE notifies PCC S of the reverse direction LSP2, it does so by sending a PCInitiate to PCC S with PLSP-ID set to zero and R bit set in the 'Bidirectional LSP Association Group TLV'. PCC S upon reception of this assigns PLSP-ID (example PLSP-ID 100) and issues a PCRpt to PCE. Thus there would be two PLSP-IDs associated with LSP2 (100 at PCC S and 200 at PCC D). <S> Same as above - if this is addressing just PLSP-ID part, then it seems fine to me. If it is trying to address comment about no need for creating 2 LSPs per headend, then it seems a bit strange to talk about “both direction LSPs on a node” since we have one LSP per node. <RG> Many thanks, Rakesh (for authors) Thanks a lot, Samuel From: Dhruv Dhody <[email protected]<mailto:[email protected]>> Date: Sunday, 9 November 2025 at 07:53 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 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]
