Return-Path: 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 75B228AEFD3C for ; Mon, 17 Nov 2025 05:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net 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 W32M1D1PwPqa for ; Mon, 17 Nov 2025 05:42:45 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id AE9EB8AEFD29 for ; Mon, 17 Nov 2025 05:42:45 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-641677916b5so7785756a12.0 for ; Mon, 17 Nov 2025 05:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1763386964; x=1763991764; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=upKsdOnHpYVRbZGRiD06hT7c1VezdtyuCPpjLOkI+uw=; b=CUbFBzltrZXqJ+ovsvrs/8XdrNiRN2GdgckA3o3AD7aiRLSNSk40yPADOJBpDR77Wg Qua2W4bYSI7WM4MyWVtlut0wi9ebEfgiw20Fl4q+vJsbDwNo6Z56AORA67bPfBQUTaMh 3LSgnLyxJgn4+Klduoqi63JDpriKgS7RruTFHCkuwlykBNAipW2eRuSf4w6XuKsPO69o MxEh0cx2XmyxaeA5nAQERcQBs9aIE+4iKBfOe14OgpkOjvs4LERYv6vIG56h7vPeQ72W QNagKTjeE+PMzMkM6Zw+xBnVldE5DVkGcwNEMerdzpWKy44BG1JIHPYGgnl4nBqVopgV B1hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763386964; x=1763991764; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=upKsdOnHpYVRbZGRiD06hT7c1VezdtyuCPpjLOkI+uw=; b=pNA1YZb8sO0MGCriv7d4B/uGzAQ95IysP5t/6xl8D1tdT9r5FoRm/LJnwUIaZWzolA U8xaRro+nHS29hD0BR3RKZZXOOxV9nf3Y9bCH/bW/Iinyt+GudXMGOxA7nQXcnBzbwy5 AVp7NmhcrsBnlfc5sfzeAqd7OwPlK4SdaztIg2iyrNI7kKYfC3b8gVbiTsXeL9uN+Pr/ QsuOREzFTHj7zumofsY8/V4wCcj34QXi1StTOGSJcNDbrzxhIfdHyXIz28rg1hOFMz1A N9aNm0vvDsxT1/uGw9Jvf0/5+M2vD4V8kJKfXhZKcTfIsnnqwsHAk/nKU8krNca/eHmW Aqag== X-Forwarded-Encrypted: i=1; AJvYcCWKMwklwq8Jkx/Ww3eJ4c+pIJSKJNS8IM2kltevJnkmgWJtoDuO9Xx9nkTNpthujoXjGkQ=@ietf.org X-Gm-Message-State: AOJu0YyE7zmR1fqe+q5BwS3hde60Kqkh2c1kVhPzUusIwWdr6sHi6zUK xKabSrsQIEg3RWxgA5pZgQuIufTKkGUsY6I6Fh00BCGS2RLmSQJ5XvsLJnDkx8sxhpa/pHYe9iz qvKHNv7VbrYpC+iCdJE4RYic7SnZJtsAtYxAewWgM9gLUcutFrCyi X-Gm-Gg: ASbGnctYKqI8xlANK9Y4QRVYy14Q8G7yxlkWjhtoY3o3rqmwgFTmxabmOOSATvx6SpU KRk09B6J3LbXW4md63Qf69e9T72B1o8yH5px0n9xBAI+R5AVXNutGd98FkACyb/w0fKa+ppIRlv CPJbDlDovSkyOh/WcxhyKs/sdYsU7G/9gAkxLD6GO9jjJQ0WbZS9Ta6aagnDi7uqlicpDSLJha3 Mtn4DIBo2uVDtOLZnuP3yoNL7J4coMpEcw5/pFhaLR5Ab3gjOTlUpxqtlV1Sqx63+SBmtGBIRLt bnQaO44= X-Google-Smtp-Source: AGHT+IFLNVIMNxXCPtO5B1d6JBs8jsRh06+WJgQ+CicvyMSkSF1J6hesm4MZ3Ci7VEiM729ppGhqir9JMOd/AfJ6NBM= X-Received: by 2002:a17:907:6d2a:b0:b50:a389:7aa4 with SMTP id a640c23a62f3a-b73677eea3bmr1307073866b.13.1763386964404; Mon, 17 Nov 2025 05:42:44 -0800 (PST) MIME-Version: 1.0 References: <176289545153.2257004.4439438509549182676@dt-datatracker-5df8666cb-7l4w5> In-Reply-To: From: Robert Raszuk Date: Mon, 17 Nov 2025 14:42:33 +0100 X-Gm-Features: AWmQ_bnTIJksuC-FgWPmZh7whc3MFnPD9oB0irpc6mbGfHRR3XoatxDWUy4pXEU Message-ID: To: Donatas Abraitis Content-Type: multipart/alternative; boundary="0000000000009d7e080643ca859a" Message-ID-Hash: FC2BY6ZPLOQZ4E3VRPN5QHEKP2X6CW44 X-Message-ID-Hash: FC2BY6ZPLOQZ4E3VRPN5QHEKP2X6CW44 X-MailFrom: robert@raszuk.net 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: "idr@ietf. org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BIdr=5D_Re=3A_draft-tantsura-idr-unreachability-safi-00=2Etxt?= List-Id: Inter-Domain Routing Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000009d7e080643ca859a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well I am not sure if we should be spending any more bandwidth on this topic but the fact that you dampen say /24 does not make it unreachable as it can be covered by less specific or default route. The above comment applies equally to all other reasons stated as "UNREACHABILITY CODES" ... On Mon, Nov 17, 2025 at 11:20=E2=80=AFAM Donatas Abraitis < donatas.abraitis@gmail.com> wrote: > Returning to "Unreachability Reason Code", I suggest adding also > "Dampening". > > On Wed, Nov 12, 2025 at 10:09=E2=80=AFPM Robert Raszuk wrote: > >> Hi Jeff, >> >> > Here we see the hazards of publishing a draft tagged with -idr. >> >> LOL !!! >> >> My first guess was that authors attempted to do UPA in BGP a bit >> differently than the original attempt as described >> in draft-krierhorn-idr-upa-01. >> >> But since in the current draft they are relying on RFC4760 yet not even >> defining attribute envelops for those NLRIs they are defining seems very >> hard to guess what this is all about. >> >> If they are indicating reasons like local policy, security filtering or >> rpki that can't be for intradomain/local consumption so it must be headi= ng >> outside of a domain. How far ... who knows ... perhaps as far as it gets >> :). >> >> Bottom line - it has been a while (if ever) to see such a proposal marke= d >> with -idr name ... >> >> Cheers >> Robert >> >> On Wed, Nov 12, 2025 at 8:30=E2=80=AFPM Jeffrey Haas wr= ote: >> >>> Here we see the hazards of publishing a draft tagged with -idr. The >>> poor authors haven't even had time to introduce the context. :-) >>> >>> While I broadly agree with the observations here and in subsequent >>> points from Donatas and Nan Geng, the point here overlapping the >>> operational message is the one I'd like to respond to. >>> >>> Some portion of the use cases covered in the draft are effectively a >>> form of "negative state attestation". In other words "you shouldn't ha= ve >>> this!" is the positive state. Certainly a large number of these use ca= ses >>> overlap the more general notification dissemination mechanism that the >>> operational message has. However, where the analogy breaks down a bit >>> (aside from a lack of standardized contents for such an operational >>> message) is apparent intention from the draft that this state should be >>> distributed throughout BGP. >>> >>> This more broadly is impacted by some BGP fundamentals. Namely, that >>> withdraws are a local matter for any number of reasons. The only one t= hat >>> is safe for any use cases for the draft is "this is completely gone fro= m >>> BGP". >>> >>> Everything else is local. And distributing positive state that "this >>> isn't here" on a different distribution graph than where the routes >>> themselves may not flow is problematic. >>> >>> It'll be interesting to hear more about the intended use cases. I have >>> a feeling that part of this is a desire for routing-distributed telemet= ry. >>> >>> -- Jeff >>> >>> > On Nov 11, 2025, at 4:57 PM, Robert Raszuk wrote: >>> > >>> > Hi, >>> > >>> > The proposal as written is just a form of a free floating idea. >>> > >>> > #1 - I would start first in providing a hook which would describe in >>> which BGP PATH ATTRIBUTE of the BGP UPDATE MSG you are going to carry t= hose >>> NLRIs ... MP-REACH-NLRI ? MP-UNREACH-NLRI ? NEW ONE ? >>> > >>> > #2 - Your justification for this work fully overlaps with already >>> existing IDR WG document: >>> > >>> https://www.ietf.org/archive/id/draft-ietf-idr-operational-message-00.t= xt >>> Please kindly explain what gain do you see to add what you have propose= d in >>> the draft to BGP UPDATE MSG ? >>> > >>> > #3 - Value: 86 (to be assigned by IANA) .. That would be squatting at >>> this point. Not good ! >>> > >>> > #4 - I am completely not following on your list of reasons: >>> > >>> > Type 2: Unreachability Reason Code >>> > >>> > * Length: 2 octets >>> > * Value: Detailed reason code (registry to be established) >>> > * 0: Unspecified >>> > * 1: Policy Blocked >>> > * 2: Security Filtered >>> > * 3: RPKI Invalid >>> > * 4-65535: Reserved for future use >>> > >>> > I assume you are still trying to announce your own prefix which becam= e >>> unreachable in your domain ... so what does it mean to announce it with= any >>> of the types like 1, 2 or 3 ? >>> > >>> > Or are you dreaming of any BGP speaker on the internet suddenly >>> broadcasting to anyone in the world that he failed to install a receive= d >>> BGP prefix due to one of those listed reasons ??? >>> > >>> > To me this proposal looks too raw for any consideration at this point= . >>> > >>> > Regards, >>> > Robert >>> > >>> > ---------- Forwarded message --------- >>> > From: >>> > Date: Tue, Nov 11, 2025 at 10:12=E2=80=AFPM >>> > Subject: I-D Action: draft-tantsura-idr-unreachability-safi-00.txt >>> > To: >>> > >>> > >>> > Internet-Draft draft-tantsura-idr-unreachability-safi-00.txt is now >>> available. >>> > >>> > Title: BGP Unreachability Information SAFI >>> > Authors: Jeff Tantsura >>> > Donald Sharp >>> > Vivek Venkatraman >>> > Karthikeya Venkat Muppalla >>> > Name: draft-tantsura-idr-unreachability-safi-00.txt >>> > Pages: 12 >>> > Dates: 2025-11-11 >>> > >>> > Abstract: >>> > >>> > This document defines a new BGP Subsequent Address Family Identifi= er >>> > (SAFI) called "Unreachability Information" that allows the >>> > propagation of prefix unreachability information through BGP witho= ut >>> > affecting the installation or removal of routes in the Routing >>> > Information Base (RIB) or Forwarding Information Base (FIB). This >>> > mechanism enables network operators to share information about >>> > unreachable prefixes for monitoring, debugging, and coordination >>> > purposes while maintaining complete separation from the active >>> > routing plane. >>> > >>> > The IETF datatracker status page for this Internet-Draft is: >>> > >>> https://datatracker.ietf.org/doc/draft-tantsura-idr-unreachability-safi= / >>> > >>> > There is also an HTML version available at: >>> > >>> https://www.ietf.org/archive/id/draft-tantsura-idr-unreachability-safi-= 00.html >>> > >>> > Internet-Drafts are also available by rsync at: >>> > rsync.ietf.org::internet-drafts >>> > >>> > >>> > _______________________________________________ >>> > I-D-Announce mailing list -- i-d-announce@ietf.org >>> > To unsubscribe send an email to i-d-announce-leave@ietf.org >>> > _______________________________________________ >>> > Idr mailing list -- idr@ietf.org >>> > To unsubscribe send an email to idr-leave@ietf.org >>> >>> _______________________________________________ >> Idr mailing list -- idr@ietf.org >> To unsubscribe send an email to idr-leave@ietf.org >> > > > -- > Donatas > --0000000000009d7e080643ca859a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Well I am not sure if we should be spending= any more bandwidth=C2=A0on this topic but the fact that you dampen say /24= does not make it unreachable as it can be covered by less specific or defa= ult route.=C2=A0

