|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: bring sense to the ietf - volunteer for nomcom
> I think you are confused. PEs are edges, route reflectors have nothing > to do with the core (in the context of bgp/mpls vpn). real networks tend not to put pops where there are no peers or customers. and vpns want to cross all those edges. and customers are going to effectively fully mesh the pops with vpns because a non-trivial number of large customers have branches in every darn city. there are customers for whom the transitive closure of vpn-linked pops is effectively the full set of pops in the isp's network. and just how many pe routers, or route reflectors, do you think we want to install per pop? some have even suggested that one would be well advised to run separate sets of rrs, one set for normal reflection and another for the mpls vpns. yuchh! others have said that to keep your network stable should you have vpn customers on the same aggregation routers as non-vpn customers. if this is done, each time a customer wants to add/delete the vpn service you need to re-home them. yucchh^2! > according to your taxonomy bgp/mplg vpn is "the internet style". not when we drive the bgp load of the pes or rrs geometrically. the only thing that scales about this approach is the profits of the those vendors who can actually carry the load of 100k, 200k, 400k, ... bgp routes. and we know bgp is one of the serious limits to net scaling. imiho, mpls vpns are a ploy in the router vendor war, escalating use of each other's engineering resources, trying to keep out the small vendors. somewhat like the cold war, two old men (yes, men, of course:-) drinking poison to see who will die first. the problem with this one is that it is the isps who get the poison, and they don't realize it until it is too late because it is a scaling issue and does not affect next quarter's results. randy
|