- Test - lists.nanog.org

Re: value of co-location
by Vadim Antonov 20 Jan '96

20 Jan '96

George H. Clapp <clapp(a)bellcore.com> wrote: >The reasons for co-location that have been mentioned so far include... >- zero-mile circuits That means expansion of that "circuit" is free. >- a hardened location for equipment That is hardly relevant, as all large players have facilities just as good. >- to establish a local presence rather than building out one's own space. Same. > - skepticism about the value of the fast packet services; the skepticism > has several flavors: > - reduced bandwidth due to protocol overhead That is not "scepticism" but a sad truth. Getting 40% less bang (on a typical IP traffic mix which includes *lots* of packets barely exceeding one cell) is rather silly. > - less reliability than a shared FDDI Shared FDDI is simply a way to offer lower performance for lower price. ATM port costs are not variable. > - performance of ATM switches compared to FDDI switches FDDI just works. It worked five years ago. >'Zero-mile circuit' isn't clear to me because, regardless of the technology >used for the NAP, it's still necessary to purchase a circuit from your site >to the NAP. The difference is between the clearline circuit and circuit with 40% protocol overhead. Some big players are carriers themselves and want to use _own_ circuits whereever possible. The reason for collocated NAPs you completely missed is called "scalability". Having all equipment in one room provides a lot of flexibility in regard to interconnections. For example, if A and B found that they have lots of mutual traffic they may want to plug one more FDDI board in their boxes and drag a private FDDI wire, to offload the traffic from shared infrastructure. When new whiz-bang LAN technology appears you can easily upgrade connection by plugging a new board into the collocated router, leaving the old interface as a backup. Which also leads to the reason #2 which you also missed -- redundancy. When ATM switch is fried or went banana you're dead. FIXes and their progeny had backup connections from the day one. --vadim

1 0

Re: value of co-location
by postel＠ISI.EDU 20 Jan '96

20 Jan '96

Hi. My workstation is connected to a 640 megabit per second lan right now. If you want one check out MyriCom at http://www.myri.com/ --jon.

2 1

Re: PacBell NAP and Co-location
by Warren K. Williams 20 Jan '96

20 Jan '96

Pushpendra Mohta wrote: >Does the arrangement you mention still require that Pacific Bell >retain ownership of the equipment that is placed at the Pacific Bell >site ? No, it does not. >Is a draft online somewhere ? No, we have not as yet drafted a contract for customers. I frankly wasn't certain as to the demand for colocation. I knew that it had been a bone of contention for working with Pacific Bell in the past, and as a result worked with various parties here to resolve the issue. As soon as I hear from a serious customer requesting a co-located solution as part of their attachment to the NAP, I'll pull together what is needed from a contractual standpoint, and put a draft on the web. We have the physical arrangements made and reserved, if you will, in case there is a true demand. ------------------------------------------------------------------- Warren K. Williams, Director - NAP Project Management Pacific Bell Business Communications Services Email: wkwilli(a)pacbell.com Phone: 510.867.9065 -------------------------------------------------------------------

1 0

Re: value of co-location
by Warren K. Williams 20 Jan '96

20 Jan '96

Paul Vixie wrote: >I know that after years of trauma and chaos and delay, we now have a couple >of NAPs implemented on an ATM mesh. If I ever see an ATM NAP come online >with dozens of 155Mb/s members and no chaos, trauma or delay, I promise to >post a full apologia here. I'll be looking forward to that post :-) Seriously though, Paul, the new platform (the Stratacom BPX) going in place here at Pacific Bell will be a test to the concerns you raise, if indeed we can bring online the PacBell NAP "with dozens of 155Mb/s members and no chaos, trauma or delay". I believe this will be the test of the hypothesis that the combination of properly engineered access line buffering, backplane speeds and congestion management capabilities can alleviate the "good put" problems previously experienced by IP over ATM implementations. We have quite a bit of date for the DS3 level that we will be presenting at the upcoming NANOG meeting, and we will certainly be compiling data on the OC3 testing as well (which, BTW, we will make public as soon as the data compilation is complete.) ------------------------------------------------------------------- Warren K. Williams, Director - NAP Project Management Pacific Bell Business Communications Services Email: wkwilli(a)pacbell.com Phone: 510.867.9065 -------------------------------------------------------------------

1 0

Re: value of co-location
by George H. Clapp 20 Jan '96

20 Jan '96

