IETF Logo Mail Archive

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

Acee Lindem <acee.ietf@gmail.com> Mon, 31 July 2023 23:57 UTC

Return-Path: <acee.ietf@gmail.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 5B124C14CE27 for <lsvr@ietfa.amsl.com>; Mon, 31 Jul 2023 16:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 l2E0BW2T178U for <lsvr@ietfa.amsl.com>; Mon, 31 Jul 2023 16:57:33 -0700 (PDT)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A992C151090 for <lsvr@ietf.org>; Mon, 31 Jul 2023 16:57:33 -0700 (PDT)
Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-63cf9eddbc6so29125046d6.0 for <lsvr@ietf.org>; Mon, 31 Jul 2023 16:57:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690847852; x=1691452652; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=4NQ1jSviuLXMvPIKwIVvtbH4oEsE5NXKiGc+hiPB544=; b=SQWxGe2Gk5OIGREgP4K7eMK59KEAgVFOIWwZ14z0RT/x+SojkwYN4YxTzQmwHybSZ1 Bvudpym3I1feUD07z5NqmcsSWtEQFGr828/2OVDP9vOr1Hnxy9EIyFGDKgGM+GCJ751W b5bwMNDoxXTP1FangSLSGI+LKcxwEJt70FuAbs1wOERKX3kJoV/9ue1MQFFrYB49oM4Q XsU4BlJQoOLeNiFl0agym0qZy7sFW8nNVdaEe5Ao6GSurXPGq7QFtbbGg4q55QtyejQ9 b9zdL9K11k74ijfx8nYvlBjXuDFjNFSbAQHrYs7yA5F75vH+9UQ71wQo2mifR/1QdpXf J9wQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690847852; x=1691452652; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4NQ1jSviuLXMvPIKwIVvtbH4oEsE5NXKiGc+hiPB544=; b=bliYWoQ6ATtR8xNOxZvmtS7ZL4BDTjBSLn/uHyM9WBniAp4fbyEWdZ2TTgHebQNUM3 lgNNGb+vpvTWLrmZEKDb8wBVzKXlPq2ZNgFAu4mOcvGa0yDPjR0M+BV6BRwAfvKl9g0U GHgziWq/NG6MhtLHFgaRv/qZJ+jl2iFaVtX7NTEUNgd96cJs0RSlcNMHtuvMShkW51Ot QsnLtvo3owg6ifIpzykxmLn0pdl62P2uroUjABtNLc5YE9dPEQpWIxLWZej6/5Kqpmch 6537KYjhdKypeebx8TUsn2ZOmLrCC201g483J9o+LZHYPcqbhuvVUxSyEDohcbrXtgpq ETug==
X-Gm-Message-State: ABy/qLZDdP8yBtDKNX8o4GqsytqQkBIbVwsvtUF+QDK+v2/R22zIy5aQ tstMuM/7Yhtpbc9PV+wtTPk=
X-Google-Smtp-Source: APBJJlG/6TdyLLrBk+2Z/lfc6L/7iN++euWGo7O2i3tsizAMm7Fy7exJETbbCbUFJXaMkEEhMa8tZg==
X-Received: by 2002:a0c:e40d:0:b0:63d:e7:470c with SMTP id o13-20020a0ce40d000000b0063d00e7470cmr14842636qvl.19.1690847852142; Mon, 31 Jul 2023 16:57:32 -0700 (PDT)
Received: from smtpclient.apple ([2605:a601:91bc:d800:d95c:34b3:e123:1792]) by smtp.gmail.com with ESMTPSA id n16-20020a0ce550000000b0063d585225e0sm2583509qvm.61.2023.07.31.16.57.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2023 16:57:31 -0700 (PDT)
From: Acee Lindem <acee.ietf@gmail.com>
Message-Id: <56C350BB-B00B-4F64-B8C1-2387055E99C7@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3BA623B5-259D-4EFF-B684-25F8AEE89935"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Mon, 31 Jul 2023 19:57:21 -0400
In-Reply-To: <ea29c72b6d4f445f8d442690006ad874@huawei.com>
Cc: Zhuangshunwan <zhuangshunwan=40huawei.com@dmarc.ietf.org>, "lsvr@ietf.org" <lsvr@ietf.org>
To: Zhuangshunwan <zhuangshunwan@huawei.com>
References: <e986cdf58d654a80a69425c7398e927e@huawei.com> <DA3B2F30-55BF-4E33-8E7F-D17178AC22C5@gmail.com> <ea29c72b6d4f445f8d442690006ad874@huawei.com>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/4x3LWjUqUPnEIWyzksBdbkIENBw>
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 23:57:37 -0000


> On Jul 31, 2023, at 08:16, Zhuangshunwan <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>
> 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

v2.23.0 | Report a Bug | By Email