Dear authors: Please consider these comments along with any others you may have received during the adoption process.
Take a look at the output of idnits. Some issues are mentioned around the references. Make sure that every document mentioned in the text has a reference, and every reference is mentioned in the text. Specifically, the boilerplate for rfc8174 is missing. https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-liu-spring-sr-policy-flexible-path-selection-14.txt I believe the document is, in general, in good shape, even though it reads more like a framework than a specification, because most of the important parts of how to measure path quality are out of scope. Especially in section four, the process, the examples, or the actions are repeated across the different sub-sections. Also, it will be important to add an Operational Considerations section to discuss, for example, that tools should be used consistently across a network and, potentially, how to select different tools for different applications. Please see more comments below. Thanks! Alvaro. [Line numbers from idnits.] ... 82 1. Introduction ... 117 This document introduces the concept of eligibility refer to [I- 118 D.ietf-spring-sr-policy-eligibility] and specifies a comprehensive 119 quality-driven candidate path switching mechanism. It primarily 120 focuses on defining the precise conditions, operational rules, and 121 dynamic procedures required for performance-driven management. The 122 framework enables autonomous system behavior based on real-time 123 quality assessments, ensuring reliable and adaptive network 124 operations in response to fluctuating performance conditions. [minor] s/This document introduces the concept of eligibility refer to [I-D.ietf-spring-sr-policy-eligibility] and specifies a comprehensive quality-driven candidate path switching mechanism./ This document specifies a comprehensive quality-driven candidate path switching mechanism. ... 231 4. Flexible Candidate Path Selection Method ... 253 When a candidate path fails to meet forwarding quality requirements, 254 its Eligibility attribute SHOULD be set to false, thereby excluding 255 it from active candidate path selection. [major] Note that text in sections 3 and 4.3 uses "MUST" when it talks about setting the eligibility attribute to false. 257 For candidate paths containing multiple segment lists: 259 - If a segment list fails to meet forwarding quality requirements, 260 it SHOULD be excluded from forwarding operations. 262 - When all segment lists under a candidate path fail to meet 263 forwarding quality requirements, the path's Eligibility attribute 264 SHOULD be set to false, disqualifying it from active candidate 265 path selection. [major] For all the "SHOULD" statements above. Why is the action recommended and not required? In other words, what are the cases when it would be okay to not take the action even when the requirements are met? ... 350 4.2. Updated SR Policy Information Model 352 This document defines a quality-driven information model for Segment 353 Routing (SR) Policy. Specifically, it introduces threshold-based 354 performance parameters for forwarding quality under each Candidate 355 Path. When a Candidate Path fails to meet the specified quality 356 thresholds, its Eligibility attribute SHOULD be set to false, 357 thereby excluding it from being selected as the active path. [major] "Eligibility attribute SHOULD be set to false" The same normative statement exists in section four. Please only specify things once. ... 428 4.3. Rules for Setting the Eligibility Attribute [major] This section talks about the rules, so it seems to make sense that specifying the behavior using normative language would be appropriate here. Keep that in mind because there are other places in the document that also use normative language and that repeatedly specify the same thing. Specify the behavior only once. ...460 * Paths with Eligibility=false MUST NIOT participate in active [minor] s/MUST NIOT/MUST NOT ... 468 4.4. Consideration of Multiple Segment Lists ... 480 For example, two threshold parameters, delay and available 481 bandwidth, are specified simultaneously for the candidate path with 482 multiple segment lists. When the delay of a segment list exceeds the 483 threshold, the following processing is performed: 485 1) Remove the segment list from the forwarding path first. 487 2) Calculate the current available bandwidth of CP based on the 488 weight ratio of the remaining effective segment lists and the 489 bandwidth of CP. 491 3) Check whether the current available bandwidth of CP still meets 492 the bandwidth threshold requirements. 494 * If the available bandwidth still meets the requirements, the 495 candidate path still meets the forwarding quality requirements, 496 and the traffic is still forwarded along this candidate path. 498 * Otherwise, the path's Eligibility attribute SHOULD be set to 499 false, disqualifying it from active candidate path selection. [major] Where are these actions taken? It seems to me that you're specifying actions that could be taken, say, at a controller. But the list doesn't actually specify how the behavior happens. It just mentions that you should calculate, for example, not necessarily how to calculate. 501 4.5. Performance Measurement for SR Policy Forwarding Quality 503 A comprehensive SR Performance Measurement toolset is an essential 504 requirement for measuring network performance to provide Service 505 Level Agreements (SLAs). The following lists several measurement 506 methods for reference; detailed measurement methods are beyond the 507 scope of this document. [minor] I believe it's okay for this document not to define measurement mechanisms. However, I would like to see some form of operational discussion, at least regarding the use of consistent mechanisms across the whole network. ... 547 By utilizing some measurement mechanisms, the actual minimum 548 available bandwidth and actual minimum remaining bandwidth of all 549 nodes along the SR Policy path can be obtained. One possible 550 implementation to obtain the actual minimum available and remaining 551 bandwidth along a path is as follows: 553 1) The head node sends STAMP probe packets with a DOH header added 554 outside the SRH for SRv6 Policy to record the path's minimum 555 bandwidth. 557 2) At each hop, the egress interface's real-time bandwidth is 558 compared with the minimum value recorded in the DOH header. 560 3) If the interface bandwidth is greater, the DOH field remains 561 unchanged; if it is smaller, the DOH field is updated 562 accordingly. 564 4) Finally, the tail node records the final minimum bandwidth from 565 the DOH header and returns this information to the head node via 566 an extended TLV in the STAMP reply packet. [minor] Is this process documented somewhere? Please add a reference. 568 In operational deployments, real-time bandwidth may exhibit 569 continuous fluctuations. To mitigate CP switchovers resulting from 570 such variability, it is advisable to define a measurement interval 571 for bandwidth monitoring. During this interval, multiple samples 572 SHOULD be collected and averaged to smooth transient anomalies and 573 prevent spurious CP transitions. [major] Given that the measurements themselves are outside the scope, please do not use normative language here. However, you may also want to include some of these items in an operational considerations section. ... 578 4.6. Flexible Candidate Path Selection Process 580 The process of selecting the best candidate path for SR policy 581 through the threshold parameter of the candidate path is as follows. 583 1) Configure the threshold parameters on the candidate path of the 584 head node through manual configuration or controller 585 distribution. 587 2) The head node monitors whether the available resources and 588 forwarding quality of the SR policy candidate path exceed the 589 thresholds. The forwarding quality of path can be obtained 590 through active or passive performance measurement methods, such 591 as iOAM [RFC9378], STAMP [I-D.ietf-spring-stamp-srpm-mpls] and 592 [I-D.ietf-spring-stamp-srpm-srv6], TWAMP [RFC5375], etc. The 593 real-time quality data can be calculated by the controller and 594 distributed to the head node, or calculated by the head node 595 according to the network measurement data. The measurement method 596 and quality data acquisition method are beyond the scope of this 597 document. [minor] The previous section also mentions some possible mechanisms, but not all the ones mentioned here. Not only in this paragraph but across the draft, especially in section 4, there seems to be duplication where you explain the same thing several times. Please consolidate so that the tools are described in one place, the process in another, and you can link references back and forth. [EoR-14]
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
