- Test - lists.nanog.org

RE: the Internet Backbone
by Jim Browning 05 Apr '96

05 Apr '96

>From: John Curran[SMTP:jcurran@bbnplanet.com] > >At 10:32 AM 4/5/96, William Allen Simpson wrote: >>> From: Avi Freedman <freedman(a)netaxs.com> >>>... >>> Everyone (of importance) agrees that in order to claim you're a backbone >>> you have to (now, not a year ago) be connected to at least 2 public NAPs/MAEs >>> and have at least one circuit that runs at DS3 or higher speed. >>> >>No, that is not correct. >> >>A US Internet "backbone" is one which connects to ALL the NAP/MAEs in >>the US. Not just two. All of them. > >Bill, > > I'm not sure that's a viable definition. First, the number of MAE's > seems to be increasing withou bound, and secondly, there are points > that you don't want to connect due to their performance. Finally, is > "connecting" considered the same as "peering"? > >/John There is no clear consensus concerning which of the facilities are "NAPs", let alone which ones an ISP should participate in to be considered a credible National/Backbone provider. For instance, while MAE-West was not one of the original NAPs established by NSF, it clearly qualifies in all other respects. On the other hand, I don't think it would be considered necessary to be at LA, Phoenix, Tucson, Dallas, etc right now to be considered a National/Backbone provider. The criteria I've heard most frequently is "connected to three of the NAPs, peering with at least 2 national providers at each of those NAPs". I believe this is what MCI requires in order to establish peering with a new entity... -- Jim Browning

1 0

Re: MIX
by Bill Woodcock 05 Apr '96

05 Apr '96

bsimpson(a)morningstar.com (William Allen Simpson) wrote: > I certainly wouldn't want to add yet another peering arrangement > with every Tom, Dick and Harry that showed up at any regional > interconnect. One interconnect, one peering arrangement. Oh, come on, Bill... don't pretend to be be clueless just for the sake of antagonizing folks. The MIXes have route servers just like any other peering points. Or am I missing the point of your objection? -Bill ________________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

1 0

Re: the Internet Backbone
by John Curran 05 Apr '96

05 Apr '96

At 10:32 AM 4/5/96, William Allen Simpson wrote: >> From: Avi Freedman <freedman(a)netaxs.com> >>... >> Everyone (of importance) agrees that in order to claim you're a backbone >> you have to (now, not a year ago) be connected to at least 2 public NAPs/MAEs >> and have at least one circuit that runs at DS3 or higher speed. >> >No, that is not correct. > >A US Internet "backbone" is one which connects to ALL the NAP/MAEs in >the US. Not just two. All of them. Bill, I'm not sure that's a viable definition. First, the number of MAE's seems to be increasing withou bound, and secondly, there are points that you don't want to connect due to their performance. Finally, is "connecting" considered the same as "peering"? /John

1 0

RE: CIDR,Sprint and the Big Guys.
by Jim Fleming 05 Apr '96

05 Apr '96

On Friday, April 05, 1996 2:25 AM, Tim Salo[SMTP:salo@msc.edu] wrote: @> From: Jim Fleming <JimFleming(a)unety.net> @> To: "'Christian Nielsen'" <cnielsen(a)vii.com>, "nanog(a)merit.edu" @> Subject: RE: CIDR,Sprint and the Big Guys. @> Date: Fri, 5 Apr 1996 01:29:10 -0600 @> [...] @> Yes CIDR is a good thing...unfortunately, it does not guarantee that the @> net will grow and aggregate in a rational way. When coupled with the @> "slow start" ISP policy, CIDR helps to rapidly fragment the IP address @> space and in some cases causes poor IP address utilization all in the @> name of "protecting the future of the Internet" or maybe "protecting the @> Internet from ISPs". @> [...] @ @It would appear that there may also be a strong argument that the @tremendous proliferation of [small] ISPs is a significant contributor @to the growth of the size of the Internet routing tables. @ Yes...and assuming some will die for whatever reason...the policies result in small fragments being created with no active way to recover the fragments... by forcing (err coaxing) ISPs to work with "upstream providers" there is a garbage collection mechanism put in place...the upstream provider can watch over part(s) of the address space which is clearly too large for a few people to handle... @Perhaps, the [anticipated] consolidation of ISPs will be a significant @event in the efforts to control routing table size. @ @-tjs @ This is very true...this is the way cities have grown...the way railroads evolved... the way many industries have matured...as the big get bigger, small ISPs will realize that they have to partner to survive...these partnerships may help to improve aggregation, routing, etc...unfortunately, some ISPs will never partner with anyone because they "think" they are going to be the next RBOC...(as we now see, even the RBOCs are partnering to survive and AT&T is de-partnering...) The combined efforts of IANA, the InterNIC and the large "upstream providers" work to perform social (err network) engineering. This works as long as the current philosophy of "creating" and "controlling" scarce resources exists. People focused on getting rich have to "play ball" or die. This same sort of situation exists in the diamond business. All of these "network engineering" efforts take us right back to the centralized telecommunications authoriity that the Internet was designed to dismantle. It is humorous to see the bleeding heart liberal Internauts becoming the new conservative protectors of the net as maturity sets in...this is similar to the hippies and gang members that now are elected officials...people are people, even on the Internet I predict that the Internet will fall into the trap of having the same problems of the system it is displacing...there is a growing centralized "elite" that call the shots in a decentralized way...the shots that are called now are not much different than the shots called by the previous elite and not much different than the shots called by the pre-divestiture elite (called the Bell System). The only way to break this cycle is to apply the same philosophies that built the Internet to dismantling (err bounding ) the Internet...in order to do that, a ruling elite has to be installed, everyone has to sing praises of the great successes, the current system has to be bounded by its own limitations, and a few people have to "think outside of the box"... -- Jim Fleming UNETY Systems, Inc. Naperville, IL 60563 e-mail: JimFleming(a)unety.net

