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
发件人: [email protected]<mailto:[email protected]>
[mailto:[email protected]] 代表 Dhruv Dhody
发送时间: 2024年12月6日 3:02
收件人: [email protected]<mailto:[email protected]>
抄送: pce-chairs <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
主题: [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 -- [email protected]
To unsubscribe send an email to [email protected]
