The ACCEPT-OWN functionality is a direct result of a business model that is based on per route granular stitching between different routing contexts on PEs within an AS or spread across multiple ASes. This may be value added centralised services as provided by the service provider or a middleman service for creating long-standing or temporal communities of interest. The push back I have heard in re ACCEPT-OWN is that it can be done by simply configuring the "leaking" of the routes of interest on the PE where the two VPNs intersect. That is where the source of Route A from VPNA needs to be leaked into VPNB on the same PE. The issue with the configuration approach is that it assumes that customers are static as to where they may advertise routes that they may want stitched. The fact is the ISP does not know a priori which routing contexts, on which PEs,and in which AS the stitching can occur. The configuration approach is a huge operational nightmare in large scale networks that span multiple regions of the world. We had considered it..
>"So to clarify.. It's ACCEPT_OWN, and it's not what's >introducing the problem, it's "utilizing" it." The notion of sending the routes back to the originator is fairly straightforward when the entire PE is viewed as one routing context. It may be done as an efficient mechanism for a RR to advertise routes to multiple peers but it is not the optimal behavior as it requires both the RR and PEs to process additional routing state. In the VPN case the PE is really homing multiple mutually exclusive routing contexts. The ability to create simple operational models to stitch requires that we can get the routes back to a PE and import them into a different routing context that originated them in the first place. So "the problem" for one routing context is actually a requirement for creating the above value added services. How and which routes send back for importation is really the discussion. Jim Uttaro -----Original Message----- From: Danny McPherson [mailto:[email protected]] Sent: Thursday, March 26, 2009 2:20 PM To: Christopher Morrow Cc: [email protected]; UTTARO, JAMES, ATTLABS Subject: 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 [email protected] https://www.ietf.org/mailman/listinfo/grow
