Hi Haibo, thank you for the detailed answers. I have added my follow-up notes below under the GIM>> tag.
Regards, Greg On Fri, Nov 5, 2021 at 1:22 AM Wanghaibo (Rainsword) < [email protected]> wrote: > 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. > GIM>> Indeed, it is a well-known technique that can be mentioned with reference. I see it being helpful to a reader. > 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. > GIM>> As I understand the use of S-BFD in this case, PE3 transmits BFD control packets over the SRv6 Policy. If that is the case, I have two questions: - Several SRv6 Policies between PE3 and, for example, PE1 might be used. If that is the case, would each such SRv6 Policy be monitored by its dedicated S-BFD session? - It is still not clear to me how a reflected BFD control packet reaches PE3 from, for example, PE1. 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. > GIM>> That is an interesting point. Could you please share more details on what you consider as "unnecessary S-BFD session" and in what case these might be created? > 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. > GIM>> Would then S-BFD session be created for each SRv6 Policy? > In our opinion, we need a common S-BFD discriminator to create the S-BFD > session for detection the nexthop's reachability. > GIM>> Can you please clarify what is the "common S-BFD discriminator"? And what is the scope of the monitoring process - each next-hop or each SRv6 policy? > > > Regrads, > > Haibo > > > > > > *From:* Greg Mirsky [mailto:[email protected]] > *Sent:* Wednesday, November 3, 2021 10:15 AM > *To:* Wanghaibo (Rainsword) <[email protected]> > *Cc:* [email protected]; BESS <[email protected]>; > idr wg <[email protected]> > *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) < > [email protected]> 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:[email protected]] *On Behalf Of *Greg Mirsky > *Sent:* Friday, October 29, 2021 3:54 AM > *To:* [email protected]; BESS <[email protected]>; > idr wg <[email protected]> > *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 [email protected] https://www.ietf.org/mailman/listinfo/bess
