Hi Greg, Thanks for your discussion. l The First scenario is an inter-domain SRv6 scenario, which is similar to OptionC. In this scenario, we must firstly make the SRv6 locator reachable. We may redistribute the SRv6 locator routes into BGP and advertise them to the other AS. This is a common solution, so we don't describe it in our document.
l Yes, in order to speed up fault detection, we need a S-BFD session from PE3 to PE1 and also a S-BFD session from PE3 to PE2. l Figure 2 is a common scenario, here we just show a scenario which the service is over SRv6-Policy. We just show a scenario for intra-domain here, it also can be used for inter-domain. For intra-domain scenario, we can advertise the discriminator with IGP according to RFC7883 or RFC7884. But there may be create unnecessary S-BFD sessions. In fact, we may also add a S-BFD discriminator Sub-TLV for SR-Policy to create the session. But this will be only used for the service over SRv6-Policy. In our opinion, we need a common S-BFD discriminator to create the S-BFD session for detection the nexthop's reachability. Regrads, Haibo From: Greg Mirsky [mailto:gregimir...@gmail.com] Sent: Wednesday, November 3, 2021 10:15 AM To: Wanghaibo (Rainsword) <rainsword.w...@huawei.com> Cc: draft-ietf-idr-bgp-ls-sbfd-extensi...@ietf.org; BESS <bess@ietf.org>; idr wg <i...@ietf.org> Subject: Re: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator Hi Haibo, thank you for your detailed response to my question. I agree that drafts address different use cases. I also have several questions about the use cases presented in draft-wang-bess-sbfd-discriminator: * As I understand the case presented in Figure 1, PE3 uses S-BFD to monitor interdomain SRv6 tunnels to PE1 and PE2 respectively. I couldn't find discussion of how reflected BFD packets reach PE3. I hope you can clarify that for me. * Also to the case in Figure 1, do you envision also establishing S-BFD sessions from PE1 and PE2 to PE3? * The use case presented in Figure 2 seems to be within a single domain. If that is the case, wouldn't advertising S-BFD discriminators via IGP achieve the goal? I greatly appreciate it if you can clarify these questions for me.The Regards, Greg On Thu, Oct 28, 2021 at 7:24 PM Wanghaibo (Rainsword) <rainsword.w...@huawei.com<mailto:rainsword.w...@huawei.com>> wrote: Hi Greg, Thanks for you comments. I have read the draft-ietf-idr-bgp-ls-sbfd-extensions<https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-sbfd-extensions/>. The problems and scenarios he's trying to solve are different from the way we use them. The extension of the bgp-ls-sbfd-extension is to report the information collected by IS-IS/OSPF to the controller. The controller collects the information and delivers configurations to devices based on service requirements. For example, the SBFD session is configured between PEs based on this descriminator. In our solution, service routes are used to directly establish S-BFD sessions, and no controller coordination is required, simplifying deployment in some scenarios. The two scenarios are oriented to different scenarios. The bgp-ls-sbfd-extension solution mainly used for reports information. Therefore, only the information carried by IS-IS/OSPF needs to be reported. Therefore, the current extension is sufficient. As our draft needs to be service-driven. In our scenarios, intermediate routers may change nexthops. To ensure service consistency, nexthop information needs to be added to verify S-BFD the creation of redundant S-BFD sessions. Regards, Haibo From: BESS [mailto:bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] On Behalf Of Greg Mirsky Sent: Friday, October 29, 2021 3:54 AM To: draft-ietf-idr-bgp-ls-sbfd-extensi...@ietf.org<mailto:draft-ietf-idr-bgp-ls-sbfd-extensi...@ietf.org>; BESS <bess@ietf.org<mailto:bess@ietf.org>>; idr wg <i...@ietf.org<mailto:i...@ietf.org>> Subject: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator Dear Authors, thank you for bringing your work to the BESS WG. I've read the draft and couldn't find a reference to the IDR WG draft that, as it seems to me, addresses the same problem - draft-ietf-idr-bgp-ls-sbfd-extensions<https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-sbfd-extensions/>. Could you take a look at the IDR draft and share your thoughts? Do you find that anything is missing in the draft-ietf-idr-bgp-ls-sbfd-extensions? Regards, Greg
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
