On Mar 26, 2009, at 12:09 PM, Christopher Morrow wrote:
Today's WG meeting brought out some contentious discussion around this presentation. The summary for a portion of the discussion was that local optimizations in BGP mechanisms can often lead to system wide systemic issues. One comment was that a particular feature (advertise-own) ends up being used in 'internet' context where it's inappropriate. In this instance though, often the VPN providers are also running 'internet' as a VPN, to lower capex/opex and take advantage of their larger 'internet' platforms for smaller 'vpn' solutions.
So to clarify.. It's ACCEPT_OWN, and it's not what's introducing the problem, it's "utilizing" it. The issue I have *here* is the fact that a client (c) advertises a prefix (p) to it's local RRs. The RRs reflect the route back to the client and the client is expected to poison it based on the Originator ID matching the local Router ID. In RFC 1966 the RRs did not reflect the route back the client because the client didn't know it was a client, and for incremental deployment it was required that the RRs not reflect it back or a routing information loop could occur. RFC 2796 was updated and allowed an RR to reflect a route back to a client and the onus was on the client to drop the update. The problem is that if the client is advertising 100ks of routes (which is perfectly reasonable for a peering edge router) to the RRs, (100ks * num_rrs) are reflected back to the client, and it now has to senselessly process and discard all of those updates. ACCEPT_OWN comes into the picture only because it employs this fundamentally broken behavior. IF ACCEPT_OWN was a function of the RR, and the routes were only reflected back to the client IF that community was presented, I'd be perfectly fine with it. -danny _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
