- Test - lists.nanog.org

Re: Policy Statement on Address Space Allocations
by Peter Galbavy 26 Jan '96

26 Jan '96

> Despite the weather forecast, I'm sure you'll warm to RIPE, its > members and even its "bureaucracy", and perhaps revise your > opinion in the light of an enjoyable experience. > > Looking forward to meeting you in Amsterdam. Me too. See you all there... -- Peter Galbavy peter(a)demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/

1 0

Re: Policy Statement on Address Space Allocations
by Sean Doran 26 Jan '96

26 Jan '96

Paul - Thank you for your kind words. Sprint's filtering policies have led directly to a more survivable SprintLink and ICM, which is to the benefit of Sprint's Internet customers. The trade-off is the inability to reach people who have just hooked up to other parts of the Internet for the first time and who are using addresses that are in conflict with what we feel our routers can support. So far the two (yes, two) customer-originated complaints involving reachability affected by our filtering have been resolved by straightforward renumbering of the non-SprintLink entity. There have, by comparison, been several hundred rather angry messages from non-customers who hook up and find that they can't use their freshly-acquired addresses to talk to SprintLink/ICM, and who claim never to have been warned that this was a virtual certainty. Two troubles in several months are rather obviously dwarfed by the thousands of customer-originated complaints about routing problems after major exchange points or other major routing transitions happen (we have observed major peers having serious difficulties with their routing system scaling recently), not to mention the most recent serious connectivity problem which involved working very closely with our vendor on getting new technology out the door that will let us scale with increasing traffic and hopefully better deal with the scaling of the increase of globally-announced routing informaiton. Customer feedback I have gotten about our CIDR and other routing policies tends to be very positive. Indeed, a number of our customers are active participants in CIDRD, NANOG, EOF and other forums where these policies sometimes are discussed at length, and none of them seem very shy about putting forward their own points-of-view, all of which is remembered and thought about frequently. We are, after all, very keen as a corporation to develop and maintain long-lasting relationships with our customers. It is possible that a number of unhappy customers have not made themselves heard, or that a number have simply voted with their feet on this precise issue, however there certainly has not been enough of the latter to justify any sort of re-think on this particular policy. Whenever I see "Sprint sucks" in newsgroups and mailing-lists, it's almost always because of reliability problems. One of our most serious backbone reliability problems involves routing convergence times and long-term stability, and this particular routing policy in combination with BGP dampening and other tools and techniques we've developed here, goes directly to the heart of those problems. I am always interested in proposals that will help provide a more robust and stable level of connectivity and performance to our entire customer base, and if you have any ideas that would make it reasonable to withdraw our prefix-length filters and _improve_ our routing stability, I would be very glad if you could detail them. Sean.

1 0

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

23 Jan '96

At 04:57 PM 1/19/96 -0800, Paul A Vixie wrote: >... The telcos have really screwed the pooch >with ISDN, SMDS, and ATM. I'm not sure why F-R has worked well without >years of delay, but it's a real anomoly. I have little if any confidence >that I will be able to buy OC3 speed ATM and use it to contact 200 >(or even 20) metro-area NAP partners any time this century. > >ISP's who practice conservative engineering (i.e., safe sex) will continue >to buy the fastest telco pipes they can get _among_those_which_actually_work_ >and this is probably going to be raw fibre before it starts to be 155Mb ATM. >I'm not in love with the idea of a barn full of routers all hooked up to >a GIGAswitch milking machine, but I have to prefer the config that works. > Religious arguments aside, the obstacle for TCP/IP performance over ATM has been due to two factors, small buffers and no explicit flow control. The new switches have large buffers. TCP works well with these switches. Explicit flow control will allow more flexible bandwidth management. That applies to TCP as well as ATM. Check out the price of an ATM circuit (considering overhead, etc) and if you perceive value for the BW then buy it. No apology needed, just purchase orders. :-) If you find that you prefer raw bandwidth over optical fiber and lots of cisco interfaces, fine, but if you like network level switching, shared network bandwidth and the price for that, buy switched services. --Kent

9 10

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