Hi Med, This document normatively references draft-ietf-pce-multipath and uses the mechanism defined there without making any changes to those procedures. Any "likely" change in draft-ietf-pce-multipath that also requires a change in this I-D would probably involve altering a TLV name or flag name, which IMHO can easily be handled during RFC Editor cluster processing.
Thanks! Dhruv On Tue, Feb 24, 2026 at 2:27 PM Ketan Talaulikar <[email protected]> wrote: > Hi Med, > > Thanks for your detailed review. > > Only responding on your first DISCUSS point as the responsible AD. > > I had brought up exactly this same point to the authors/WG as part of my > AD review (see point 3 of [1]). Following this, the authors made > significant improvements to this document to clarify the one-way dependency > from this document to the multipath draft (at least that is how I see it > but I let the authors/WG confirm). So, I did not see any strong technical > issue - even if the multipath document is still in WGLC currently. > > I had asked the WG to consider moving them both together [2] but left it > to the chairs/WG if they still wished to progress this document > independently. > > I hope this provides some context and I will follow the discussion on this > point along with others in your review. > > Thanks, > Ketan > > [1] https://mailarchive.ietf.org/arch/msg/pce/X7Rzx92UN5KJ2UeD3gWCyoG_jz8/ > [2] https://mailarchive.ietf.org/arch/msg/pce/VuY1j0BM3qbBzA7B8qvM2guAFnw/ > > > On Tue, Feb 24, 2026 at 1:31 PM 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. >> >> # 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? >> >> # 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). >> >> >> ---------------------------------------------------------------------- >> 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. >> >> # 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. >> >> # (Fully) Symmetric paths >> >> I wonder whether we can clarify early in the doc that bidir is not >> necessarily >> about having fully symmetric paths. >> >> # Overview >> >> Can we say that the description assumes that no errors are encountered >> and all >> operations are successful. >> >> # 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 >> >> # nits >> >> ## 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]