1 0

Re: CIDR,Sprint and the Big Guys.
by salo＠msc.edu 05 Apr '96

05 Apr '96

> From: Avi Freedman <freedman(a)netaxs.com> > Subject: Re: CIDR,Sprint and the Big Guys. > To: salo(a)msc.edu (Tim Salo) > Date: Fri, 5 Apr 1996 10:18:25 -0500 (EST) > Cc: nanog(a)merit.edu > [...] > > It would appear that there may also be a strong argument that the > > tremendous proliferation of [small] ISPs is a significant contributor > > to the growth of the size of the Internet routing tables. > > > > Perhaps, the [anticipated] consolidation of ISPs will be a significant > > event in the efforts to control routing table size. > > > > -tjs > > Not unless they happen to have contiguous address space. Oops. I forgot to add "in the long term." Presumably, a smaller number of larger ISPs would be able to justify larger address blocks. But you are correct in observing how difficult it is to go back and clean up earlier allocations. > Seriously, almost every small ISP that I know of gets addresses from its > upstream provider(s). Therefore, unless they're dual-homed, they don't > contribute to the growth of the size of the tables. > > Yes, they may sign up people with IPs in the swamp and route for them, > but so may any other ISP/NSP. > > I can't imagine that there are more than 300 local and regional ISPs > that receive address space from the NIC directly. I could be wrong, > of course... We hear a lot about dual-homed ISPs and ISPs who want to change their upstream providers. It would be very interesting to have some quantitative information about the size of these classes. (Or, are issues related to dual-homed ISPs and changes in upstream providers more theoretical than real?) -tjs

1 0

Re: Address "portability"
by avg＠postman.ncube.com 05 Apr '96

05 Apr '96

>From: matthew(a)scruz.net (Matthew Kaufman) >>From: Peter Lothberg <roll(a)stupi.se> >> Give me a call when you convinced the phone_company to make my phone number >> work in California. >The California PUC has approved local phone competition within California, >with the requirement the phone number portability (between carriers) be >fully implemented as soon as possible. Making your phone number stay the >same no matter whether you're a PacBell or MFS or TCI customer is exactly >the same problem as making IP addresses portable... just wait until ISPs >are regulated, and they get the same mandate. >-matthew kaufman > matthew(a)scruz.net Which only shows how stupid American elected representatives are. (No, i do not think they are any smarter in any other country). --vadim

1 0

Re: NANOG/IEPG/ISOC's current role
by avg＠postman.ncube.com 05 Apr '96

05 Apr '96

Avi Freedman <freedman(a)netaxs.com> wrote: >Unless they have a real plan & need to get about 128 buildings full of >100 machines/building online, it's a lost cause. You already need a >/18 to be heard from Sprint in >= 207/8. Unless you're a customer of >Sprint. And if you're a customer of Sprint you'll get aggregated in something like /14. The proxy/firewall solution for schools is probably the best. --vadim

2 1

Re: join the Internet Backbone
by avg＠postman.ncube.com 05 Apr '96

05 Apr '96

