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 252718ADD2FD for ; Mon, 17 Nov 2025 02:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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=gmail.com 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 pgYSwMwW8EgC for ; Mon, 17 Nov 2025 02:20:55 -0800 (PST) Received: from mail-yx1-xb12e.google.com (mail-yx1-xb12e.google.com [IPv6:2607:f8b0:4864:20::b12e]) (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 6A9F18ADD24B for ; Mon, 17 Nov 2025 02:20:02 -0800 (PST) Received: by mail-yx1-xb12e.google.com with SMTP id 956f58d0204a3-63f97c4eccaso3821124d50.2 for ; Mon, 17 Nov 2025 02:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763374802; x=1763979602; 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=IR1xP0/EGitjyoNqzkuikbhG3AUw1XzSvhuHiBeU19c=; b=NnCT/aTrrdVFT7cOiquTGby3k+fnda+WeOKfMUEzdkhOG+RLpHFcsbXNKoAdU+VOPw uy8HJ9682D9thQZjnlOscff3mPXKohuJOUhIdlVOp+AnjFL44sTPnVTaLF27XAdouh7N yvyMu6fADfig5v29BbpcqwnzYXjA4Q/ugORbj7l+sPOmv87tSkplwiiWeI/DJoasikeN Xz3+KAQ9uhRklkxfgDR73byq9CVB+XGV16qx6wr9ZlgFp3hJV926UcAIRj1zgCRccqEy IRp2hIuZlgaai9oU2rB4hFJPfjTRO+SCULi0hfUCfhHyKbNLwHBFVqgDGe4VLWVkezJz WUtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763374802; x=1763979602; 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=IR1xP0/EGitjyoNqzkuikbhG3AUw1XzSvhuHiBeU19c=; b=kml7HfMtmEHAosJ+e7B/xrqaI3y+pQQYsduiFw2o1i8LBGcOu1yuxyJZGLWAozfxmt Cl3QcZ75srh8KbayJnu2rkO4PoDezxjXxXyMl/fBNa+78BIgOwvlGqbN8DTM7a6+A/O0 sdFwDbB0+fVi4x+CT+Glw1gwfNtU0OkDW/Vu+1NQ+AtNecW7sb3MDqH5F6LUh4tKea8S PXRtfKIRFtRLwJD+SgT/YdaNtd+zwdBEJKNi0Y7HvhkKg3tV8PjORTtI5UC+dZr4H4SY QKxiWG5MF3/BpiJzCjRp1S+uFrGgUQxwNgthB72UnUUssOXj9ELq+TNb4Idw9+3+LyNd pUWA== X-Forwarded-Encrypted: i=1; AJvYcCUjSQFU/7dcgxpmlzyQzsHyr4bEo482JGFSqkbcFfamhdMUzqAAbXinuHIHG/iDBHyDyWA=@ietf.org X-Gm-Message-State: AOJu0Yx8caYyXV3imfyLsHkqNH9jegCPVhZ3OrgpFu43io7EB3RAWS9Z nhKz70Timw75NBfnzg/E6uE12ZOJ3iniW14O9/3mx3sY6o+2DB0KkUwIsEw2+D/EAK2092/2PcS iDQw/5P8ooUv2lb2yuwtbhV9PZDjS63h7Sig1YXQ= X-Gm-Gg: ASbGnctNudM70xbs/n9Aid7RlZaXsX6hZE7yHMl83xNfDWGdUkIShAVwxK03rCvUTyH nnwI3nVAPFWQi8PXsm4N7AIxlgiX8Ijrc6wmyfdXLJH5CTLaa97iNlsTU6zUEpS6HaWO4pOkkdn Cs5W7yr4yEpHB6PoO/Zn2CoULGfsKtv+yWM9ZuoK8TCocHYmpcoKVdS1hc337aL8ifP5tciLgvc pnmC179vnd13evSEvvbJk0FTeVt4dgSKswVXtZTmA+2YX2qFom3CIykKbRL X-Google-Smtp-Source: AGHT+IHAEpdMu5nHL1jZAuhhndcKl3U0HTp1HHNYuJlSdNPMcjBUuQTm/21AX1MneoCE3PxG/6bq41Rz65BvHivJFU8= X-Received: by 2002:a05:690e:150f:b0:641:f5bc:698a with SMTP id 956f58d0204a3-641f5bc72b6mr5679244d50.70.1763374801788; Mon, 17 Nov 2025 02:20:01 -0800 (PST) MIME-Version: 1.0 References: <176289545153.2257004.4439438509549182676@dt-datatracker-5df8666cb-7l4w5> In-Reply-To: From: Donatas Abraitis Date: Mon, 17 Nov 2025 12:19:50 +0200 X-Gm-Features: AWmQ_bkJywZj3d9hSTmsUWvZ54d-UGhsbkADwj2_euTn8DM59Q1E_rVOJxd9qz0 Message-ID: To: Robert Raszuk Content-Type: multipart/alternative; boundary="000000000000aaa2300643c7b000" Message-ID-Hash: 4JEUJZB3KXBT2Q5XZDFSBKQS3NYF6NA5 X-Message-ID-Hash: 4JEUJZB3KXBT2Q5XZDFSBKQS3NYF6NA5 X-MailFrom: donatas.abraitis@gmail.com 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: --000000000000aaa2300643c7b000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 headin= g > 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 marked > with -idr name ... > > Cheers > Robert > > On Wed, Nov 12, 2025 at 8:30=E2=80=AFPM Jeffrey Haas wro= te: > >> Here we see the hazards of publishing a draft tagged with -idr. The poo= r >> authors haven't even had time to introduce the context. :-) >> >> While I broadly agree with the observations here and in subsequent point= s >> 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 for= m >> of "negative state attestation". In other words "you shouldn't have thi= s!" >> is the positive state. Certainly a large number of these use cases over= lap >> the more general notification dissemination mechanism that the operation= al >> message has. However, where the analogy breaks down a bit (aside from a >> lack of standardized contents for such an operational message) is appare= nt >> intention from the draft that this state should be distributed throughou= t >> 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 th= at >> is safe for any use cases for the draft is "this is completely gone from >> 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 telemetry. >> >> -- 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 th= ose >> 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.tx= t >> 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 >> > >> > * 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 became >> 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 received >> 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 Identifie= r >> > (SAFI) called "Unreachability Information" that allows the >> > propagation of prefix unreachability information through BGP withou= t >> > 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-0= 0.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 > --=20 Donatas --000000000000aaa2300643c7b000 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Returning to "Unreachability Reason Code", I sug= gest adding also "Dampening".

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

> H= ere we see the hazards of publishing a draft tagged with -idr.=C2=A0
<= div>
LOL !!!

My first guess was that= authors attempted to do UPA in BGP a bit differently than the original att= empt as described in=C2=A0draft-krierhorn-idr-upa-01.=C2=A0

<= /div>
But since in the current draft they are relying on RFC4760 yet no= t even defining attribute envelops for those NLRIs they are defining seems = very hard to guess what this is all about.=C2=A0

I= f they are indicating reasons like local policy, security filtering or rpki= that can't be for intradomain/local consumption=C2=A0so it must be hea= ding outside of a domain. How far ... who knows ... perhaps as far as it ge= ts :).=C2=A0

Bottom line - it has been a while (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 with -id= r.=C2=A0 The poor authors haven't even had time to introduce the contex= t. :-)

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
--000000000000aaa2300643c7b000--