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