Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
Zhuangshunwan <zhuangshunwan@huawei.com> Mon, 31 July 2023 12:16 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 44652C14CF1D for <lsvr@ietfa.amsl.com>; Mon, 31 Jul 2023 05:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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_BLOCKED=0.001, 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 HbCoHzBgJfYY for <lsvr@ietfa.amsl.com>; Mon, 31 Jul 2023 05:16:36 -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 887D2C14F736 for <lsvr@ietf.org>; Mon, 31 Jul 2023 05:16:35 -0700 (PDT)
Received: from lhrpeml500006.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4RDxvq6JHzz67LSb for <lsvr@ietf.org>; Mon, 31 Jul 2023 20:12:55 +0800 (CST)
Received: from kwepemi500001.china.huawei.com (7.221.188.114) by lhrpeml500006.china.huawei.com (7.191.161.198) 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 13:16:30 +0100
Received: from kwepemi500002.china.huawei.com (7.221.188.171) by kwepemi500001.china.huawei.com (7.221.188.114) 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 20:16:28 +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 20:16:28 +0800
From: Zhuangshunwan <zhuangshunwan@huawei.com>
To: Acee Lindem <acee.ietf@gmail.com>, Zhuangshunwan <zhuangshunwan=40huawei.com@dmarc.ietf.org>
CC: "lsvr@ietf.org" <lsvr@ietf.org>
Thread-Topic: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
Thread-Index: AQHZw6Moi+qeqt89x0ypCorslsW9hK/TxlLQ
Date: Mon, 31 Jul 2023 12:16:28 +0000
Message-ID: <ea29c72b6d4f445f8d442690006ad874@huawei.com>
References: <e986cdf58d654a80a69425c7398e927e@huawei.com> <DA3B2F30-55BF-4E33-8E7F-D17178AC22C5@gmail.com>
In-Reply-To: <DA3B2F30-55BF-4E33-8E7F-D17178AC22C5@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_ea29c72b6d4f445f8d442690006ad874huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/hcBbqX1P3dQ-FQzBm_sA5CsEnio>
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: Mon, 31 Jul 2023 12:16:40 -0000
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. 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> Cc: 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
- [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf Zhuangshunwan
- Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf Acee Lindem
- Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf Zhuangshunwan
- Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf Acee Lindem
- Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf Zhuangshunwan