BGP ORF in practice

Fri Jun 1 14:03:25 UTC 2012

On Thu, May 31, 2012 at 10:59 AM, Rob Shakir <rjs at rob.sh> 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
table.

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

:w