Dear Imtiyaz,
Thank you for your support and excellent suggestions on the draft.
We agree that your three points—clarifying capacity limits in Section 2, adding
specific examples for the new criteria in Section 3, and clarifying the
cumulative meaning of "valid SL weight"—will significantly improve the document.
We will incorporate all of your feedback into the next revision of the draft.
Thank you for your valuable contribution.
Best regards,
Ran
Original
From: ImtiyazMohammad <[email protected]>
To: 刘尧00165286;
Cc: 陈然00080434;[email protected] <[email protected]>;[email protected]
<[email protected]>;
Date: 2025年11月27日 16:38
Subject: [spring] Re: Request for Discussion: Validity of SR Policy Candidate
Path
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Hello Ran and WG,
I support the adoption of this proposal, as the quantitative criteria
significantly improve the reliability of SR Policy validation. I have a few
suggestions that I believe will add clarity and value to the draft.
Point 1: Enhancing Section 3 (Validity of a Candidate Path)
The problem is well-defined in Section 2, but adding brief explanations and
example scenarios of how the new attributes—"valid SL count" and "valid SL
weight"—address the problem would be highly beneficial.
Valid SL count:
For example, with the topology shown in Section 2, if the operator configures a
minimum valid SL count of 2, the Candidate Path (CP) will be rendered invalid
as soon as a single Segment List (SL) goes down. This prevents the CP from
remaining active when its capacity is halved and insufficient for the full
traffic load.
Valid SL weight:
This attribute can be used to ensure a minimum required capacity. Consider two
Segment Lists: SL1 (capacity 100MB) and SL2 (capacity 200MB).
The operator configures weights proportional to capacity: SL1 has weight 1 and
SL2 has weight 2.
To ensure the CP remains active only when the higher capacity path (SL2) is
available, the operator can set the minimum required valid SL weight to 2. If
SL2 goes down, the remaining weight is 1, the criterion is not met, and the CP
is correctly declared invalid.
Point 2: Clarifying Capacity in Section 2 (Motivation)
The existing text in the Motivation section can be enhanced to clearly
establish the capacity limits of the Segment Lists, which is the core reason
for the problem.
Proposed revised text for the first paragraph of the Motivation section (
something like .):
The SR Policy POL1 has two candidate paths: CP1 and CP2, and CP1 is the active
candidate path. The two segment lists (SL1 and SL2) of CP1 are installed as the
forwarding instantiation of SR Policy POL1. These segment lists are assumed to
have a maximum capacity of 100MB each that they can carry. The CP1 carries a
total of 200MB of traffic. Within POL1, flow-based hashing is used over its SLs
with a 50% ratio, so each SL carries 100MB of traffic. At this time, if one of
the segment lists is determined to be invalid by the rule defined in RFC 9256,
the remaining Segment List cannot carry the full 200MB of traffic due to its
capacity limit. However, the CP1 is still considered active according to RFC
9256.
Point 3: Clarifying "valid SL weight"
While "valid SL count" clearly refers to the number of valid SLs, the term
"valid SL weight" could be ambiguous. A reader might interpret it as the
required weight of an individual Segment List, rather than the intended sum of
the weights of all valid Segment Lists. I suggest rephrasing this attribute in
the text to explicitly clarify that it represents the minimum cumulative weight
of all valid Segment Lists on the Candidate Path.
Thanks,
Imtiyaz
- Individual
On Thu, 27 Nov 2025 at 07:08, <[email protected]> wrote:
Hi,
I think the topic of when the candidate path is valid and the validation
criteria is an important topic, which can make SR Policy to fulfill the SLA
requirements better.
It seems that there's not a whole picture in this draft yet to show how the
enhanced CP validation method works in the network, maybe some descriptions of
the control/management plane function can be added.
Regards,
Yao
Original
To: [email protected] <[email protected]>;
Cc: [email protected] <[email protected]>;
Date: 2025年11月25日 17:05
Subject: [spring] Request for Discussion: Validity of SR Policy Candidate Path
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Hi WG，
We would like to initiate a discussion on the
https://datatracker.ietf.org/doc/draft-chen-spring-sr-policy-cp-validity/ .
This draft builds upon RFC 9256 and it adds further considerations to the
existing validation mechanisms in RFC 9256, with a focus on improving the
current approach to CP validity checks.It defines new quantitative criteria
(e.g., minimum valid SL count and weight) to refine the CP validity
determination specified in RFC 9256, addressing limitations inherent in the
simple "at least one active SID-List" criterion.
This work is critical for improving the reliability and operational accuracy of
SR Policy deployments.
We request feedback on the mailing list to help us advance this draft. Thank
you!
BR,
Ran
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
