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

"Wanghaibo (Rainsword)" <rainsword.wang@huawei.com> Fri, 29 October 2021 02:24 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 5B97D3A0972; Thu, 28 Oct 2021 19:24:50 -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 Vthh5_1lhzCF; Thu, 28 Oct 2021 19:24:46 -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 AE3A43A0971; Thu, 28 Oct 2021 19:24:45 -0700 (PDT)
Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HgR3W1Bbsz67LpM; Fri, 29 Oct 2021 10:20:23 +0800 (CST)
Received: from kwepeml500004.china.huawei.com (7.221.188.141) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 29 Oct 2021 04:24:37 +0200
Received: from kwepeml500001.china.huawei.com (7.221.188.162) by kwepeml500004.china.huawei.com (7.221.188.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 29 Oct 2021 10:24:35 +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, 29 Oct 2021 10:24:35 +0800
From: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>, "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: AQHXzDWwgpZ4kp3dJ0mGk2p05qYhKavpOg1Q
Date: Fri, 29 Oct 2021 02:24:35 +0000
Message-ID: <af74e3ada6cf46e19d5d06e97298f3b6@huawei.com>
References: <CA+RyBmWrGcBDMsjd_2nPsLLHH=zeEnFAvRMbuC4rE-5LV0Az+g@mail.gmail.com>
In-Reply-To: <CA+RyBmWrGcBDMsjd_2nPsLLHH=zeEnFAvRMbuC4rE-5LV0Az+g@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_af74e3ada6cf46e19d5d06e97298f3b6huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/3gvBmo3POox-LzjE-igy3hoATek>
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, 29 Oct 2021 02:24:51 -0000

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