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

From: Greg Mirsky <[email-masked]>
Date: Tue, 2 Nov 2021 19:14:41 -0700

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.

Regards,
Greg

On Thu, Oct 28, 2021 at 7:24 PM Wanghaibo (Rainsword) <
[email-masked]> 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-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* Friday, October 29, 2021 3:54 AM
> *To:* [email-masked]; BESS <[email-masked]>;
> idr wg <[email-masked]>
> *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
>

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Fri, 5 Nov 2021 08:22:44 +0000

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:[email-masked]]
Sent: Wednesday, November 3, 2021 10:15 AM
To: Wanghaibo (Rainsword) <[email-masked]>
Cc: [email-masked]; BESS <[email-masked]>; idr wg <[email-masked]>
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky
Sent: Friday, October 29, 2021 3:54 AM
To: [email-masked]<mailto:[email-masked]>; BESS <[email-masked]<mailto:[email-masked]>>; idr wg <[email-masked]<mailto:[email-masked]>>
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

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 5 Nov 2021 10:02:47 -0700

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-masked]> wrote:

> 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-masked]]
> *Sent:* Wednesday, November 3, 2021 10:15 AM
> *To:* Wanghaibo (Rainsword) <[email-masked]>
> *Cc:* [email-masked]; BESS <[email-masked]>;
> idr wg <[email-masked]>
> *Subject:* Re: [bess] A question to the Authors of
>    - 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?
>

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Sat, 6 Nov 2021 17:25:07 +0000

Hi Greg,

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

Regards,
Haibo
Sent: Saturday, November 6, 2021 1:03 AM

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-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 3, 2021 10:15 AM
To: Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; BESS <[email-masked]<mailto:[email-masked]>>; idr wg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator

Hi Haibo,

Regards,
Greg

Thanks for you comments.

Regards,
Haibo

Dear Authors,

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 7 Nov 2021 12:52:10 -0800

Hi Haibo,
thank you for so quickly responding to my questions. I have additional
notes in-lined below and tagged GIM2>>.

Regards,
Greg

On Sat, Nov 6, 2021 at 10:25 AM Wanghaibo (Rainsword) <
[email-masked]> wrote:

> *Sent:* Saturday, November 6, 2021 1:03 AM
>    - 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.
>
GIM2>> I agree that such an advertisement would be useful and should be
mentioned in the draft. Also, it seems reasonable to mention it and discuss
possible security risks that it creates.

> [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.
>
GIM2>> I think that an implementation can be more intelligent and use a
combination of conditions to create an S-BFD session to avoid a full mesh
of S-BFD sessions in a domain.

> [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.
>
> [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.
>
> GIM2>> I have a question that might help us check if our interpretation of
the terms is close.  I've found three places in the document where
"reachability" is used. The first occurrence is in regard to the
reachability of a service, the second - "the VPN SID's reachability of PE1
and PE2", the third - "the reachability of the VPN SID". "Reachability", as
I interpret it, is the ability to deliver a packet from the source to the
destination, i.e., the existence of a path in the network domain that
connects nodes. Do you think that my interpretation of "reachability" is
close enough to how it is used in the document? That the document is not
about monitoring a remote system over the specific path, e.g., SRv6 Policy?

Regards,
Greg