Hi Greg, Thanks for that update. The monitoring at Segment List level looks good to me.
Thanks, Ketan On Tue, Aug 1, 2023 at 3:45 PM Greg Mirsky <gregimir...@gmail.com> wrote: > 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