Sue them under truth is advertisements laws. --vadim >From nanog-owner(a)merit.edu Thu Apr 4 21:32 PST 1996 Return-Path: <nanog-owner(a)merit.edu> Received: from postman.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA14401; Thu, 4 Apr 1996 21:32:22 +0800 Received: from titan.sprintlink.net by postman.ncube.com (4.1/SMI-4.1) id AA11410; Thu, 4 Apr 96 21:33:50 PST Received: from merit.edu (merit.edu [35.1.1.42]) by titan.sprintlink.net (8.6.9/8.6.9) with ESMTP id AAA11296 for <avg(a)titan.sprintlink.net>; Fri, 5 Apr 1996 00:33:44 -0500 Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id XAA06390 for nanog-outgoing; Thu, 4 Apr 1996 23:47:18 -0500 (EST) Received: from cyberport.com (root(a)puma.cyberport.com [204.134.75.6]) by merit.edu (8.7.5/merit-2.0) with ESMTP id XAA06385 for <nanog(a)merit.edu>; Thu, 4 Apr 1996 23:47:14 -0500 (EST) Received: from hippo.cyberport.com (kevin(a)hippo.cyberport.com [204.134.75.2]) by cyberport.com (8.7.5/8.7.3) with SMTP id VAA17815; Thu, 4 Apr 1996 21:46:54 -0700 (MST) Date: Thu, 4 Apr 1996 21:46:54 -0700 (MST) From: Kevin Rosenberg <kevin(a)cyberport.com> To: Christian Nielsen <cnielsen(a)vii.com> Cc: nanog(a)merit.edu Subject: Re: join the Internet Backbone In-Reply-To: <Pine.SOL.3.91.960404203714.27888A-100000(a)lonepeak.vii.com> Message-Id: <Pine.BSI.3.92.960404214310.24738B-100000(a)hippo.cyberport.com> Mime-Version: 1.0 Sender: owner-nanog(a)merit.edu Precedence: bulk Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 750 Status: R > [...] > that USWest, SISNA (who now claims to be the 3rd largest ISP/NSP and still > have only a T1 to MCI, and claim that is a DS3) and all these other > people who think that they are connected to the internet back bone. > [...] In Farmington, New Mexico, SISNA uses compressing DSU's on each side of their 56K line to their main office. They claim their 56K line is a "T1-speed" line. Being in local competition with them, that bugs me more than the "250MB" tape drives that are only 120MB! ---------------------------------------------------------------------- Kevin Rosenberg | The Four Corner's Finest Internet Access Chief System Administrator | kevin(a)cyberport.com CyberPort Station | http://www.cyberport.com

1 0

CIDR,Sprint and the Big Guys. (fwd)
by Christian Nielsen 05 Apr '96

05 Apr '96

OLD> Move into the 206.10.0.0 - 206.15.0.0 New> What I meant to say was: 210.0.0.0 - 215.0.0.0 Which should be just over 1500 ISPs. Any ISP/NSP that can provide a good network outline, showing not only how they plan to put into pratice but show their current setup, locations, etc. will be assigned a /16 in the range above. That would give about 1200 ISPs /16s. Now, to make sure they are being conservative with their networks, routing tables, CIDR, etc. Explain to the ISP that the only way they are going to get a /16 is if they renumber their whole network. This will return a lot of larger /20 and above address space to the nic and reduce the size of the routing table on the net. Now, why can't something like this be done? Trust me, If you gave me /16, I would have all my customers re-number, re-number all my hosts, etc in about 6 months, which is about the timeline I would bive. But than again, we can go along as we do, the larger keep getting larger and the rest of us have to fight for IPs. ok, now off the soap box. Christian Nielsen Vyzynz International Inc. cnielsen(a)vii.com,CN46,KB7HAP Phone 801-568-0999 Fax 801-568-0953 Private Email - Christian(a)Nielsen.Net BOFH - cnielsen(a)one.dot PS :)

1 0

RE: NANOG/IEPG/ISOC's current role
by Jim Fleming 05 Apr '96

05 Apr '96

On Thursday, April 04, 1996 5:04 AM, Tim Bass (PIER)[SMTP:pier@dune.silkroad.com] wrote: @Howard states: @ @[ ... ] @ @> IMHO, I don't think you can guarantee that almost anything will stay @> routable, certainly anything less than an /18. Bluntly, there's no good @> way to guarantee routable prefixes. @> @ See #5 below... @Yes, there is a good way to GUARANTEE routable prefixes. Intermediate @system address translation which maps to "virtual renumbering".... @ See #6a below... @The answer my friend.... is blowing in the wind... in the technical @implementation, not "human attitude re-engineering"..... @ See #12 below... @The attitude, .... "bluntly, there's no good way for man to fly...." @is not unique to written history.... it is alive and well in the @Internet today ;-) @ See #3 below... @Best Regards, @ @Tim @ @@@@@@@@ From RFC 1925, April 1996 @@@@@@@@@@@@@@@@ Network Working Group R. Callon, Editor The Twelve Networking Truths (1) It Has To Work. (2) No matter how hard you push and no matter what the priority, you can't increase the speed of light. (2a) (corollary). No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won't make it happen any quicker. (3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (4) Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network. (5) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. (6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. (6a) (corollary). It is always possible to add another level of indirection. (7) It is always something (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't have all three). (8) It is more complicated than you think. (9) For all resources, whatever it is, you need more. (9a) (corollary) Every networking problem always takes longer to solve than it seems like it should. (10) One size never fits all. (11) Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. (11a) (corollary). See rule 6a. (12) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. @@@@@@@@@@@@@@ They save the best for last...in my opinion, #12 is where the answer is... we have to make things simpler and focus new technical solutions on solving the real problems...unfortunately #8 above comes into play... as well as the all of the other 12 Networking Truths... -- Jim Fleming UNETY Systems, Inc. Naperville, IL 60563 e-mail: JimFleming(a)unety.net

2 1