What's the general consensus (hah! 
regarding the use of RFC5291 BGP
outbound route filtering? It's worked well for me in the lab, but I have
yet to use it in a live environment (and I don't know that most service
providers would know what I was talking about if I asked for it). Does it
work great or does it end up being more pain than it's worth?
Thanks
:w
Hi Wayne,
In my experience, ORF is not particularly widely deployed in live network deployments.
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.
Further to this, there is, or has been, some disconnect in the modes of ORF that are supported between various speakers - for instance, some vendors support only prefix-based ORF, where others support only RT-based, which causes some barriers to implementation.
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?
Cheers,
r.
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