Thanks Med for the review and confirmation. FYI, We have posted the revised version:
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sr-bidir-path-22 thanks, Rakesh On Wed, Feb 25, 2026 at 3:44 AM <[email protected]> wrote: > 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]> 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] > To unsubscribe send an email to [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]
