Hi Joel,
Thank you for your invaluable feedback, which has been immensely helpful in
refining the draft. We truly appreciate your insights and expertise. As we
contiune to move forward with the draft, we look forward to receiving more of
your guidance.
Best Regards
Yisong on behalf of co-authors
发件人: Joel Halpern
时间: 2025/01/09(星期四)23:51
收件人: Yisong Liu;spring;
抄送人: draft-liu-spring-sr-policy-flexible-path-selection;
主题:
Re:_Re:_Re:_[spring]_Ask_SPRING_WG_for_review_draft-liu-spring-sr-policy-flexible-path-selection
Thank you for adding the paragraph about the relationship to RFC 2386.
With that added, I think that further nuances if needed can be left till
later in the process.
Yours,
Joel
On 1/9/2025 2:27 AM, Yisong Liu wrote:
Hi Joel,
I apologize for the response so late. We have updated the
draft as suggested, added references to RFC2386 and noted
the limitations of this draft, and you can find the latest
version (08) at the following link:
https://datatracker.ietf.org/doc/draft-liu-spring-sr-policy-flexible-path-selection/08/.
Please let us know whether this addresses your questions. If
you have any further comments or suggestions, please share them
with us.
Best Regards
Yisong on behalf of co-authors
发件人: jmh.direct <jmh.dir...@joelhalpern.com>
发送时间: 2024年12月11日 14:33
收件人: Yisong Liu <liuyis...@chinamobile.com>;
Joel Halpern <j...@joelhalpern.com>; spring
<spring@ietf.org>
抄送:
draft-liu-spring-sr-policy-flexible-path-selection
<draft-liu-spring-sr-policy-flexible-path-select...@ietf.org>
主题: RE: Re: Re: [spring] Ask SPRING WG for
review draft-liu-spring-sr-policy-flexible-path-selection
Rather than my trying to restate the problem, I would recommend
reading
Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G
smartphone
-------- Original message --------
From: Yisong Liu <liuyis...@chinamobile.com>
Date: 12/11/24 1:23 AM (GMT-05:00)
To: Joel Halpern <j...@joelhalpern.com>, spring
<spring@ietf.org>
Cc: draft-liu-spring-sr-policy-flexible-path-selection
<draft-liu-spring-sr-policy-flexible-path-select...@ietf.org>
Subject: Re: Re: [spring] Ask SPRING WG for review
draft-liu-spring-sr-policy-flexible-path-selection
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