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

[Robert Raszuk <[e-mail]>]

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]
>
>