Hi Ketan, thank you for clarifying the SR Policy composition. We've updated the draft to address your suggestion. I greatly appreciate it if you review the updates highlighted in the diff <https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-bfd-08> and would kindly share your feedback.
Regards, Greg (on behalf of the authors) On Wed, Jul 26, 2023 at 10:30 AM Ketan Talaulikar <ketant.i...@gmail.com> wrote: > Hello All, > > Sharing the comments made at the mike in today's session to the list as we > ran out of time: > > 1) The "path" to be monitored for SR Policy should be the Segment List and > not Candidate path. Perhaps > https://www.rfc-editor.org/rfc/rfc9256.html#section-2.13 will clarify the > model for SR Policy. The RFC section 2 explains in more detail. > > 2) SR Policy construct is unidirectional and hence the issue of packet > drops in reverse path is applicable to all forms. There may not always be a > reverse path. > > 3) If there is a need to specify a reverse path, the same can be done > without the need for LSP ping bootstrap overhead. E.g., > https://datatracker.ietf.org/doc/html/draft-ali-spring-bfd-sr-policy-10#section-3.3 > - there are also other mechanisms like using the BSID of the reverse path > to return. > > Thanks, > Ketan > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
