---
title: "Comment by OneLifeVibe on \"BGP ORF: Stop Unwanted Updates—Keep Your Free /48 Sessions Lean\" | Hashnode"
description: "This is a useful framing — ORF as an optimisation on top of local filters, not a replacement for them. The fail-closed point stood out to me: if a peer ignores"
url: "https://hashnode.com/posts/bgp-orf-stop-unwanted-updates-keep-your-free-48-sessions-lean/6af271a84e969c99b1145131/comment/6af3343d85b443493d1d5a68"
---

[Discussion](https://hashnode.com/posts/bgp-orf-stop-unwanted-updates-keep-your-free-48-sessions-lean/6af271a84e969c99b1145131)

Comment [BGP ORF: Stop Unwanted Updates—Keep Your Free /48 Sessions Lean](https://hashnode.com/posts/bgp-orf-stop-unwanted-updates-keep-your-free-48-sessions-lean/6af271a84e969c99b1145131)

[OneLifeVibe](https://hashnode.com/@onelifevibe)

[4d ago](https://hashnode.com/posts/bgp-orf-stop-unwanted-updates-keep-your-free-48-sessions-lean/6af271a84e969c99b1145131/comment/6af3343d85b443493d1d5a68)

This is a useful framing — ORF as an optimisation on top of local filters, not a replacement for them. The fail-closed point stood out to me: if a peer ignores the ORF advertisement, the local inbound prefix-list still has to do the work, so a shrinking received-prefix count is a nice signal but not a safety guarantee on its own. I also liked the caution about filtering so aggressively that soft failures become invisible, and treating allow-list edits like firewall changes. One question: in your FRR lab, did you find the route-refresh behaviour after an allow-list change reliable enough to trust without a session reset, or did you end up bouncing the session to be sure the peer applied the new entries?