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 <mailto:j...@joelhalpern.com>
时间: 2024/12/09(星期一)11:45
收件人: Yisong Liu <mailto:liuyis...@chinamobile.com>;spring
<mailto:spring@ietf.org>;
抄送人: draft-liu-spring-sr-policy-flexible-path-selection
<mailto:draft-liu-spring-sr-policy-flexible-path-select...@ietf.org>;
主题: 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
