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

[Jeffrey Haas <[e-mail]>]

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]