Dear Alvaro，
Thank you very much for your detailed review and constructive comments on
draft-chen-idr-bgp-sr-policy-cp-validity-04, especially for raising the
important question of how the CP validity mechanism interacts with the
eligibility framework (draft-ietf-spring-sr-policy-eligibility).
We have carefully considered all your feedback and have prepared an updated
version addressing the points you raised. Below is a summary of the changes:
Grammar fix: Changed "architecture are specified" to "architecture is
specified" (nit comment).
Removed unstable reference: Removed the reference to
draft-liu-spring-sr-policy-flexible-path-selection, as suggested (major
comment).
Lowercase "may": Changed the normative "MAY" to a factual "may" where
appropriate (major comment).
Editorial improvements: Fixed capitalization and wording in the validity
condition description (minor comments).
Security Considerations: Added a description about the potential DoS risk if
the validity parameters are misconfigured (either maliciously or by operator
error), with an example scenario.
We fully agree that this interaction needs to be clearly documented, and we
appreciate you giving us the options of either including the considerations in
our draft or collaborating with the eligibility authors. We intend to follow
your suggestion and would like to work together with the authors of
draft-ietf-spring-sr-policy-eligibility to develop a common understanding.
BR，
Ran
Original
From: AlvaroRetana <[email protected]>
To: [email protected]
<[email protected]>;
Cc: [email protected] <[email protected]>;spring Chairs <[email protected]>;
Date: 2026年04月24日 01:43
Subject: Chair Review of draft-chen-spring-sr-policy-cp-validity-07 (Adoption)
Dear authors:
In parallel with the WG adoption call, here's my review of this document.
Please consider the comments with other input you may receive.
As I mentioned in the adoption thread, I would like to see Operational
Considerations about the interaction of the criteria defined here and the use
of Eligibility (draft-ietf-spring-sr-policy-eligibility). These considerations
could belong in this draft, or you can collaborate to develop a common
understanding.
Thanks!
Alvaro.
[Line numbers from idnits.]
...
77 1. Introduction
79 SR Policy architecture are specified in [RFC9256]. An SR Policy
[nit] s/architecture are/architecture is
...
89 This document defines the new candidate path validity criterions
90 based on [RFC9256]. For the segment list invalidation rules, refer
91 to [RFC9256] and [I-D.liu-spring-sr-policy-flexible-path-selection].
92 This document does not change the segment list invalidation rules.
[major] The New validity criteria are based on rfc9256. It is too early to
determine the impact (on rfc9256) that
I-D.liu-spring-sr-policy-flexible-path-selection will have. Remove the
reference.
...
135 3. Validity of a Candidate Path
137 A headend MAY be informed about the validity control parameters of a
138 candidate path for an SR Policy <Color, Endpoint> by various means
139 including: via configuration, PCEP, or BGP. The detailed protocol
140 extension will be described in a separate document.
[major] s/MAY/may
In this case, "MAY" states a fact and is not needed for interoperability.
...
175 candidate path is considered valid only if both validity control
176 parameters are satisfied.
[nit] s/candidate path/A candidate path
178 If both the Minimum Valid SL Count and the Minimum Cumulative SL
179 Weight are set to 0, The validity of candidate paths must be
180 determined according to the mechanism defined in [RFC9256].
[minor] s/set to 0, The validity of candidate paths must be/set to 0, the
validity of candidate paths is
...
210 6. Security Considerations
212 The security considerations of segment routing in [RFC9256] are
213 applicable to this document.
[major] Changing the validity criteria is not without potential issues. For
example, a rogue operator may misconfigure the new validity parameters, making
the conditions impossible to meet (or too easy), resulting in a deterioration
or even an inability to provide the service . IMO, this is new (with respect to
rfc9256) and should be mentioned.
For example... Focusing on the Minimum Valid SL and considering the example in
Figure 1, it's easy to see that the correct configuration is 2 (as explained in
Section 4). However, it would be easy for an attacker (a rogue employee, for
example) to configure this parameter as 1 or 3... A value of 1 would result in
the problem this draft is trying to solve: a deterioration of the service,
while a value of 3 would result in the CP never being valid (because there are
only 2 SLs). One could consider both cases to be DoS attacks.
[EoR-07]
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
