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

[Donatas Abraitis <[e-mail]>]

a) How are these types distinguished? IMO, it's easier to have a single one
(like filtered) instead of sub-reasoning. And... as a very popular do we
want to disclose this "WHY" (reasoning) to external peers?
1: Policy Blocked
2: Security Filtered

b) NLRI format...

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |           IPv4 Prefix (variable)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    TLVs (variable)                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I think it's missing ID part (if additional paths are used), or we should
say that "is't not working with add-paths"?

c) Configuration example is wrong:

router bgp 65001
  neighbor 192.0.2.1 remote-as 65002
  !
  address-family ipv4 unreachability
    neighbor 192.0.2.1 activate
    neighbor 192.0.2.1 maximum-prefix 50000
    neighbor 192.0.2.1 route-map UNREACH-IN in
    neighbor 192.0.2.1 route-map UNREACH-OUT out
  exit-address-family
  !
  address-family ipv6 unreachability
    neighbor 2001:db8::1 activate
  exit-address-family
!
route-map UNREACH-IN permit 10
  match community NO-EXPORT-UNREACH
  set local-preference 50
!

2001:db8::1 is not defined :)

d) What happens if conflicting information arrives (e.g., one peer says
“RPKI invalid”, another still advertises the prefix normally)? Like
spoofing/malforming.

e) To me it sounds like BMP-like another one complex...

f) I'm just thinking loudly if we can't have the same information encoded
in NHC (Next Hop Characteristics)... Something like:

AFI: 1
SAFI: 1
NLRI: 192.0.2.0/24
NHC:
  Type: 100 (Unreachability Status)
  Value:
    Reason: RPKI Invalid
    Timestamp: 1731423624
Path Attributes: AS_PATH, ORIGIN, etc.

$0.02

On Wed, Nov 12, 2025 at 4:19 AM gengnan <gengnan=[e-mail]>
wrote:

> Hi,
>
>
>
> Had a look at the draft. A question to my mind is: for what prefixes do we
> need to announce using the new proposed safi.
>
>
>
> 1. the prefixes that have been announced/propagated to a peer but now
> become to fail to pass the local policy due to policy changes?
>
> 2. the prefixes that are received from a peer but failed to pass the local
> policy, and thus will not be propagated further?
>
> 3. the prefixes that failed to pass the local policy (e.g., RPKI invalid)
> but still be propagated?
>
> 4. …
>
>
>
> Best,
>
> Nan
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Wednesday, November 12, 2025 5:57 AM
> *To:* idr@ietf. org <[e-mail]>
> *Subject:* [Idr] draft-tantsura-idr-unreachability-safi-00.txt
>
>
>
> 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]
>


-- 
Donatas