[spring] New Version Notification for draft-karboubi-spring-sr-policy-eligibility

["Karboubi, Amal" <[e-mail]>]

Hello,

A new version of eligibility draft draft-karboubi-spring-sr-policy-eligibility<https://datatracker.ietf.org/doc/draft-karboubi-spring-sr-policy-eligibility/> has been posted, which addressed the comments provided in earlier discussions notably:


  1.  Emphasizing that this document aims to generically solve the particular problem where a system needs to have a candidate path operationally up and signaled and yet prevent it from carrying traffic.  The reasons for this may be various, and document provided few examples notably around ability to continue to run measurements on the path (e.g. TWAMP) to assess health of end-end path.  This was already mentioned in earlier version, but a new paragraph under problem statement will be added on next version to hopefully make it clearer before we dive into examples.
  2.  Hopefully with that problem statement clarified, comments regarding tearing path down or using IDR draft to set the administrative state of CP as down is cleared (since the use case here is the need to keep the path up)
  3.  Added clarification at end of section 4  that there is no preference with regards to protocol being used to set the eligibility nor component used to set it. To the head end, it simply acts on final value being set and uses it in its active path selection. The components that would be responsible for setting/unsetting eligibility and choice of protocol becomes a use case and implementation specific, such use cases are developed in their own drafts e.g. draft-liu-spring-sr-policy-flexible-path-selection. However, we provided some guidelines when we have distributed system / components in place that are responsible for observing and assessing conditions that impact eligibility.
  4.  Minor updates will be added in next version for clarity throughout (e.g. avoided using the word "compressed" so it not confused with SRV6 compression when talking about SID list in one of the examples).
  5.  There were comments wether this is specific to CS-SR style only, it was clarified during last IETF that this is not the case and this is applicable to any use case that requires a path to remain up (for whatever reason) , there was no further update to the document to reflect this, as we believe existing version that separates the concept of eligibility from use cases was stated in various places of the document.

Feedback and comments are highly appreciated!
Thanks,
-Amal.