The above comment applies equally to al= l other reasons stated as "UNREACHABILITY CODES" ...=C2=A0
<= /div>
On Mon, Nov 17, 2025 at 11:20=E2=80=AFAM Donatas Abrai= tis <donatas.abraitis@gmai= l.com> wrote:
Returning to "Unreachability Reason Code", = I suggest adding also "Dampening".

On Wed, Nov 12, 2025 at 10:09= =E2=80=AFPM Robert Raszuk <robert@raszuk.net> wrote:
Hi Jeff,

&= gt; Here we see the hazards of publishing a draft tagged with -idr.=C2=A0

LOL !!!

My first guess was= that authors attempted to do UPA in BGP a bit differently than the origina= l attempt as described in=C2=A0draft-krierhorn-idr-upa-01.=C2=A0
=
But since in the current draft they are relying on RFC4760 y= et not even defining attribute envelops for those NLRIs they are defining s= eems very hard to guess what this is all about.=C2=A0

<= div>If they are indicating reasons like local policy, security filtering or= rpki that can't be for intradomain/local consumption=C2=A0so it must b= e heading outside of a domain. How far ... who knows ... perhaps as far as = it gets :).=C2=A0

Bottom line - it has been a whil= e (if ever) to see such a proposal marked with -idr name ...=C2=A0

