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

Zhuangshunwan <zhuangshunwan@huawei.com> Mon, 31 July 2023 11:25 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 85860C14CE42 for <lsvr@ietfa.amsl.com>; Mon, 31 Jul 2023 04:25:57 -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=ham 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 hGVYqivmRWQ5 for <lsvr@ietfa.amsl.com>; Mon, 31 Jul 2023 04:25:53 -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 7E086C14CE38 for <lsvr@ietf.org>; Mon, 31 Jul 2023 04:25:53 -0700 (PDT)
Received: from lhrpeml100004.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4RDwnL3TrPz6J7Tw for <lsvr@ietf.org>; Mon, 31 Jul 2023 19:22:14 +0800 (CST)
Received: from kwepemi100003.china.huawei.com (7.221.188.122) by lhrpeml100004.china.huawei.com (7.191.162.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Mon, 31 Jul 2023 12:25:49 +0100
Received: from kwepemi500002.china.huawei.com (7.221.188.171) by kwepemi100003.china.huawei.com (7.221.188.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Mon, 31 Jul 2023 19:25:47 +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; Mon, 31 Jul 2023 19:25:47 +0800
From: Zhuangshunwan <zhuangshunwan@huawei.com>
To: "lsvr@ietf.org" <lsvr@ietf.org>
Thread-Topic: Mail regarding draft-ietf-lsvr-bgp-spf
Thread-Index: AdnDn+sV+9ahMBi7RcKvS1IfTwHI4Q==
Date: Mon, 31 Jul 2023 11:25:47 +0000
Message-ID: <e986cdf58d654a80a69425c7398e927e@huawei.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_e986cdf58d654a80a69425c7398e927ehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/YCZB9jd_ijMl6spBSqI8eet_-Ts>
Subject: [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: Mon, 31 Jul 2023 11:25:57 -0000

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?

Thanks,
Shunwan