Hi Joel,
Thank you for your comments. I want to provide some clarity regarding the
purpose and scope of this draft . This draft tackles the scenario where
multiple paths are available, and the need arises to switch paths based on
their quality metrics. It is not intended to replace the controller's role in
global optimization but rather to complement it by allowing for local,
quality-driven responses to link degradation.
The draft specifically addresses the ability to switch to alternative paths
within a strategy when the current path fails to meet specified link quality
criteria such as bandwidth, delay, or packet loss. In cases where a controller
issues an SR Policy that encompasses multiple paths, if a path's link quality
does not meet the set requirements, it will switch to a backup path for
forwarding.
Essentially, this draft resolves the forwarding status of SR Policy paths,
facilitating a switch based on link quality. It is important to note that the
overall path optimization remains under the purview of the controller, which
continues to make global decisions. This draft addresses the selection issue of
multiple paths under an SR Policy, ensuring that the network can adapt to local
conditions without overriding the controller's broader strategies.
I'm not sure if I've explained everything clearly. If you have any further
questions, please feel free to continue the discussion.
Best Regards
Yisong
发件人: Joel Halpern
时间: 2024/12/09(星期一)11:45
收件人: Yisong Liu;spring;
抄送人: draft-liu-spring-sr-policy-flexible-path-selection;
主题: Re: [spring] Ask SPRING WG for review
draft-liu-spring-sr-policy-flexible-path-selection
Looking at this draft, there seem to be two related aspects, one of which
makes sense, and one of which needs work.
As a participant, I can understand the general goal. And adjusting the
path selection when component link issues reduce the overall available
bandwidth, increase the end-to-end delay, or increase the expected jitter
is understandable. I leave whether this is the right approach to that
problem to those who have worked more closely with SR policies.
However, if I read section 4.1 properly, it wants to change the path
selection in response to observed parameters such as observed packet loss
(frequently in practice caused by congestion.) On fortunately,
distributed dynamic path selection based on parameters that are sensitive
to traffic load has well-known problems with various responders adjusting
resulting in simply moving the problem. If you have recognized this
problem and I missed it, please cite RFC 2386 early in the document, and
point to the resolution. If you have not addressed this problem, please
either do so or restrict the applicability of this proposal.
Delaying response is not sufficient.
Yours,
Joel
On 12/8/2024 9:37 PM, Yisong Liu wrote:
Dear WG members,
With the rise of AI models, new intelligent computing services
require enhanced network reliability, especially in
quality-sensitive scenarios like storage-compute separation and
real-time inference. The
draft-liu-spring-sr-policy-flexible-path-selection offers
flexible path switching for quality degradation, crucial for
maintaining network performance.
This draft proposed a new mechanism to specify
multiple candidate paths for SR policies, allowing for more
sophisticated traffic engineering. It supports
dynamic path adjustments based on real-time network conditions,
optimizing resource utilization and ensuring high service
quality. This draft aims to provide network operators with
greater flexibility and control over traffic routing in SR
networks.
We have just posted a new version. Please see the draft in
the following link:
https://datatracker.ietf.org/doc/draft-liu-spring-sr-policy-flexible-path-selection/
I hope you can review this draft and share your feedback.
Welcome any questions and comments.
Best Regards
Yisong on behalf of co-authors
_______________________________________________ spring mailing list --
spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
