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
Randy;
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.
Real networks? The RFC explicitly states that: : We are not focused on providing VPNs over the public Internet. The RFC has nothing to do with the Internet. So, real networks, here, should be interpreted as telephone networks, part of which may be private IP networks. Recent introduction, by IETF, of intelligent intermediate entities such as edge routers, policy decision points and call agents is the direct violation of the end to end principle which causes a lot of scalablity problems. But, do you think telephone network operators mind? IETF, now, means Intelligent Extension of Telephone Forum.
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.
That's exactly what IBM did with computers, until it was defeated by UNIX and RISC. What else can you expect with Cisco? Masataka Ohta
Masataka Ohta wrote:
IETF, now, means Intelligent Extension of Telephone Forum.
Not to offend anyone, but one could say "Imbeciles Extending the Telephone Forum" could apply to some limited WGs. :)
Recent introduction, by IETF, of intelligent intermediate entities such as edge routers, policy decision points and call agents is the direct violation of the end to end principle which causes a lot of scalablity problems.
These things should be especially troubling to all of us. No vendor I have spoken to will make a clear statement of direction on where they believe the intelligence should be, resulting in a tremendous FUD factor for those purchasing technology without a solid technology background. They just end up purchasing it all or none of it. When it becomes more important for "engineers" to have memorized vendor product lines rather than technologies to solve business problems, we have issues like these. It would appear that some have left the realm of engineering and entered the art gallery. -Nathan Lane
Randy;
The RFC explicitly states that:
: We are not focused on providing VPNs over the public Internet.
The RFC has nothing to do with the Internet.
Note that BCP9, RFC2026, says: publication for comments before proceeding further. The RFC Editor is expected to exercise his or her judgment concerning the editorial suitability of a document for publication with Experimental or Informational status, and may refuse to publish a document which, in the expert opinion of the RFC Editor, is unrelated to Internet ^^^^^^^^^^^^^^^^^^^^^ activity or falls below the technical and/or editorial standard for ^^^^^^^^ RFCs. I should accept a fact that Jon Postel is really dead. Masataka Ohta
participants (3)
-
Masataka Ohta -
Nathan Lane -
Randy Bush