Hi Dhruv and all, I read the latest draft and support its adoption. I see (from operator's view) very practical benefits from that work such as reducing signaling between PCE (controller) and routers, especially if we extended it towards SR Policy. So we can provision at once time both SR Policy and S-BFD sessions. This is very important in case of dynamic SR Polices, currently PCE should support and handle two SBIs for that: PCEP for SR Policy, Netconf for S-BFD. It is inefficient and can create race conditions. Here are my additional comments after review: 1) Abstract 1.1 I would re-phrase it: " This document proposes extension to PCEP to configure LSP parameters. Some of LSP parameters are needed to configure S-BFD for candidate paths." -> "This document proposes PCEP extensions for configuration and provisioning S-BFD session parameters for SR Policy candidate paths onto PCC " . 1.2 "The need for these definitions first appeared for Segment Routing path setup type, both MPLS and IPv6 data planes of SR. " -> " This extension can work with different PCEP Path Setup Types but especially suitable for Segment Routing (SR-MPLS, SRv6)." 2) Introduction 2.1 " PCEP Extensions for Segment Routing [RFC8664] specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as a PCC to request a path subject to certain constraint(s) and optimization criteria in SR networks." -> " PCEP Extensions for Segment Routing [RFC8664] specifies extensions for the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and initiate SR-TE paths with SR-MPLS dataplane, as well as a PCC can request an SR path from either a stateful or a stateless PCE. Similarly Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing [RFC9603] makes the same for SRv6." 2.2 Last paragraph " This document specifies PCEP extensions to signal additional information to configure additional LSP attributes. " -> "This document specifies PCEP extensions which allow configuration of S-BFD sessions onto PCC as additional LSP attributes."
3) 4.1 Overview 3.1 "A new option to define S-BFD parameters is defined in this document. The S-BFD parameters are only meant to be used for SR LSPs and with " -> " A new option to set up S-BFD session parameters is defined in this draft, here we focus only on SR LSPs." 4) 4.2 Processing 4.1 "If a PCEP speaker is capable of S-BFD and its peer is capable of S-BFD, then the PCEP speaker MAY send LSP-SBFD TLV towards that peer, to report the S-BFD state (Enabled/Disabled) for the configured LSP." -> " If a PCEP speaker is capable of S-BFD and its peer is capable of S-BFD too, when the PCEP speaker MAY send LSP-SBFD TLV towards that peer, to report its the S-BFD state (Enabled/Disabled) for the configured LSP." 4.2 " If B=0 and LSP-BFD-Parameters sub-TLV is received, then the PCEP speaker shall IGNORE the sub-TLV. Ignoring or saving the S-BFD configuration is implementation decision." -> "f B=0 and LSP-BFD-Parameters sub-TLV are received, when the PCEP speaker MAY IGNORE the sub-TLV. Ignoring or saving the S-BFD configuration is implementation decision. " 4.3 "In some implementations there is limitation that LSPs in the same association group must have same S-BFD parameter values." -> "Having the same S-BFD parameter values or not for LSPs in the same association group is implementation based . " 4.4 "Editor note: Alternatively, it can be defined implicitly as follows: If the LSP-SBFD TLV is not received from PCEP peer but there is S-BFD for that LSP then S-BFD shall be removed for specified LSP. ." -> Sounds quite confusing IMO. Which S-BFD config shall be removed ? Static (CLI based) ? It will be quite hard to accomplish IMO. Please clarify. 4.5 I would suggest to add here a call flow diagram, for better understanding. 5) 6. Implementation note 5.1 IMO it conflicts with section 9 (Implementation status). Wouldn't be better to move that info in section 9? 6) 7.2. PCEP Errors 6.1 There is peace of XML in the text, please correct it. That's all. SY, Boris On Friday, January 24, 2025 at 12:43:56 PM GMT+3, Dhruv Dhody <d...@dhruvdhody.com> wrote: Hi WG, We have not received sufficient feedback on the I-D, and at this point, it appears there isn’t enough support. However, considering the period of the year, the chairs have decided to extend the poll by one week. If you believe the I-D should be adopted, now is the time to share your opinion. If you do not support it, please provide your reasons. Authors are also requested to respond to the messages received so far. The chairs will review the feedback and make a final decision on Friday, 31st January. Thanks! Dhruv & Julien On Sat, Jan 4, 2025 at 4:37 PM Dhruv Dhody <d...@dhruvdhody.com> wrote: > Hi WG, > > This email begins the WG adoption poll for > draft-fizgeer-pce-pcep-bfd-parameters-03 > > https://datatracker.ietf.org/doc/draft-fizgeer-pce-pcep-bfd-parameters/ > > Should this draft be adopted by the PCE WG? Please state your reasons - Why / > Why not? What needs to be fixed before or after adoption? Are you willing to > work on this draft? Review comments should be posted to the list. > > Please respond by Monday 20th Jan 2025. > > Please be more vocal during WG polls! > > Thanks! > Dhruv & Julien > _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
