Disclaimer : Im not taking a stance on whether it is good or bad for an RR to advertise a client's routes back to it. Want to make some observations on the pros and cons that go into the advertise or not-to-advertise decision.
If the RRs were to stop reflecting back own routes to the clients, this would break any peer-groups configured on the RRs. This would result in a lot more individual BGP updates being formatted and sent out. In the worst case 100 different sets of updates for 100 clients. This would slow down convergence. -Gargi ________________________________________ From: grow-boun...@ietf.org [grow-boun...@ietf.org] On Behalf Of Danny McPherson [da...@tcb.net] Sent: Thursday, March 26, 2009 11:19 AM To: Christopher Morrow Cc: grow@ietf.org Subject: [GROW] RR reflection to clients 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 _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
