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