Hi Ketan, thank you for your clarification in the expedient follow-up note. I have a question about the use of the B-SID. As I understand the processing, B-SID would be replaced by the associated segment list in the forwarding plane. Is that right? If it is, it seems like the packet is not identified as the BFD Control message and, consequently, not validated according to RFC 7880. Further, the packet that would be returned to SBFDInitiator would be the same packet that it transmitted. Thus, it seems to me, the procedures defined in RFC 7880 are not followed. Am I missing something?
Regards, Greg 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