Cheers
Robert

On Wed, Nov 12, 2025 at 8:30= =E2=80=AFPM Jeffrey Haas <jhaas@pfrc.org> wrote:
Here we see the hazards of publishing a draft tagged wi= th -idr.=C2=A0 The poor authors haven't even had time to introduce the = context. :-)

While I broadly agree with the observations here and in subsequent points f= rom Donatas and Nan Geng, the point here overlapping the operational messag= e is the one I'd like to respond to.

Some portion of the use cases covered in the draft are effectively a form o= f "negative state attestation".=C2=A0 In other words "you sh= ouldn't have this!" is the positive state.=C2=A0 Certainly a large= number of these use cases overlap the more general notification disseminat= ion mechanism that the operational message has.=C2=A0 However, where the an= alogy breaks down a bit (aside from a lack of standardized contents for suc= h an operational message) is apparent intention from the draft that this st= ate should be distributed throughout BGP.

This more broadly is impacted by some BGP fundamentals.=C2=A0 Namely, that = withdraws are a local matter for any number of reasons.=C2=A0 The only one = that is safe for any use cases for the draft is "this is completely go= ne from BGP".

Everything else is local.=C2=A0 And distributing positive state that "= this isn't here" on a different distribution graph than where the = routes themselves may not flow is problematic.

