Hi Boris, (Responding separately to your review and review from Jie in case if those requires more discussion).
Please see inline <S>. Happy New Year to all š Thanks, Samuel -----Original Message----- From: Boris Hassanov <bhassanov=40yahoo....@dmarc.ietf.org> Sent: Tuesday, December 31, 2024 9:34 PM To: 'Dhruv Dhody' <d...@dhruvdhody.com>; Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org> Cc: 'pce-chairs' <pce-cha...@ietf.org>; draft-ietf-pce-sid-a...@ietf.org; pce@ietf.org Subject: [Pce] Re: WGLC for draft-ietf-pce-sid-algo-15 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. <S> Ack, I can swap them. 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. <S> I'm fine with converting to SHOULD. 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.." <S> Ack, think about adding some details. 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). <S> Can you think about any specific interoperability issue? Requiring implementations to support such combination (MUST statement) does not seem to be best choice as it may be require triggering multiple path-computations with different set of constraints (potentially even optimization metrics) and comparing results of those. On the other hand, blocking it completely is also not best choice as there one of IGP domains may not support all constraints from FAD of other FAD (backward compatibility). I'll try to re-phrase statement with "RECOMMENDED" to avoid using it. 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.Ā <S> Please check my response to him. There are no 3 layers. LSPA and metric object are aligned and algorithm in SID is used for different purpose. 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." <S> That is not allowed even in IGP Flex-algo. If you use SR algorithm constraint with F=1 (Flex-algo path-computation), then all links in the path MUST have FA ASLA attributes advertised (all other links MUST be pruned from the topology) and all nodes along the path MUST be participation in that algo. This is part of requirements of Flex-algo path-computation in IGP and PCE MUST follow it as described in " The PCE MUST follow IGP Flexible Algorithm path computation logic as described in [RFC9350]. " 5) Happy New year! <S> 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 _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
