- Test - lists.nanog.org

Re: value of co-location
by salo＠msc.edu 22 Jan '96

22 Jan '96

> To: nanog(a)merit.edu > Subject: Re: value of co-location > Date: Mon, 22 Jan 1996 09:29:06 -0500 > From: "Joseph Lawrence" <lawrence(a)mci.net> > [...] > PS. Also does someone have numbers for the amount of > buffering in a DEC gigaswitch, and information on their buffer > managment (i.e. variable length buffers vs fixed length buffers). DEC has a nice technical report about the flow control mechanism used in the GigaSwitch. Your DEC salesperson should be able to get you a copy, and probably some other interesting stuff, (make your salesperson earn his or her living...). In some sense, you may be asking the wrong question. I think the GigaSwitch flow control mechanism pushes the buffering requirements back to the FDDI stations (i.e., routers). Consult the DEC report for the real answer. If necessary, I can dig up the document number. -tjs

1 0

Re: value of co-location
by Paul Ferguson 22 Jan '96

22 Jan '96

At 04:54 AM 1/20/96 -0700, Dave Siegel wrote: >> >> This breaks down when the connection speed goes from DS-3 to OC-3. >> > >> >LAN speeds can keep up with WAN speeds at OC-3, just use ATM. >> > >> >--- >> >Stephen Balbach "Driving the Internet to Work" >> >VP, ClarkNet due to the high volume of mail I receive please quote >> >> You are, obviously, kidding. >> -- >> Paul Ferguson || || > >He's obviously talking about some kind of LAN quite unlike Ethernet. ;-) > >Dave > Obviously. ,-) - paul -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso(a)cisco.com c i s c o S y s t e m s

1 0

Re: value of co-location
by Sean Doran 22 Jan '96

22 Jan '96

| the goal is to come up with a router the size of a 5ESS | with similar capacity ^^^^^^^^^^^^^^^^^^ ^^^^^^^ greater bigger than Just as an aside, the number of switched minutes for PDN/VPN dialup data traffic of all sorts (IP and non-IP, Internet and private network) through one particularly data-oriented IXC is widely expected to exceed the total number of switched minutes for voice traffic by the middle of summer, this year. It would astonish me to learn that a number of other IXCs and some LECs have not made strikingly similar predictions, give or take some weeks or months. | (and which is installable and maintainable by telco knuckledraggers) You got that part right. Sean.

1 0

Hotel reminder
by Pam Ciesla 22 Jan '96

22 Jan '96

Make sure to reserve your hotel rooms early for the NANOG Meeting. Hotel info in on the Web location http://www.nlanr.net/nanog/ or http://nic.merit.edu/. Also, if you have not registered please do so either by e-mail to me or on the Web site http://nic.merit.edu/. The NANOG Meeting will be February 15 & 16 in San Diego at the Supercomputing Ctr. If you need more info let me know. Pam Ciesla

1 0

Re: value of co-location
by Scott Bradner 21 Jan '96

21 Jan '96

> other new switches barely have enough to replace a one-room ethernet. speakng from testing experience - more seem to fall into this state than into the 'ok for data' list Scott

1 0

Re: value of co-location
by Paul Ferguson 21 Jan '96

21 Jan '96

At 06:36 PM 1/19/96 -0500, Stephen Balbach wrote: >> 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. > >LAN speeds can keep up with WAN speeds at OC-3, just use ATM. > >--- >Stephen Balbach "Driving the Internet to Work" >VP, ClarkNet due to the high volume of mail I receive please quote >info(a)clark.net the full original message in your reply. > > You are, obviously, kidding. - paul [in singapore at the moment] -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso(a)cisco.com c i s c o S y s t e m s

3 2

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