BGP ORF in practice

Wayne Tucker wayne at
Fri Jun 1 09:03:25 CDT 2012

On Thu, May 31, 2012 at 10:59 AM, Rob Shakir <rjs at> wrote:
> It has some potential to be difficult to manage where implementations
> begin to experience complexities in building UPDATE message replication
> groups (where peers have a dynamic advertisement (egress) policy due to ORF,
> then this may mean that the number of peers with common UPDATE policies
> reduces, and hence concepts like policy-driven UPDATE groups become less
> efficient). This may impact the scaling of your BGP speakers in ways that
> are not easy to model - and hence may be undesirable on PE/border devices
> where control-plane CPU is a concern.

Makes sense - ORF would reduce the net amount of processing required,
but puts more of it on the advertising side.

> In an inter-domain context, I have seen some discussion of ORF as a means
> by which an L3VPN customer may choose to receive only a subset of their
> routing information at particular "low feature" sites - but the
> inter-operability issues mentioned above resulted in this not being
> deployed. Do you have a similar deployment case?

My deployment case is as an end user of multiple ISPs.  At previous
jobs (at service providers) I got used to the flexibility provided by
multiple full tables, but at this job I don't have the budget for
hardware that's really designed to handle that.  Without ORF, my
choices are:

1.) default prefixes only

Way too little control for my taste. I'm stuck either letting it pick
one "best" 0/0 to use or tweaking the config so that I can do ECMP
(which freaks out support staff when their traceroute bounces around).

2.) default + subset (such as customer routes)

Better than #1, but less flexible if I want to steer a prefix anywhere
other than to a service provider which is advertising it to me.

3.) default + full

Flexible in that I can filter what I accept and still rely on the 0/0
prefix for "full" reachability.  The control plane on my routers can
handle that many prefixes in memory, but it bogs them down a bit and I
have to be careful of how many prefixes I let into the forwarding

Thanks for the input.  It sounds like ORF could be viable, but only if
the service provider is amenable and the equipment is compatible.


More information about the NANOG mailing list