Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf

Zhuangshunwan <zhuangshunwan@huawei.com> Tue, 01 August 2023 08:46 UTC

Return-Path: <zhuangshunwan@huawei.com>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381DAC151992 for <lsvr@ietfa.amsl.com>; Tue, 1 Aug 2023 01:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.904
X-Spam-Level:
X-Spam-Status: No, score=-6.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkY2XxM4Dhkc for <lsvr@ietfa.amsl.com>; Tue, 1 Aug 2023 01:46:45 -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 6C5B0C15107F for <lsvr@ietf.org>; Tue, 1 Aug 2023 01:46:45 -0700 (PDT)
Received: from lhrpeml100003.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4RFTCg0ZG8z6J70d for <lsvr@ietf.org>; Tue, 1 Aug 2023 16:43:27 +0800 (CST)
Received: from kwepemi500003.china.huawei.com (7.221.188.51) by lhrpeml100003.china.huawei.com (7.191.160.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Tue, 1 Aug 2023 09:46:41 +0100
Received: from kwepemi500002.china.huawei.com (7.221.188.171) by kwepemi500003.china.huawei.com (7.221.188.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Tue, 1 Aug 2023 16:46:39 +0800
Received: from kwepemi500002.china.huawei.com ([7.221.188.171]) by kwepemi500002.china.huawei.com ([7.221.188.171]) with mapi id 15.01.2507.027; Tue, 1 Aug 2023 16:46:39 +0800
From: Zhuangshunwan <zhuangshunwan@huawei.com>
To: Acee Lindem <acee.ietf@gmail.com>
CC: Zhuangshunwan <zhuangshunwan=40huawei.com@dmarc.ietf.org>, "lsvr@ietf.org" <lsvr@ietf.org>
Thread-Topic: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
Thread-Index: AQHZxArQ8GmiA0t3WEyH87hIEld++K/VHSrg
Date: Tue, 01 Aug 2023 08:46:39 +0000
Message-ID: <d8439266a0a34085b400f3c2bd8724fa@huawei.com>
References: <e986cdf58d654a80a69425c7398e927e@huawei.com> <DA3B2F30-55BF-4E33-8E7F-D17178AC22C5@gmail.com> <ea29c72b6d4f445f8d442690006ad874@huawei.com> <56C350BB-B00B-4F64-B8C1-2387055E99C7@gmail.com>
In-Reply-To: <56C350BB-B00B-4F64-B8C1-2387055E99C7@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.202.95]
Content-Type: multipart/alternative; boundary="_000_d8439266a0a34085b400f3c2bd8724fahuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/ndL2bbz7Qq0j5BIzuRZbYv7BiRI>
Subject: Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Aug 2023 08:46:48 -0000

Hi Acee,

I can understand the situation. I think the text in the current draft is also good.
I think this may be a check point for a future XXIE certification☺

Thanks,
Shunwan

From: Acee Lindem [mailto:acee.ietf@gmail.com]
Sent: Tuesday, August 1, 2023 7:57 AM
To: Zhuangshunwan <zhuangshunwan@huawei.com>
Cc: Zhuangshunwan <zhuangshunwan=40huawei.com@dmarc.ietf.org>; lsvr@ietf.org
Subject: Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf




On Jul 31, 2023, at 08:16, Zhuangshunwan <zhuangshunwan@huawei.com<mailto:zhuangshunwan@huawei.com>> wrote:

Hi Acee,

Thank you for your quick response. Yes, I understand that in BGP SPF, the traditional BGP decision process has been completely replaced.

Regarding the rule “3.  The NLRI received from the BGP SPF speaker with the numerically larger BGP Identifier is preferred.”, I think “the BGP SPF speaker with the numerically lower BGP Identifier is preferred” would also work well. And this is somewhat easy to understand, because RFC 4271 already has such an accepted rule.

We could have changed this a couple years ago but I don’t think that we want to change this now that we have implementations. Since we’ve replaced entire decision process, using the same tie-breaker doesn’t seem necessary.

Thanks,
Acee




Thanks,
Shunwan

From: Lsvr [mailto:lsvr-bounces@ietf.org] On Behalf Of Acee Lindem
Sent: Monday, July 31, 2023 7:35 PM
To: Zhuangshunwan <zhuangshunwan=40huawei.com@dmarc.ietf.org<mailto:zhuangshunwan=40huawei.com@dmarc.ietf.org>>
Cc: lsvr@ietf.org<mailto:lsvr@ietf.org>
Subject: Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf

Hi Shuwan,



On Jul 31, 2023, at 07:25, Zhuangshunwan <zhuangshunwan=40huawei.com@dmarc.ietf.org<mailto:zhuangshunwan=40huawei.com@dmarc.ietf.org>> wrote:

Hi Authors,

Thank you for contributing this useful document!

I think I missed some of the discussion information. I saw the following rule and was puzzled:

https://datatracker.ietf.org/doc/draft-ietf-lsvr-bgp-spf/
6.1.  BGP SPF NLRI Selection
…
3.  The NLRI received from the BGP SPF speaker with the numerically
       larger BGP Identifier is preferred.
…

The above rule is contrary to the definition of RFC 4271. RFC 4271 defines the following:
“
9.1.2.2.  Breaking Ties (Phase 2)
…
f) Remove from consideration all routes other than the route that
         was advertised by the BGP speaker with the lowest BGP
         Identifier value.
”

My question is: why are the two rules not defined as the same style?

In BGP SPF, the traditional BGP decision process is completely replaced.

Thanks,
Acee





Thanks,
Shunwan
_______________________________________________
Lsvr mailing list
Lsvr@ietf.org<mailto:Lsvr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsvr