At 04:49 PM 21-10-96 -0700, Michael Dillon wrote:
On Mon, 21 Oct 1996, Jon Zeeff wrote:
In other words, the big players don't like the "open" naps and are deliberately not installing sufficient bandwidth to them?
No, the open NAP's are bad engineering and the big players are fixing the topology by routing around them.
If you want a private interconnect to avoid having to deal with 100 peering requests per week from every Tom, Dick and Harriet's web page services, OK. But there isn't any gee-whiz technology that you can do at a private interconnect that you can't do at a NAP/MAE. Open NAPs aren't bad engineering. --Kent speaking as a consultant to PacBell NAP services
On Tue, 22 Oct 1996, Kent W. England wrote:
In other words, the big players don't like the "open" naps and are deliberately not installing sufficient bandwidth to them?
No, the open NAP's are bad engineering and the big players are fixing the topology by routing around them.
If you want a private interconnect to avoid having to deal with 100 peering requests per week from every Tom, Dick and Harriet's web page services, OK.
But there isn't any gee-whiz technology that you can do at a private interconnect that you can't do at a NAP/MAE. Open NAPs aren't bad engineering.
I wasn't referring to the internal engineering of the NAP but to the overall topology engineering. IMHO it is bad engineering to build a central exchange point with no bypasses around the exchange point. It's kind of an 80/20 rule thing in that any two providers that exchange a lot of traffic at a NAP should really build a private exchange outside the NAP to keep the NAP facilities available for the 80% of the traffic that needs to go through a central exchange facility. BTW, I think that a NAP could be an excellent solution to the problem of TD&H web services. If the NAP provides facilities like the Digital facility at Palo Alto, then when TD&H come up and say we want a line right into the NAP you can say "Sure, no problem, here's a list of the ISP's that have facilities at the NAP and you can even locate your WWW server right here at the NAP if you want to". Sometimes looking at the forest will help you solve problems that are occurring with the trees. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
participants (2)
-
Kent W. England -
Michael Dillon