- Test - lists.nanog.org

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

23 Jan '96

> I signed the NDA, but I didn't spell my name right, so it's not > legally binding. Basically, anyone who invests over 10k gets a > seat on the space ship he's building to fly to the planet Zorgo, > where we will all pilfer advanced technology, and bring it back to > the planet earth to make us all rich. > Can I still have a seat, Vadim? Sure, but since you've broken NDA you won't get seat in the first class, so we'll use a regular microwave oven to thaw (and bake) you on arrival. You see, that's better than sacrificing guiltless bovines. --vadim

1 0

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

23 Jan '96

| Bottom line: about 270,000 pps per port, 14 microsec. | forwarding latency AND superior reliability. The choice | for NAP designers everywhere :)- Bilal, I think you missed a word. "Successful" seems to have been omitted between "choice" and "for". Some NAP designers opted for packet shredders, and might even be getting some thousands of pps total traffic (so they claim, but then they seem to count very local (i.e., cross-town) ATM connectivity as "NAP" traffic), as opposed to the low tens of thousands of packets per second *per port*, with much of that being traffic between sites with about 30 times the delay * bandwidth buffering requirements. Of course, the fact that the switched FDDI exchange points have proven to be more reliable in practice than the ATM exchange points have -- even with a fraction of the load -- tends to do nothing to diminish the religious fervour of the people who assert that ATM NAPs are the ultimate single answer to the needs of the Internet. I wonder sometimes if their brains were cellified and passed through an ATM NAP... Sean.

2 1

Re: value of co-location
by Paul 'Corwin' Frommeyer 23 Jan '96

23 Jan '96

I'll hazard flames and put my oar in... [various incisive comments about the disparate evolution of network connectivity hardware and network routing hardware ommitted] There seems to be some consensus, at least for some individuals/organizations, that bigger/faster/better router hardware is an essential, since the dairy barn approach currently in favor amongst the data comm equipment manufacturers may not prove scalable. However, the discussion so far has focussed on what won't work rather than what specific features etc. are needed. In the cause of keeping pace with the expansion (as well as a partisan reason or two ;-), what sort of beasts should this bigger, faster, better generation of routers look like? If fast packet services and co-location on a LAN milking machine won't cut it, then what's the thinking as to what *is* needed to do the job? Clueing the various equipment manufacturers in as to what direction the hardware should be evolving in is probably at least worth the effort (not to imply that individual efforts have not been underway for some time, but a collective voice often carries more weight). Unfortunately, this goes beyond simply getting a single company in touch with reality because of the plethora of pieces involved in building backbone and delivery services. However, this is probably one of the few "right groups of people" to be formulating these requirements and then bashing the various vendors over the head with them ;-). A fast .02 on my part would be that something in the way of non-blocking backplane design needs to be _advanced_ in order to be able to scale current router technology up. This to start tackling the traffic aggregation problems... Distibuted switching and multiple transport busses seem like steps in the right direction architecturally, but what are the topological and traffic flow realities that instantiation of these methods should be grounded in? Internet and Enterprise networking are markedly different, and at least until recently the focus of the manufacturers has been on the Enterprise... Also, a quick-and-dirty point-to-point delivery mechanism scalable along with the SONET hierarchy wouldn't hurt either, since as has been pointed out the fast-packet overhead for multiple and multi- point signalling (or, worse, data/voice/video integration) becomes an exacerbating bandwidth tax in the traditional point-to-point circuits used to build Internet backbones and ISP networks. This would also address Paul Vixie's all-too-true issues about the ability of the carriers to support the services in an efficient and reliable manner. If the transport is something they are familiar with (T3 being a good example, and ATM of course standing as a bad one... ;), then the reliability of the Net as a whole improves as more ISP's become able to use "supportable carrier transports". Of course, the trick is to get the supportability of T3 with the speed of OC-48... ;-) (not that there are any routers that could *handle* OC-48... arghhh... ;-) :-p) I'll be happy to assist in the bashing in my day job ;-), but since I must in conscience agree with Dennis wholeheartedly on the subject of ATM and it's orthogonal relationship to current service delivery needs, I'm definitely speaking solely as myself here. Curiosity got the better of me, tho, and I'd like to know what other thoughts there are along these lines... Cheers, Paul Paul "Corwin" Frommeyer Work Internet Engineer, CCIE Play ISP Systems Engineer Network Sorcerer At Large Cisco Systems, Inc. Paul's Fone Company pfrommey(a)cisco.com corwin(a)palas.com *** Speaking solely for myself unless otherwise noted ***

3 2

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

22 Jan '96

At 05:11 PM 1/20/96 -0500, Vadim Antonov wrote: >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. What is meant by free expansion of the circuit? >>'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. What isn't mentioned is the advantage of data-link layer multiplexing that the Fast Packet Services offer. Rather than bringing in multiple circuits and consuming multiple ports on your router, it's possible to carry traffic from customers as well as traffic to the NAP on that same interface. That's a fundamental point which is driving much of the deployment of the Fast Packet Services. George Clapp voice: 201-829-4610 fax: 201-829-2504 page: 800-980-1298 email: clapp(a)bellcore.com

1 0

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