[Idr] Re: draft-tantsura-idr-unreachability-safi-00.txt

[Donatas Abraitis <[e-mail]>]

Returning to "Unreachability Reason Code", I suggest adding also
"Dampening".

On Wed, Nov 12, 2025 at 10:09 PM Robert Raszuk <[e-mail]> 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 heading
> 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 PM Jeffrey Haas <[e-mail]> wrote:
>
>> 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 have this!"
>> is the positive state.  Certainly a large number of these use cases 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 that
>> 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 <[e-mail]> 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 those
>> 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.txt
>> 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: <[e-mail]>
>> > Date: Tue, Nov 11, 2025 at 10:12 PM
>> > Subject: I-D Action: draft-tantsura-idr-unreachability-safi-00.txt
>> > To: <[e-mail]>
>> >
>> >
>> > 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 Identifier
>> >    (SAFI) called "Unreachability Information" that allows the
>> >    propagation of prefix unreachability information through BGP without
>> >    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 -- [e-mail]
>> > To unsubscribe send an email to [e-mail]
>> > _______________________________________________
>> > Idr mailing list -- [e-mail]
>> > To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
> Idr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 
Donatas