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.

_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

Reply via email to