On Thu, May 31, 2012 at 10:59 AM, Rob Shakir r...@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
