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]
