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

Greg Mirsky <gregimirsky@gmail.com> Fri, 05 November 2021 17:03 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 EDBD23A1285; Fri, 5 Nov 2021 10:03:07 -0700 (PDT)
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 EPr94Mrm4VPc; Fri, 5 Nov 2021 10:03:03 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 14BAA3A1255; Fri, 5 Nov 2021 10:03:02 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id x15so4070961edv.1; Fri, 05 Nov 2021 10:03:01 -0700 (PDT)
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=8Bzvyi8a4IC8XT6Ir6bhCUhTDGqkyH7l41Ypd1FZfPo=; b=Bn62mCjE/hvTJgTAMW2izCcxT+sRX1sBW37izFe+zwxGYhuwfBstuelQSHiOTvgkHA ttJl0bpJUxNwj11lA3H2udNwQCs03GY4rLTcKZ6Q9mFJhqXV8w+CCSSVfdS/Q56SsLfb Vx/FAhKyXgL81BnlCFPDkyJ/YaZKtiBFUqwGjfTLW47x0zi8UYhzxC0rC8xffX8U4N5q PmXGL9S3QeNMZGbqaS1Y4xME+98d63NfU5VBlxV++r9IvH3/0EmPkg4zkIpHT/6q6mMO VJ5/oa0nKZS1+2MQSdL7RhkmlnzxGRrVFzTEe8U2FIAtGKIxDqVdHj4V94hgjFDcIcZr cyNQ==
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=8Bzvyi8a4IC8XT6Ir6bhCUhTDGqkyH7l41Ypd1FZfPo=; b=TFzIq2PE52cntSX/WkzSR4qVedmoUSwlOKrgCH7IHBDHS13ZhHONEprRY9KSnw/1GH UviziQs2YNkzSn3+0okY3/IbOqBTkV1ZIuudhTtTkZ7CMtd75d15jU26EojXudylkRNM Zx4gcO0dDTQkEepH+zeZguTw0LuYuMWYrmyJEWcwl33X0bse65ZFzQBnEpUIyWi0Ek42 iTMqKY07VfbSH+pwIDA8+0ypSdiMINb9pRVjSMwauXtVA2cHlUxI2RJX5P9i7PH5mPX3 gwKBv4BqIqCGfv/UVIFgEQkqgLDPpyz8lEQk4GLRPlEukTe0VjUe9+mN0xiRP17fRNCC rzCA==
X-Gm-Message-State: AOAM530bqzl46b7DIE4dsnLs4wn9EcYz8OU22hi0nuaT0uYz68v/GgcM Xzr5SSorEs/1EFFFy09X0JEpSDZB94Hz3tFI+m8QcWy/
X-Google-Smtp-Source: ABdhPJxTRujKA5KR4bQLEL98itf7S1hfrdRw97oYkDuIeBXBjq5b5YaYyaro8Y8R8GnzgePFcNLwY01abIqlbc0xVF8=
X-Received: by 2002:a17:906:1457:: with SMTP id q23mr8465726ejc.561.1636131779022; Fri, 05 Nov 2021 10:02:59 -0700 (PDT)
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>
In-Reply-To: <a2a61c9ed8c548f4b908e842662530ee@huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 05 Nov 2021 10:02:47 -0700
Message-ID: <CA+RyBmVSj4PzZxgMkcruG_y=kxzHOEZ1aqEgecG-exixEFtuhg@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="0000000000007e92fd05d00d9d54"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/tOsvpvNq2GfIyqnVbZoDByu9-rI>
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: Fri, 05 Nov 2021 17:03:14 -0000

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.

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