Hi all,
I reviewed 16th version of the draft and support its progressing. Some comments are below: 1) Section 3.5 1.1 IMO it is kind of counter-logic to place firstly item 3.5.1 Path Min Delay Metric value ahead of 3.5.2 Path Min Delay Metric. So firstly we talk about the value itself then about the metric description, it should be vice verse IMO. 1.2 Similarly for 3.5.4/3.5.4 Path Metric 1.3 Also this part in 3.5.4 sounds confusing: "...then performing path computation for other algorithms and Generic Metric sub-TLV with Bandwidth metric type is not advertised for the link then PCE implementation MAY have local policy to specify attributes similar to section 4.1.3 and 4.1.4 in [I-D.ietf-lsr-flex-algo-bw-con] and compute metric value automatically or the link MAY be treated as if the metric value is not available for other metric types (e.g. use default value instead). ... ". I think MAY is either not enough here (i.e. use SHOULD instead) OR there should be sort of tie-breaker when PCE does not have a local policy (because of MAY), so how PCE should compute BW metric in this case? I would like to see here a clear and consistent description for a multivendor PCE case without any understatements. 2) Section 4.2 2.1 "It is allowed to use other SID types (e.g., Adjacency or Binding SID), but only from nodes participating in specified SR-Algorithm." It would be great to clarify more about procedure for BSID association with particular SR-Algorithm from some node there. Especially when we later talk about the case when ".. headend is part of multiple IGP domains.." 2.2 Again for this "multiple IGP domains" paragraph I see potential interoperability issues due to this MAY/RECOMMENDED combination (just compare it with more strict 4.2.1 section). 3) Earlier Jie's comments about additional complexity for 3 layers modifications (SID, LSPA and Metric objects) is worth to think about if simplification is possible or not, IMO. 4) I also would like to see some clarification in 4.2.1 for the case when PCE needs to calculate a path between the nodes, which are in some FAD (or FADs) and node(s) which are not. Which metric a PCE should or must use in this case? I meant mapping of that statement for such scenario: " The PCE MUST optimize computed path based on metric type specified in the FAD, metric type included in PCEP messages from PCC MUST be ignored." 5) Happy New year! Thank you. SY, Boris On Thursday, December 26, 2024 at 11:06:52 AM GMT+3, Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org> wrote: Hi WG, I’ve read the latest (-16) version of this draft, and think the proposed function is useful, thus I support progressing this document. While please find below some review comments for the authors to consider refining the document before moving it to the next stage. One major comment is that this document proposes to carry SR-algorithm and associated constraints at different places/levels: - Algorithm of each SR SID - Algorithm in LSPA object - New metric types in METRIC object It would be helpful to clarify whether it allows inconsistent or conflict algorithms/constraints being carried in the same message, and if so, which one would take precedence in path computation, or what would be the consequence? Section 4 mainly talks about the processing of the SR-Algorithm TLV in the LSPA object, while the combination of the SR-Algorithm for the end-to-end path, the algorithms for the SIDs, and other constraints in the message is not fully specified. And in section 4.2 the draft says “SR-Algorithm does not replace the Objective Function defined in [RFC5541]”, then can SR-algorithm and Object Function coexist in one message? If so, the same question applies. - Abstract As indicated by the text, the SR-SID and associated algorithm is distributed in IGP and already available to the routers, the abstract can briefly introduce the typical scenario and the related PCE process (e.g. in PCE request/reply, PCE update/report or PCE initiate) in which the SIDs and associated algorithms need to be informed by the PCE to the headend router. In addition to the PCEP extensions for indicating the algorithm associated with each SID, this document also proposes extensions to the LSPA object to carry SR-algorithm TLV. It is suggested to also reflect this functionality in the abstract. - Introduction “Both the PCE and the headend router may independently compute SR-TE paths with different SR-Algorithms. The headend needs to relay this information to the PCE for purposes such as data collection and troubleshooting. In scenarios involving multiple (redundant) PCEs, when a headend receives a path from the primary PCE, it needs to be able to report the complete path information, including the SR-Algorithm, to a backup PCE.” It seems the above text is about the headend router informing PCE about the SR-TE paths and the associated algorithms of each SID, which is different from the direction of information distribution as described in the abstract. It is suggested to align the scenario in the abstract and introduction. “In the context of SR-TE, the PCE must ensure that paths computed using Flexible Algorithms are congruent with the desired routing policies and constraints. This involves using the same ordered rules to select FADs when multiple options are available, and considering node participation in the specified SR-Algorithm during path computation. The PCE must also optimize paths based on metrics defined within the FAD, ensuring alignment with the operator's objectives.“ Here a reference to the specific section in RFC 9350 would help. And suggest to replace “the metric defined within the FAD” with “the metric type specified within the FAD”. “The introduction of new metric types, such as Path Min Delay Metric and Path Bandwidth Metric, further enhances the ability of PCE to compute paths that meet these criteria.” For congruent path computation, it seems these new path-level metric types are only applicable when the SR-algorithms use the same metric types (delay or bandwidth). Maybe this can be mentioned somewhere in the introduction or the operation section. - Object Formats I don’t have specific comments on the encodings. While section 3.5.4 refers to draft-ietf-lsr-flex-algo-bw-con about the definition of bandwidth metric. The text says Bandwidth Metric “MAY be advertised in their link metric advertisements”. While draft-ietf-lsr-flex-algo-bw-con mainly describes the automatic calculation of bandwidth metric based on the advertised link bandwidth attribute and the rules of deriving the bandwidth metric. It is suggested to align the descriptions about bandwidth metric with that document. - Operation For the PCC, after receiving the Algorithm in the ERO Subobject, will it be used for operation other than reporting the algorithm information in the PCrpt message? The same question applies for the PCE side. In addition to the specification about path computation based on SR-Algorithm constraint, the combination of SR-algorithm with other constraints also needs to be further specified. Section 4.2.1 says that the metric type included in PCEP message from PCC MUST be ignored by PCE, while the PCE should use metric type from FAD in messages sent to the PCC. Then it also says “The PCE MUST use constraints specified in the FAD and also constraints directly included in PCEP messages from PCC.” Is Metric object considered as part of the constraints included in the PCEP message? It seems the text could be further aligned and clarified. Hope this helps. Best regards, Jie 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Dhruv Dhody 发送时间: 2024年12月6日 3:02 收件人: pce@ietf.org 抄送: pce-chairs <pce-cha...@ietf.org>; draft-ietf-pce-sid-a...@ietf.org 主题: [Pce] WGLC for draft-ietf-pce-sid-algo-15 Hi WG, This email starts a 3-weeks working group last call for draft-ietf-pce-sid-algo-15. https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/ Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version and it is ready for publication in your opinion. As always, review comments and nits are most welcome. The WG LC will end on Friday 27 Dec 2024. A general reminder to the WG to be more vocal during the last-call/adoption. 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
