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

Greg Mirsky <gregimirsky@gmail.com> Sun, 07 November 2021 20:52 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324D93A0D40; Sun, 7 Nov 2021 12:52:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P31jQB5s9lSV; Sun, 7 Nov 2021 12:52:24 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DFC73A0D4A; Sun, 7 Nov 2021 12:52:23 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id r12so54475592edt.6; Sun, 07 Nov 2021 12:52:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7bonbQtb/aDZBsb+HUXWb3m88kAGuiED1zE6LgE6tFQ=; b=GtC+0kjtsHTuCLjTYdv3kPgFON99H/faFXrZ4up6XgSA91tT44Zn4EJOJ9B8CReIt6 FWYfaXbHLSs5bJD8go7tGhO/zYv0g82TFCrjaw02RO+iPcYfXoxHENwZdijlIHo/6r6u 3BB0JFoTux28Y7GkKHUG27aZzoCA+RQdTQnzWpNKKqc1kW8RPgYGMJcwBRlE64wwU6DV RJLgnLugh4ODNZnxCY0qZ+6jfcCWiUZ00FS4bAdUnBIwgUyHHXAUBXaeUDJyErPihExq NRgO8BFEpuzyp7lTVOfiemvGHG6IXsqsY34ZPfGpqUmp43/JqKk3cifZWSEXylK9+IuX pz+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7bonbQtb/aDZBsb+HUXWb3m88kAGuiED1zE6LgE6tFQ=; b=dmVEY0gvedqKDZ69Q/TECOroefLG9fiM7GQKQZ64Qa6pLxDvvkKP46qRjbxNSzIdzw y7FmA+r4keoAhKu3tvwyqOALcGx8C2S8hDUOX4wNRhNfLy7o2+cUzXMagOXkwZ1AQq79 OSVMtnfbND3FBFA4k1EnT1tNua/P//kLM6modGQye0WrDjzRpl5RHqVM4sVY09nXLopQ pl8w0v7AvjHdcRjWzXtQzK/Eri8asewj3eE/ievoOOsQyBT2pmEyTMPrCA0qAWljbfA1 VxUCd9Tzuz1Y7HC/Bg8lB0xa8Hj99BfTQ/XDcpy+E/8+/69TrGJJWkFDqSZuS4+tqZGC 15ig==
X-Gm-Message-State: AOAM533gottIznmeNPTHXAR+8iHqasXHHI+d1yEVdUddnAtT37enc5mC w2NgA3S+xoTXN2nZwtPPpdgeLmRzLq65ozd/1xgjlwR7+4Q=
X-Google-Smtp-Source: ABdhPJzRerETIfpEKcanEGQfzKJRBkPTHCJYj/jZ5yMU7NwB1Gq/Dr6wvHpz0Qhib8kBKroYAnHDoEM++KM9UioIhDI=
X-Received: by 2002:a17:906:912:: with SMTP id i18mr91734970ejd.131.1636318341524; Sun, 07 Nov 2021 12:52:21 -0800 (PST)
MIME-Version: 1.0
References: <CA+RyBmWrGcBDMsjd_2nPsLLHH=zeEnFAvRMbuC4rE-5LV0Az+g@mail.gmail.com> <af74e3ada6cf46e19d5d06e97298f3b6@huawei.com> <CA+RyBmVdupDPHABjS63K+cR-MJ0mgat+a_xbQuk74wUTR8e0Dg@mail.gmail.com> <a2a61c9ed8c548f4b908e842662530ee@huawei.com> <CA+RyBmVSj4PzZxgMkcruG_y=kxzHOEZ1aqEgecG-exixEFtuhg@mail.gmail.com> <c720cd4e91e345eca60ac2da63c690b8@huawei.com>
In-Reply-To: <c720cd4e91e345eca60ac2da63c690b8@huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sun, 07 Nov 2021 12:52:10 -0800
Message-ID: <CA+RyBmUhz_9XaQfyr4Syp9RbK-x-nHZnzua8M7dn2STUU3joVw@mail.gmail.com>
To: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
Cc: "draft-ietf-idr-bgp-ls-sbfd-extensions@ietf.org" <draft-ietf-idr-bgp-ls-sbfd-extensions@ietf.org>, BESS <bess@ietf.org>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007c70c605d0390d14"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/iS2jMQ-fYwprMJL9ZS4ChysEPJk>
Subject: Re: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Nov 2021 20:52:35 -0000

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) <
rainsword.wang@huawei.com> wrote:

> Hi Greg,
>
>
>
> Thanks for your comments. Please see my answers below under the [Habio]
> tag.
>
>
>
> Regards,
>
> Haibo
>
> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com]
> *Sent:* Saturday, November 6, 2021 1:03 AM
> *To:* Wanghaibo (Rainsword) <rainsword.wang@huawei.com>
> *Cc:* draft-ietf-idr-bgp-ls-sbfd-extensions@ietf.org; BESS <bess@ietf.org>;
> idr wg <idr@ietf.org>
> *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) <
> rainsword.wang@huawei.com> 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.
>
>
>
> [Haibo] Thanks for your suggestion, and we'll make this part clearer.
>
> 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.
>
> [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.

> 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?
>
> [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.

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

> Regrads,
>
> Haibo
>
> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com]
> *Sent:* Wednesday, November 3, 2021 10:15 AM
> *To:* Wanghaibo (Rainsword) <rainsword.wang@huawei.com>
> *Cc:* draft-ietf-idr-bgp-ls-sbfd-extensions@ietf.org; BESS <bess@ietf.org>;
> idr wg <idr@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.wang@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-bounces@ietf.org] *On Behalf Of *Greg Mirsky
> *Sent:* Friday, October 29, 2021 3:54 AM
> *To:* draft-ietf-idr-bgp-ls-sbfd-extensions@ietf.org; BESS <bess@ietf.org>;
> idr wg <idr@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
>
>