Mahesh Jethanandani has entered the following ballot position for draft-ietf-pce-sid-algo-25: No Objection
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-sid-algo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "Abstract", paragraph 3 > This document specifies extensions to the Path Computation Element > Communication Protocol (PCEP) to enhance support for Segment Routing > (SR) with a focus on the use of Segment Identifiers (SIDs) and SR- > Algorithms in Traffic Engineering (TE). The SR-Algorithm associated > with a SID defines the path computation algorithm used by Interior > Gateway Protocols (IGPs). This document introduces extensions in > three main areas. > > Mechanisms for informing PCEP peers about the SR-Algorithm associated > with SIDs by encoding this information in Explicit Route Object (ERO) > and Record Route Object (RRO) subobjects. This document updates RFC > 8664 and RFC 9603 to allow such extension. > > The document specifies SR-Algorithm constraint, enabling refined path > computations that can leverage IGP algorithm logic, including > Flexible Algorithms, and their associated constraints and > optimization metrics. > > It defines new metric types for the METRIC object required to support > SR-Algorithm based path computation, but also applicable to Label > Switched Paths (LSPs) setup using different Path Setup Types. The Abstract is long and most of the text is duplicated in Introduction. Suggest shortening the Abstract to the first paragraph and removing the last statement, and deferring the rest of the details to the Introduction Section as has already been done. Section 4.4, paragraph 9 > * S (Strict): If set, the path computation at the PCE MUST fail > if the specified SR-Algorithm constraint cannot be satisfied. > If unset, the PCE MUST try to compute the path with SR- > algorithm constraint specified. If the path computation using > the specified SR-Algorithm constraint fails, the PCE MUST try > to compute a path that does not satisfy the constraint. In general, I support Gunter's DISCUSS. This section and this paragraph in particular was cited by OPSDIR review done by Nagendra (thanks Nagendra). Section 6, paragraph 0 > All manageability requirements and considerations listed in > [RFC5440], [RFC8231], [RFC8281], [RFC8664] and [RFC9603] apply to > PCEP extensions defined in this document. In addition, the > requirements and considerations listed in this section apply. Thanks for adding a section of manageability and for identifying additional parameters that need to be defined in the YANG model. In there a plan to update that model? ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Document references draft-ietf-lsr-flex-algo-bw-con, but that has been published as RFC9843. Document references draft-ietf-pce-pcep-yang, but that has been published as RFC9826. Section 3, paragraph 3 > implicit algorithm of BSID is independent from SR algorithm used for the SR > ^^^^^^^^^^^^^^^^ The usual collocation for "independent" is "of", not "from". Did you mean "independent of"? Section 4.4, paragraph 1 > nded along the way. * A network comprises of a set of N links {Li, (i=1...N) > ^^^^^^^^^^^^ Did you mean "comprises" or "consists of"? Section 4.4, paragraph 9 > ion that observes the worst (i.e., highest value) delay metric among all dest > ^^^^^^^ A determiner may be missing. Section 5.2, paragraph 8 > -con], a PCE implementation may need support these IGP extensions to allow u > ^^^^^^^^^^^^ The verb "support" needs to be in the to-infinitive form. Section 10.5, paragraph 1 > EPS: Usage of TLS to Provide a Secure Transport for the Path Computation Ele > ^^^^^^^^^^^^^^^^^^ Uncountable nouns are usually not used with an indefinite article. Use simply "Secure Transport". _______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
