Hi WG, Please accept my apologies for the delayed response. Following the IETF 122 meeting, we greatly appreciated the valuable feedback and insightful comments received from the experts. In response, we have submitted an updated version (version 10) of the draft.
We have provided responses as follow to the main comments received and would welcome any further feedback you may have. 1. Comment from Himanshu Shah: This is an usecase. There are many usecases where you can apply eligibility. Those use cases should not be defining different ways on how can switch over from CP one to CP two. If the intent is not met you invalidate the CP.[Reply] No different approaches should be defined for CP switchover. Our current draft has been revised to the 'eligibility' state without altering the original 'validity' state as defined in RFC9256.2. Comment from Ketan Talaulikar: In RFC9256, we have the tiebreaking rules which are strictly governed by the operator that is provisioning the SR policies via BGP, PCEP or CLI. They are static in nature. Then we have the validation rules for the situations on whatever can be detected on headend. We are adding more qualitative checks which change dynamically based on network conditions. This is something additional. I like the eligibility proposal. Whatever it is called is up to the WG. My suggestion is to update RFC9256. I don't believe there is a need for a bis. I will summarize on the mailing list.[Reply] We use the eligibility draft [I-D.karboubi-spring-sr-policy-eligibility] as the basis for quality-indicator path selection, with updates made to Sections 1, 4.1 and 4.2, and please check the version 10.3. Comment from Boris Khasanov: Similarly to that Ketan said - we need to manage the consistency with RFC 9256, if it says CP is active then 1 SL is active. Here we also bring additional eligibility criteria vs. RFC 9256 as in previous drafts.[Reply] We will not modify the routing mechanism of RFC9256. Additional CP states are introduced solely for path selection based on metrics like bandwidth and latency. For specific mechanism changes, please refer to the updated section 4.2 in the document.4. Comment from Shraddha Hegde: Is the eligibility criteria or whatever validation used only when PCE initially installs the paths and you select, or is the router continuously monitoring and evaluating the eligibility and reselect if not eligible?[Reply] The ingress router continuously monitors metrics such as bandwidth and delay of the CP. If requirements are not met, reselection is performed. For specific mechanisms, please refer to Section 4.3 in the draft.Thank you for your continued support and welcome more feedback. Best Regards Yisong on behalf of co-authors
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