It'll be interesting to hear more about the intended use cases.=C2=A0 I= have a feeling that part of this is a desire for routing-distributed telem= etry.

-- Jeff

> On Nov 11, 2025, at 4:57 PM, Robert Raszuk <robert@raszuk.net> wrote:
>
> Hi,
>
> The proposal as written is just a form of a free floating idea.
>
> #1 - I would start first in providing a hook which would describe in w= hich BGP PATH ATTRIBUTE of the BGP UPDATE MSG you are going to carry those = NLRIs ... MP-REACH-NLRI ? MP-UNREACH-NLRI ?=C2=A0 NEW ONE ?
>
> #2 - Your justification for this work fully overlaps with already exis= ting IDR WG document:
> https://www.ietf.org/a= rchive/id/draft-ietf-idr-operational-message-00.txt=C2=A0 Please kindly= explain what gain do you see to add what you have proposed in the draft to= BGP UPDATE MSG ?
>
> #3 - Value: 86 (to be assigned by IANA) .. That would be squatting at = this point. Not good !
>
> #4 - I am completely not following on your list of reasons:
>
> Type 2: Unreachability Reason Code
>
>=C2=A0 =C2=A0 *=C2=A0 Length: 2 octets
>=C2=A0 =C2=A0 *=C2=A0 Value: Detailed reason code (registry to be estab= lished)
>=C2=A0 =C2=A0 *=C2=A0 0: Unspecified
>=C2=A0 =C2=A0 *=C2=A0 1: Policy Blocked
>=C2=A0 =C2=A0 *=C2=A0 2: Security Filtered
>=C2=A0 =C2=A0 *=C2=A0 3: RPKI Invalid
>=C2=A0 =C2=A0 *=C2=A0 4-65535: Reserved for future use
>
> I assume you are still trying to announce your own prefix which became= unreachable in your domain ... so what does it mean to announce it with an= y of the types like 1, 2 or 3 ?
>
> Or are you dreaming of any BGP speaker on the internet suddenly broadc= asting to anyone in the world that he failed to install a received BGP pref= ix due to one of those listed reasons ???
>
> To me this proposal looks too raw for any consideration at this point.=
>
> Regards,
> Robert
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Tue, Nov 11, 2025 at 10:12=E2=80=AFPM
> Subject: I-D Action: draft-tantsura-idr-unreachability-safi-00.txt
> To: <i-d= -announce@ietf.org>
>
>
> Internet-Draft draft-tantsura-idr-unreachability-safi-00.txt is now av= ailable.
>
>=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0BGP Unreachability Information SAFI >=C2=A0 =C2=A0 Authors: Jeff Tantsura
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Donald Sharp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vivek Venkatraman
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Karthikeya Venkat Muppa= lla
>=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 draft-tantsura-idr-unreachability-safi= -00.txt
>=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A012
>=C2=A0 =C2=A0 Dates:=C2=A0 =C2=A02025-11-11
>
> Abstract:
>
>=C2=A0 =C2=A0 This document defines a new BGP Subsequent Address Family= Identifier
>=C2=A0 =C2=A0 (SAFI) called "Unreachability Information" that= allows the
>=C2=A0 =C2=A0 propagation of prefix unreachability information through = BGP without
>=C2=A0 =C2=A0 affecting the installation or removal of routes in the Ro= uting
>=C2=A0 =C2=A0 Information Base (RIB) or Forwarding Information Base (FI= B).=C2=A0 This
>=C2=A0 =C2=A0 mechanism enables network operators to share information = about
>=C2=A0 =C2=A0 unreachable prefixes for monitoring, debugging, and coord= ination
>=C2=A0 =C2=A0 purposes while maintaining complete separation from the a= ctive
>=C2=A0 =C2=A0 routing plane.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.iet= f.org/doc/draft-tantsura-idr-unreachability-safi/
>
> There is also an HTML version available at:
> https://www.ietf.= org/archive/id/draft-tantsura-idr-unreachability-safi-00.html
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list -- i-d-announce@ietf.org
> To unsubscribe send an email to i-d-announce-leave@ietf.org
> _______________________________________________
> Idr mailing list -- = idr@ietf.org
> To unsubscribe send an email to idr-leave@ietf.org

_______________________________________________
Idr mailing list -- idr@i= etf.org
To unsubscribe send an email to idr-leave@ietf.org


--
Do= natas
--0000000000009d7e080643ca859a--