Hi Greg I think this is a highly valuable draft for operators to to be able to monitor the SR policy SID list being instantiated by the BSID binding of candidate path to forwarding plane. I think this could be applicable to SRv6.
RFC 9256 SR Policy defines a unidirectional candidate path with 2-tuple value value <color,endpoint> instantiated via PCEP, BGP, local policy. I think it’s a great idea to use S-BFD or maybe even multi hop BFD RFC 5883 to monitor the BFD session unidirectionally BFD async mode similar to the drafts S-BFD bidirectionally. The caveat with monitoring the bidirectional Co-routed path is per the draft to use RFC 5884 method to bootstrap LSP Ping FEC binding to BFD session to monitor the LSP. As the standard MPLS data plane is based on unidirectional LSP as well SR-MPLS and SR Policy Candidate path SID List is a unidirectional LSP to be monitored, what is the reason to monitor the BFD control packets bidirectionally. BFD async mode is one way control packets where echo the packets are looped requiring bidirectional LSP along the entire path. Is the monitoring of the reverse parh for special use cases such as for transport networks bidirectional Co-routed path RFC 7551 RSVP-TE extension for bidirectional Co-routed paths or maybe some other scenario. Another possible method to monitor the return path is using the path SID draft below as opposed to BSID. MPLS path Segment https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment SR Policy path Segment for bidirectional paths https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-segment Kind Regards Gyan On Wed, Jul 26, 2023 at 1:42 PM Greg Mirsky <gregimir...@gmail.com> wrote: > 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
