IETF Logo Mail Archive

[Idr] Re: CHRE: Re: draft-decraene-idr-nlri-error-handling-00.txt

Jeffrey Haas <jhaas@pfrc.org> Tue, 21 October 2025 17:34 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: idr@mail2.ietf.org
Delivered-To: idr@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 4E27879B0471; Tue, 21 Oct 2025 10:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OELMppQpjhcO; Tue, 21 Oct 2025 10:34:09 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by mail2.ietf.org (Postfix) with ESMTP id 885A279B034D; Tue, 21 Oct 2025 10:33:20 -0700 (PDT)
Received: from smtpclient.apple (99-188-202-8.lightspeed.livnmi.sbcglobal.net [99.188.202.8]) by slice.pfrc.org (Postfix) with ESMTPSA id B3D3A1E24F; Tue, 21 Oct 2025 13:33:13 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7B2BBB25-6D36-4561-A91E-824F64F093AB"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <MR1P264MB4354FD25563FC91CCFB0AB26F0F2A@MR1P264MB4354.FRAP264.PROD.OUTLOOK.COM>
Date: Tue, 21 Oct 2025 13:33:13 -0400
Message-Id: <B2AAC8AC-B18A-4F39-9C1A-BD70DF2BF4AE@pfrc.org>
References: <176053803383.1109285.4613858825382469856@dt-datatracker-84f8f646b-tg6mn> <MR1P264MB4354CE655479696D589F8050F0E8A@MR1P264MB4354.FRAP264.PROD.OUTLOOK.COM> <CAPF+HwVb_Mb9C79SfVtTP=rxMjNK8CTEKOAFsXbx__8FwJ+RLw@mail.gmail.com> <AB42F105-6FD2-40C6-88DB-FDD33EF8A9BA@juniper.net> <CAPF+HwX_D5_Y88MQrerY+bPRY_V4QB=LG7nZY75skzntfT0G2g@mail.gmail.com> <F93E64FE-DE2C-47C6-B69F-267A69503140@juniper.net> <CAPF+HwX9VVNk26E-6NFphy-FV6vtyDkVBFQNPdghGw4yJCudfw@mail.gmail.com> <5656EE4B-764B-46EF-BE6A-7D2E657DDA6F@juniper.net> <CAOj+MMFT3qOENbcJ5Ctp9PQxhsrgzPM852_sOZTUWq83kZqZ6g@mail.gmail.com> <MR1P264MB4354DE951D947A766EDBFE8FF0F6A@MR1P264MB4354.FRAP264.PROD.OUTLOOK.COM> <CAOj+MMGypHqRt5OHWW62P-_PEiGhAJ0DHNA33WNT2ZwUoN5-tg@mail.gmail.com> <MR1P264MB4354ECB1758B24F266A622ECF0F5A@MR1P264MB4354.FRAP264.PROD.OUTLOOK.COM> <CAOj+MMH1UaNQrVmJ5y_ACoJZU-+MT6_BF8R3PvUXK_474ub5jQ@mail.gmail.com> <MR1P264MB435468CB62F71469C07A05C1F0F2A@MR1P264MB4354.FRAP264.PROD.OUTLOOK.COM> <CAOj+MMFRtRqaRLM2LeN91MESju0_fsCTwTM=Q8NOVcjpqarZbg@mail.gmail.com> <MR1P264MB4354FD25563FC91CCFB0AB26F0F2A@MR1P264MB4354.FRAP264.PROD.OUTLOOK.COM>
To: Bruno Decraene <bruno.decraene@orange.com>
X-Mailer: Apple Mail (2.3696.120.41.1.10)
Message-ID-Hash: U42NKOCG7IHJ3EKVNYHDNVDS6ZVFYLPO
X-Message-ID-Hash: U42NKOCG7IHJ3EKVNYHDNVDS6ZVFYLPO
X-MailFrom: jhaas@pfrc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Robert Raszuk <robert@raszuk.net>, idr <idr@ietf.org>, "draft-decraene-idr-nlri-error-handling@ietf.org" <draft-decraene-idr-nlri-error-handling@ietf.org>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Idr] Re: CHRE: Re: draft-decraene-idr-nlri-error-handling-00.txt
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/o0zPMJW2e1eAoKIZbF4dLg3MIc4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

For key, we all know what it probably means, but we have no formalism for it.

We should discuss fixing that in 4271-bis.



> On Oct 21, 2025, at 12:30 PM, bruno.decraene@orange.com wrote:
> > “The NLRI key is the part of the NLRI which is used to identify and distinguish between each individual route in the BGP RIB”
>  
> That to me seems way too broad and very much implementation dependent. 
>  
> I’m open to other suggestions.
> But I don’t see how this could be implementation dependent because this defines whether the NLRI-key advertised in MP_REACH_NLRI (resp.  MP_UNREACH_NLRI) updates (resp. withdraw) a previously announced route in the RIB.

The one place this had slight ambiguity is when a withdraw may summarily withdraw multiple things simultaneously.  This was previously the case for RFC 3107, §4 multiple routes to a destination, but as RFC 8277 clarified "no one does that".

I think it's currently the case that no BGP NLRI can be advertised with multiple paths with one key and can be removed as a group with another key.

-- Jeff

v2.46.0 | Report a Bug | By Email | System Status