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

Greg Mirsky <gregimirsky@gmail.com> Wed, 03 November 2021 02:14 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 A8CEB3A09D0; Tue, 2 Nov 2021 19:14:59 -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 8LYKAVCZxkAB; Tue, 2 Nov 2021 19:14:55 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 CE8983A09CF; Tue, 2 Nov 2021 19:14:54 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id ee33so3858081edb.8; Tue, 02 Nov 2021 19:14:54 -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=Kb4EHjE8A4zEo/5I+YZahw4LnsOd4BT2nzLixrfzSwM=; b=ZKniPE1n2F0FfCjEyTJIv3CMK5LijSWzS3y/ODG7C+sxDxYA0gmboC4JdtMPh4sZP/ UzoJRsJvCp07zKZjkj+ucIzQOHFapSed6HdXSKoJByejcZkhGl9TNkEvPLbhOf6+yF/s eJh2BGDn6W5/aVJvbc/QpnDZWTorW+gIt3gb6gvGM9oNE0GluG/N3nP+PFXa6CgJByeC F7d1K59gWBYB7Iw2Gtzaejg+f5nVVr0By/0uZ3/viy4fIeVBg8b95HABZHNCbZyBv7iC lRR7Bnf62eBHuJtQAtIK1BWqYURSenxGP6q26M6WewgYazggQd/wA7GyAHtiIyLZgK9x Agog==
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=Kb4EHjE8A4zEo/5I+YZahw4LnsOd4BT2nzLixrfzSwM=; b=wMpYzCqkQqrPSJU/FhaNodUgiU+/9eKs0yS8dVGqhAv/j/8PA4+zAtRr6FCFYBoJQz UMZBwVCcuWt/TKtDGbU0QcekSfjsJYp72xHRIVJc02EjxrM9GFOX1n9XqkQey5ViYj2a xO/oGs3iWmrrIHX9ujQY6KY7KCv5wLG1WuhmA1eQkKAk6D5XJ3krK94yM6lZYvM9JY/E kA3Ksh3sJijN/AT5+8tIjujxoERLXgvLulaqbjAGFxLwlYTgJP6vuAq91Kcy1YLr5vPT M3mdgNHOB94isgMyhLxcxXuWcsEVYrLfVq8D5SmcKd2E6P1yOGyf0PkrXHLXTunRWigH 9IvA==
X-Gm-Message-State: AOAM531WCJIzYRsxSHSiC7r7v23/crSBxx/gIYw/TE+gIZDIxRawdUno 474+6iEcYygxiASIePRgstq/DTWvQ1wPuMyctM3dTQ80eNc=
X-Google-Smtp-Source: ABdhPJwJEvNBGl+ZEdwpQnQuCOzjP5kfWFQ0h4KlSO4phw0FsxQBKdFbd6hAbfDGNUsu6Yi1sLXNigR/7o6GKaf7h+8=
X-Received: by 2002:a05:6402:40cf:: with SMTP id z15mr55363559edb.138.1635905692554; Tue, 02 Nov 2021 19:14:52 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmWrGcBDMsjd_2nPsLLHH=zeEnFAvRMbuC4rE-5LV0Az+g@mail.gmail.com> <af74e3ada6cf46e19d5d06e97298f3b6@huawei.com>
In-Reply-To: <af74e3ada6cf46e19d5d06e97298f3b6@huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 02 Nov 2021 19:14:41 -0700
Message-ID: <CA+RyBmVdupDPHABjS63K+cR-MJ0mgat+a_xbQuk74wUTR8e0Dg@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="000000000000b0d98d05cfd8f974"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/9KA5YKCcZPZInnmIpGJ66PYTzfI>
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: Wed, 03 Nov 2021 02:15:00 -0000

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