Hi Everyone, We received a lot of valuable feedback during yesterday's presentation. A lot of Thanks to Keten for helping to answer the questions during the discussion in yesterday's meeting. Here, we have compiled the questions and comments we received from the queue and chat and tried to provide responses. We hope to receive more feedback from the WG members. If there are any missing commnets, please help to supplement them. 1. Himanshu Shah: SR Policy is based on intent. All the CPs are there and being monitored. Do we need your mechanism to select the canadidate path? [Reply] This mechanism is used for situations where the quality of CP forwarding changes, such as a decrease in latency. The head end node can monitor the results in real-time for CP switching, improving the response speed to changes in network forwarding quality. 2. Susan Hares: Can you tell me what how the adding this will change the amount of data flow that occurs? Will it change the rate of sending candidate routes? Will it increase it? Will it decrease it? I realize why you might want it, but can you have you looked at what it does to the flow pattern of the BGP updates? [Reply] This mechanism will not affect the forwarding of data flow, nor will affect the distribution of BGP SR Policy routing. As the threshold for network quality parameters, the configuration will only be issued once through BGP SR Policy, and the head end node will monitor the network quality and complete CP switching based on the threshold. 3. Shraddha Hegde: The active CP can be updated by controller to satisfy all the resource requirement. why isn't that an option and a new candidate path selection needed? [Reply] Providing this mechanism is to not rely on the controller and for the head end node to do the monitoring. e.g., delay measurement. 4. Martin Horneffer : the current path selection procedure is complex enough. IMHO a single preference is enough. [Reply] This mechanism is perhaps better done by marking a CP which is say seeing delay over a threshold as invalid. So it doesn't change the tiebreaker. 5. Antoine Fressancourt : Is it the case that the SR policy is announced once, and the thresholds are updated several times after the initial SR policy announcement ? [Reply]The threshold does not change as they are configured but then monitored for CPs. The thresholds are only configured once. 6. Himanshu Shah : It is an additional CP selection criteria based on SLA threshold. My point is that this is implicit in SR-Policy creation that TE is monitored [Reply] It becomes super complication if we try to change the selection process by all these parameters. But this mechanism can simplify the process by marking a CP crossing a threshold as "invalid" and then fallback to existing CP selection in RFC9256. 7. Antoine Fressancourt : This is what I supposed a PCE / controller would do, maybe announcing threshold is required for explaining the path selection for requesting routers [Reply] The thresholds only need to announce once from the controller to the head end node and the head end node can monitor the forwarding quality of CPs according to the thresholds. 8. Himanshu Shah: The built-in assumption on SR-Policy that all the CPs are calculated based on the intent that is monitored periodically so when not met.. you select the next priority CP [Reply] It depends on the policy to do the implementation keep monitoring all CPs all the time or only to do so for specific CPs when needed. 9. Srihari Sangli : Another point is that, each ingress is better suited to check the CP from its point of view as opposed to do all verification from a centralized entity. [Reply] Yes, this is also the starting point for us to propose this mechanism. Please help to further review the draft (https://datatracker.ietf.org/doc/draft-liu-spring-sr-policy-flexible-path-selection/) If you have more questions and comments , welcome to let us know. Best Regards Yisong on behalf of co-authors
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
