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

"Wanghaibo (Rainsword)" <rainsword.wang@huawei.com> Fri, 05 November 2021 08:22 UTC

Return-Path: <rainsword.wang@huawei.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 8F6AB3A0D7D; Fri, 5 Nov 2021 01:22:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 pxFrJwjbDeue; Fri, 5 Nov 2021 01:22:50 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395AE3A0D7B; Fri, 5 Nov 2021 01:22:50 -0700 (PDT)
Received: from fraeml741-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HltmM3hFrz680Ml; Fri, 5 Nov 2021 16:22:43 +0800 (CST)
Received: from kwepeml100005.china.huawei.com (7.221.188.221) by fraeml741-chm.china.huawei.com (10.206.15.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 5 Nov 2021 09:22:46 +0100
Received: from kwepeml500001.china.huawei.com (7.221.188.162) by kwepeml100005.china.huawei.com (7.221.188.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 5 Nov 2021 16:22:44 +0800
Received: from kwepeml500001.china.huawei.com ([7.221.188.162]) by kwepeml500001.china.huawei.com ([7.221.188.162]) with mapi id 15.01.2308.015; Fri, 5 Nov 2021 16:22:44 +0800
From: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.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>
Thread-Topic: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator
Thread-Index: AQHXzDWwgpZ4kp3dJ0mGk2p05qYhKavpOg1QgAdYiYCABAVpoA==
Date: Fri, 05 Nov 2021 08:22:44 +0000
Message-ID: <a2a61c9ed8c548f4b908e842662530ee@huawei.com>
References: <CA+RyBmWrGcBDMsjd_2nPsLLHH=zeEnFAvRMbuC4rE-5LV0Az+g@mail.gmail.com> <af74e3ada6cf46e19d5d06e97298f3b6@huawei.com> <CA+RyBmVdupDPHABjS63K+cR-MJ0mgat+a_xbQuk74wUTR8e0Dg@mail.gmail.com>
In-Reply-To: <CA+RyBmVdupDPHABjS63K+cR-MJ0mgat+a_xbQuk74wUTR8e0Dg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.153.118]
Content-Type: multipart/alternative; boundary="_000_a2a61c9ed8c548f4b908e842662530eehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/X79IYqJrM5VBmMNN-gl5dUqr2J4>
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 08:22:56 -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: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<mailto: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<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<mailto:draft-ietf-idr-bgp-ls-sbfd-extensions@ietf.org>; BESS <bess@ietf.org<mailto:bess@ietf.org>>; idr wg <idr@ietf.org<mailto: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