Hi Jie, Thanks a lot for comments.
Please see response inline <S>. Sorry for long responses, but some of them contains copy & pasted section of the document. Regards, Samuel From: Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org> Sent: Thursday, December 26, 2024 9:06 AM To: 'Dhruv Dhody' <d...@dhruvdhody.com> Cc: 'pce-chairs' <pce-cha...@ietf.org>; draft-ietf-pce-sid-a...@ietf.org; pce@ietf.org Subject: RE: [Pce] Re: WGLC for draft-ietf-pce-sid-algo-15 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? <S> Path-computation is done based on constraints and optimization metric-type. Only constraint in list above is Algorithm constraint specified in LSPA object. Metric-type depends on path-computation type chosen by F-flag as specified in section 3.4: a) F=0 => standard (no change against RFC8231/RFC8281) path-computation done based on metric type received from Metric object from PCRpt/PCReq as specified in section 4.2.2: “…Path computation is done based on optimization metric type and constraints specified in PCEP message received from PCC….” b) F=1 => Flex-algo path-computation done based on optimization metric from FAD as specified in section 4.2.1: “…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…” So I don’t see any conflict here. One algo constraint per CP/LSP and one optimization metric type selected based on F flag. Algorithm in ERO is used for reporting purposes (e.g. PCRpt) or for encoding of already computed path by PCE (PCUpdate). Ability to specify algo per SID is there at least for 2 reasons: - SID types without algorithm specified (e.g. BSID). It would not be accurate to specify that complete E2E path is using specific algo if BSID of other policy is included in it, which may use other algorithm. - Reporting of paths, which are not result of path-computation done by Algorithm constraint, (e.g. Explicitly configured paths or paths computed by headend). Those may use SIDs with from different algorithms in single SL. We are not restricting it as there may be valid usecases, where mixing is possible (e.g. 2 IGP domains, both with same FAD but different algo number) I can still add some statement to describe 2 cases above to section 4.1. 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. <S> As described above, algorithm from SIDs is not supposed to be used in the path-computation (no change against existing usage in existing PCEP RFCs). If it is used, then only to consider for example reserved bandwidth of actual path, but not as constraint for new path-computation. Algorithm constraint and interaction with E2E path is described in section 4.2: “…Path computation MUST occur on the topology associated with specified SR-Algorithm. The PCE MUST NOT use Prefix SIDs of SR-Algorithm other than specified in SR-Algorithm constraint. It is allowed to use other SID types (e.g., Adjacency or Binding SID), but only from nodes participating in specified SR-Algorithm.¶<https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-16.html#section-4.2-5> Specified SR-Algorithm constraint is applied to end-to-end SR policy path.” For combination with other constraints – typically Flex-algo constraint (F flag =1) is not supposed to be combined with other constraints (as constraints and optimization metric are already specified in FAD), but we didn’t want to block all combinations as there are some potential exceptions. In general, there is no change against general rules described in RFC5440 from constraints processing. PCE is supposed to compute path based on all constraints specified (considering existing flags in PCEP objects, which can make it optional) and it must consider how IGP will behave, when such path will be programmed. How PCE implementation will do it is out of scope of the draft – this is same as for example basic path-computation with TE metric used as optimization metric – if path with optimal TE metric is not aligned with optimal path from IGP metric POV, then PCE must use more SIDs in SL to guarantee that traffic is forwarded based on optimal path from TE metric POV. PCEP RFCs are also not specifying how PCE implementation is supposed to do it. This is what we are also specifying in section 4.2.1, starting with statement “The PCE MUST use constraints specified in the FAD and also constraints directly included in PCEP messages from PCC. …”. Since most of the vendors probably won’t implement support for combination (at least in initial phase), then we are also describing what should happen for such unsupported combinations. 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. <S> Same as above. If both (Objective function and some constraints), then both should be applied. - 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. <S> Sure, I can add 2-3 statements to indicate use cases (reporting of path from headend, inter-area path-computation by PCE, decreasing size of compute SL,…). For “SR-algorithm TLV” – I can see that SR-algorithm constraint is already mentioned in the abstract, but I can potentially extra statement indicating Flex-algo path-computation. - 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. <S> Ack, both directions are supported (PCC <-> PCE), it is clarified later in the document, but I’ll align 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”. <S> This is not about specific rule or single section, but about complete Flex-algo concept as defined in RFC9350 (starting from FAD selection logic, ASLA attributes, algo node participation, …), which is already referenced in quoted paragraph. “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. <S> Is there reason why you think that for example “Path Min Delay Metric” cannot be used for non-Flex-algo usecase? “Min Unidirectional Link Delay” is advertised in “legacy” link attributes as well, so it is potentially even applicable to RSVP-TE path-computation. For bandwidth, it is slightly more complicated, because of automatic metric calculation, see my next response (but we are allowing that as well). - 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. <S> “draft-ietf-lsr-flex-algo-bw-con” is also just saying that bandwidth metric MAY be advertised and if it is not specified, how router can do automatic metric calculation based on attributes from FAD (so only specific to Flex-algo). We are saying same thing – those are initial 2 paragraphs of section 3.5.4 – we are just pointing to LSR draft without repeating what they already specified. On top of that we are also specifying what should be done in PCEP if bandwidth optimization metric is not specified for non-Flex-algo case – that is 3rd paragraph of 3.5.4. Are you missing something specific? - 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. <S> For PCC sending ERO to PCE, it is already mentioned in introduction section that it is sent only for troubleshooting (debugging) and visualization (data collection) purposes. Same potentially applies to opposite direction, but it is not mentioned explicitly. I can modify introduction section to specify it. I would like to avoid restricting its usage and saying that it cannot be used for other usecase as I can imagine that in PCE can potentially use it for example in case of hierarchical path-computation (BSID of one policy used in SL of other policy). 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. <S> Responded to this already above. 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. <S> I personally consider metric object part of constraints only if it is with B flag specified, so used as metric bound and optimization metric type is part of optimization criteria, but I’m fine with adjusting it with something like “The PCE MUST use constraints specified in the FAD and also constraints (except optimization metric type) directly included in PCEP messages from PCC.””. Hope this helps. Best regards, Jie 发件人: forwardingalgori...@ietf.org<mailto:forwardingalgori...@ietf.org> [mailto:forwardingalgori...@ietf.org] 代表 Dhruv Dhody 发送时间: 2024年12月6日 3:02 收件人: pce@ietf.org<mailto:pce@ietf.org> 抄送: pce-chairs <pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>>; draft-ietf-pce-sid-a...@ietf.org<mailto: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
