Hi Rakesh, all, I also saw the replies from Ketan and Dhruv. I had the discussion I wanted to have for the first point and I consider that point closed. Thanks.
Thank you Rakesh for the follow-up and changes below. I also checked the diff. All looks good to me. Cheers, Med De : Rakesh Gandhi <[email protected]> Envoyé : mardi 24 février 2026 23:29 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : The IESG <[email protected]>; [email protected]; [email protected]; [email protected] Objet : Re: [Pce] Mohamed Boucadair's Discuss on draft-ietf-pce-sr-bidir-path-21: (with DISCUSS and COMMENT) Thank you Med for the detailed review of the document and the suggestions. Attaching the diff file and text file updated to address the comments. Please see replies inline with <RG>... On Tue, Feb 24, 2026 at 3:02 AM Mohamed Boucadair via Datatracker <[email protected]<mailto:[email protected]>> wrote: Mohamed Boucadair has entered the following ballot position for draft-ietf-pce-sr-bidir-path-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-sr-bidir-path/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Cheng, Mach, Weiqiang, Rakesh, and Quan, Thank you for the effort put into this specification. The theory of operation is well described and key events are identified/logged. Thanks to Carlos Pignataro for the OPSDIR review. Thanks to the authors for engaging and addressing the points raised by Carlos. Appreciated. Please find below some few DISCUSSion points: # Multipath dependency CURRENT: This extension also utilizes the procedure defined in [I-D.ietf-pce-multipath] to carry the multiple EROs and the associated reverse path EROs for an SR LSP. As there is a dependency on that one, are we confident that one is stable enough to progress this one? I appreciate that the writeup says: “This I-D uses a PCEP Object/TLV defined in the normatively referenced I-D but makes no changes to it.” but the question is also the other way around: is there any change in I-D.ietf-pce-multipath that would impact this spec? IMO, maybe wait I-D.ietf-pce-multipath to be approved before sending both documents to the RFC Editor? This is more convenient rather than pulling the doc from the RFC Editor queue. <RG> This draft uses reverse ERO object (ERO is a well-known PCEP object) and N/L/R flags for the attribute from the ietf-pce-multi-path draft, which are quite isolated and unlikely to go through a churn in that draft. # Too generic CURRENT: The PCEP YANG module [RFC9826] defines a data model for LSP associations. However, it does not include information for associated bidirectional SR LSPs. ACK. The question is: Are there key parameters that would be needed for the feature defined in this doc. For example, would the following be needed: * Indicate whether bidir paths are supported by a node? * Control activate/deactivation of bidir association? * Counters of active bidir paths? * Counters of failed bidir paths? <RG> Added these. # Liveness detection CURRENT: Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements. I’m afraid some elaboration is needed here. The intro claimed that some apps requires both direction, monitoring should be covering both directions in order to assess the serviceability. We need to say at least so (and require that both directions are correlated at the manager level). <RG> Added as follows. 8.3. Liveness Detection and Monitoring Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements as they are performed independently on both sides of a bidirectional SR LSP, using the forward and reverse LSP paths of the bidirectional SR LSP. However, the monitoring on both sides of a bidirectional SR LSP needs to be correlated at the management level to ensure that the bidirectional service carried by the bidirectional SR LSP is operational. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Stateless The abstract says: The mechanisms defined in this document are applicable to both stateless and stateful PCEs for PCE-initiated and PCC-initiated LSPs I’m not sure where stateless is discussed in the doc. If so, can we make that explicit for readers? I’m not asking to change the abstract but to have that in the introduction, for example. <RG> Added in the Introduction section at a couple of places. # Mobile case CURRENT: There are some applications that require bidirectional paths in SR networks, for example, such as in mobile backhaul transport networks. ## Great that you provided an example. ## As readers may not be familiar with specifics of that case: I wonder whether you can include a pointer where one can further dig into this specific case. <RG> We couldn't find any related reference. Removed this text as it was not part of the spec. # (Fully) Symmetric paths I wonder whether we can clarify early in the doc that bidir is not necessarily about having fully symmetric paths. <RG> Added some text related to co-routed and non-co-routed paths in Introduction. # Overview Can we say that the description assumes that no errors are encountered and all operations are successful. <RG> Added. # Section 8 I know the context of that naming in PCE, but the considerations are beyond management. Also, in order to be consistent with latest discussion in OPS, I suggest the following change: OLD: 8. Manageability Considerations NEW: 8. Operational Considerations <RG> Updated. # nits <RG> Fixed all nits below. Thanks, Rakesh ## paradigm Source routing was there before SR. Can we please consider this change through the doc: OLD: source routing paradigm NEW: source routing ## There isn’t only no one network Please consider this change in the abstract OLD: in each direction in the network) NEW: OLD: in each direction in a network) ## Expand PCC in the introduction ## Terminology OLD: Protocol (PCEP), PCEP Peer, PCEP speaker. NEW: OLD: Protocol (PCEP), PCEP Peer, and PCEP speaker. ## Section 4 OLD: the the procedures defined in [RFC9059] NEW: the procedures defined in [RFC9059] ## Section 5.2 OLD: The PST NEW: The PCEP Path Setup Type (PST) ## Section 8.6: These are not new anymore OLD: New tools such NEW: Tools such Cheers, Med _______________________________________________ Pce mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
