Re: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator

["Wanghaibo (Rainsword)" <[e-mail]>]

Hi Greg,

Thanks for your comments. Please see my answers below under the [Habio] tag.

Regards,
Haibo
From: Greg Mirsky [mailto:[e-mail]]
Sent: Saturday, November 6, 2021 1:03 AM
To: Wanghaibo (Rainsword) <[e-mail]>
Cc: [e-mail]; BESS <[e-mail]>; idr wg <[e-mail]>
Subject: Re: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator

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) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,
Thanks for your discussion.

•  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.

[Haibo] Thanks for your suggestion, and we'll make this part clearer.

•  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.
[Haibo] The last answer is specify the figure 1. The S-BFD session created here is to detect the SRv6 locator IP reachability. The S-BFD control packet from PE3 to PE1 is according to PE1’s SRv6 locator IP’s reachability, which can be achieved by ASBR1/2 advertise PE1’s SRv6 locator IP to AS65002.

•  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?
[Haibo] If we use IGP to flood the S-BFD discriminator, each node in the domain will receive the information. If we create a session as soon as we receive this information, there will be redundancy. Therefore, S-BFD sessions need to be established based on service requirements.
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?
[Haibo] For scenario 2, the S-BFD session is created based on the next-hop address, that is, the endpoint of the SRv6-Policy. So the S-BFD session is not 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?
[Haibo] For “common S-BFD discriminator” mode, we want to create an S-BFD session according to the next-hop. SRv6 Policy is only a scenario that may be widely used. In fact, SRv6 can be used as well as IPv6 MPLS or even IPv4 MPLS. That is, the S-BFD session created for the next hop address is called “common S-BFD discriminator” mode. This is to distinguish the SRv6 locator mode, which will use the SRv6 locator as the destination.
Regrads,
Haibo
From: Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, November 3, 2021 10:15 AM
To: Wanghaibo (Rainsword) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; BESS <[e-mail]<mailto:[e-mail]>>; idr wg <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Greg Mirsky
Sent: Friday, October 29, 2021 3:54 AM
To: [e-mail]<mailto:[e-mail]>; BESS <[e-mail]<mailto:[e-mail]>>; idr wg <[e-mail]<mailto:[e-mail]>>
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