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]