The reasons for co-location that have been mentioned so far include... - zero-mile circuits - a hardened location for equipment - to establish a local presence rather than building out one's own space. - skepticism about the value of the fast packet services; the skepticism has several flavors: - reduced bandwidth due to protocol overhead - less reliability than a shared FDDI - performance of ATM switches compared to FDDI switches 'Zero-mile circuit' isn't clear to me because, regardless of the technology used for the NAP, it's still necessary to purchase a circuit from your site to the NAP. The circuit is either included in the price of the fast packet service or purchased separately as a leased line to the co-location site. The next two points, 'hardened location' and 'establish a local presence,' make sense. If you do not have a presence in the city where the NAP is located, co-location serves that purpose. The various statements made concerning the value of the fast packet services are familiar arguments. I'd like to point out that CERFnet uses SMDS, the Northwest NAP (NIX) uses Frame Relay, and the San Francisco and Chicago ATM NAPs are carrying significant amounts of traffic. The Chicago NAP is experiencing peak traffic of nearly 80 Mbps. What is needed to move the debate forward are objective performance criteria and measurements, and I look forward to the work of the Benchmarking Methodology Working Group to provide that criteria. George Clapp voice: 201-829-4610 fax: 201-829-2504 page: 800-980-1298 email: clapp(a)bellcore.com

2 1

Re: value of co-location
by Kent W. England 20 Jan '96

20 Jan '96

At 12:24 PM 1/19/96 -0500, Stephen Balbach wrote: > >Get a 100Mb FDDI or Ethernet connection between the two colocated >routers. > >Then bring in multiple Fast packet services into your router which then >aggregates out the LAN port. > > This breaks down when the connection speed goes from DS-3 to OC-3. --Kent

4 3

Re: .com pollution
by Joe Pruett 20 Jan '96

20 Jan '96

for sites that don't want to restart dns, you can usually clean things out of the cache by doing something like: repeat 500 dig ns com. becaused cached data has its ttl dropped by 10% each time it is used (at least in bind-4.9.3-beta34 and above).

1 0

Re: .com pollution
by Alan＠PeachNet.EDU 20 Jan '96

20 Jan '96

I found corruption in 198.72.72.10 (my server) and killed/started BIND at 17:50 EST. My other servers 131.144.4.10 and 131.144.4.9 were not affected. I saw trash like this via nslookup/dig: "com nameserver = H.RÔT-SERVERS.NET". I did not dump the db so I can't compare TTL, etc with you. A-I were also all corrupt. Any idea how it started? Alan At 7:06 PM 1/19/96, Kobi wrote: >...and, on our resolvers.... > >com. 321028 NS H.RÔT-SERVERS.NET. > 320919 IN NS H.R\357^?T-SERVERS.NET. ;Cr=addtnl [198.72.72.10] > >[B., C., D., E., all corrupted from the same source] > >I have killed and restarted named on ours... > >_k

1 0

Re: .com pollution
by Kobi 20 Jan '96

20 Jan '96

...and, on our resolvers.... com. 321028 NS H.R�T-SERVERS.NET. 320919 IN NS H.R\357^?T-SERVERS.NET. ;Cr=addtnl [198.72.72.10] [B., C., D., E., all corrupted from the same source] I have killed and restarted named on ours... _k

1 0

.com pollution
by Per Gregers Bilse 19 Jan '96

19 Jan '96

(Credit for spotting this goes to Dima Volodin from Sprint.) Please check your nameservers for .com NS bogus data. I had a look around after Dima pointed out the bogus data in ns.EU.net, and over 3/4 of the nameservers I checked were infected (sprint, merit, mci, ans, net99, janet ...). ;; ANSWERS: com. 467325 NS E.ROOT-SERVERS.NET. com. 467325 NS I.ROOT-SERVERS.NET. com. 467325 NS F.ROOT-SERVERS.NET. com. 467325 NS G.ROOT-SERVERS.NET. com. 467325 NS A.ROOT-SERVERS.NET. com. 467325 NS H.ROOT-SERVERS.NET. com. 77377 NS ari.ari.NET. com. 77377 NS ns2.sprintlink.NET. com. 77377 NS ns1.sprintlink.NET. com. 77377 NS ns.peach.NET. com. 467325 NS B.ROOT-SERVERS.NET. com. 77377 NS k2.ari.net. com. 325800 NS H.RoT-SERVERS.NET. com. 324155 NS B.RoT-SERVERS.NET. com. 324155 NS C.RoT-SERVERS.NET. com. 324155 NS D.RoT-SERVERS.NET. com. 324155 NS E.RoT-SERVERS.NET. com. 324155 NS I.RoT-SERVERS.NET. com. 324155 NS F.RoT-SERVERS.NET. com. 324155 NS G.RoT-SERVERS.NET. com. 324155 NS A.RoT-SERVERS.NET. com. 467325 NS C.ROOT-SERVERS.NET. com. 467325 NS D.ROOT-SERVERS.NET. 'rot-server' ... -- ====== ___ === Per G. Bilse, Mgr Network Operations Ctr ===== / / / __ ___ _/_ ==== EUnet Communications Services B.V. ==== /--- / / / / /__/ / ===== Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / ====== tel: +31 20 6233803, fax: +31 20 6224657 === ======= 24hr emergency number: +31 20 421 0865 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse(a)EU.net

1 0