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]
