November 1997 - Test - lists.nanog.org

Re: Architectural Solutions to Internet Congestion Based On SS7 and Intelligent Network Capabilities
by csilva＠notes.cc.bellcore.com 07 Nov '97

07 Nov '97

carl ford at bellcore is doing more work on this, please e-mail him for more info.... carl silva 908-699-7850 To: Alan Gebele/Bellcore@Bellcore, Carl S. Ford/Bellcore@Bellcore, Carl L. Silva/Bellcore@Bellcore cc: From: Luis D. Arango/Bellcore Date: 11/06/97 04:44:34 PM Subject: Re: Architectural Solutions to Internet Congestion Based On SS7 and Intelligent Network Capabilities Folks, As expected, fyi, rave review from the net community. Lou To: tli @ juniper.net cc: ferguson @ cisco.com, nanog @ merit.edu (bcc: Luis D. Arango/Bellcore) From: kc @ nlanr.net Date: 11/06/97 05:41:46 AM PST Subject: Re: Architectural Solutions to Internet Congestion Based On SS7 and Intelligent Network Capabilities > The operative concept in this paper is 'telephone networks'. > > "Architectural Solutions to Internet Congestion Based On > SS7 and Intelligent Network Capabilities" I particularly liked the myopic use of the term "Internet Congestion". And here I thought that they had a solution for MAE-East.... ;-) I think the paper would have been more accurately titled: "Kludges to get around modems that don't say goodbye." or "We never should have introduced flat rate local dialing. What now?" ;-) ;-) tony -- i almost went catatonic when i tried to read that paper -- check out sentence number One: The explosive growth of the internet has created problems for the Public Switched Telephone Network (PSTN), which for the forseeable future will provide the majority of users with internet access via dialup modems. i love how their phrasing it like they have this acute perception about the market demands. as though we're all still using modems by choice. as though THEY aren't the ones limiting us to this silly analog crap, despite that they already have perfectly high quality dedicated copper pairs into customer premises. the only reason Anyone is still using a modem is cause the PSTN can't seem to Get With The Program and learn how to speak Internet (speak it, hell, they can't even Spell it with a capital I in this paper. i think we should all lowercase pstn from now on.) (ok so that made less sense coming from me. whatever.) if it weren't so depressing it would be amusing, the attitude throughout this paper: that the PSTN views Internet traffic as something to quarantine off to its own network (keep it away from the precious lucrative pstn) this paper provides no architectural solution to, nor even insight into, Internet congestion. not even solutions that could clearly increase RBOC revenues (what morons) instead it draws Magic Sphere around the telephony network, shielding it from the Horrible Intimidating Internet, without any consideration of how they might be able to participate in evolving the Internet efficaciously. ok so maybe we weren't expecting some huge breakthrough from them, but did they have to so *Vividly* confirm my worst fears about the prevailing archaic pstn mindset. my favorite part was one of their possible solutions for how to divert circuit calls to ISPs based on some numbering scheme: to obtain all ISP and on-line service provider (OSP) telephone numbers, and configure office-based 'triggers' for these numbers. oh yeah. that'll work. all the phone numbers of all the ISPs. yum. the boggling part is that they're *already* openly assuming the need for an additional packet switched network No Matter What. and the pstn has already dedicated Always-On copper lines from customers to COs -- so their plan is to do some heuristics on the signals coming in from the copper pair, and turn it into a transient fixed bandwidth circuit. brilliant leap of logic right into the abyss, how did they manage that. can't they come up with a more broken model? (no, i don't want to know) i just don't see what's so repulsive to them about just building a PSI(nternet)N, colocating routers, then using the already dedicated circuits to customer premises to access it. (i guess that's what @home thought too; they seem to have at least gotten that part right) they're adding so much Kruft to their system just to avoid moving to a more capable one there is something so Deeply Wrong with this picture where's Kuhn when you need him maybe we should get michael moore to do a movie about it (i know, you all were planning to wait for the movie rather than read that article anyway. wise souls.) k

1 0

BGP/Multihoming
by Michael R. Poyaoan 07 Nov '97

07 Nov '97

The diagram below describes our current set-up: * We have two default routes via BGP with MCI (L1 and L2) for outgoing traffic. * The two MCI links are configured to load share incoming traffic thru the use of MEDs. AS701 +--------+ | UUNet | +--------+ | AS3561 | +-------+ +--------+ | MCI | | UNA | AS10275 +-------+ +--------+ | | | | | | | | | L1| |L2 L3| | | AS6648 | | | +----------+ | | +---| | | | | Sky |-----+ +------| | +----------+ Questions: 1. How can I use the third link for default routes? Is static routing the only solution? 2. Is it possible to load-share outgoing traffic between two different ASN's? How? 3. How can I unclude the third link for load-sharing incoming traffic? Please reply privately. Thanks, --------------------------------------------------------------------------- Michael R. Poyaoan email: mrp(a)skyinet.net Network Operations Center voice: +63 2 411-2005 Sky Internet, Inc. fax: +63 2 411-2003 ---------------------------------------------------------------------------

2 1

Cyberpromotions plans to acquire or merge with a national ISP?
by Paul A Vixie 07 Nov '97

07 Nov '97

Background: AGIS cut them off, they're suing AGIS, they're also making noises about starting their own backbone. In a USA Today article (05 Nov) they got more specific about their plans. Sorry Randy, there's nothing in this you can cut or paste into your Cisco. But I think that peering with a Cyberpromotions-partnered ISP would be a huge operational problem based on reports of AGIS's experiences with them, and I wanted to give everyone a heads-up that Cyberpromotions appears not to be ready to fold up their tent and stop spamming us all quite yet. Best quote from below: "AGIS engineers expressed skepticism that a deal like the one Wallace describes would be possible; even if one of the smaller backbone companies agreed to team up with him, backbones must negotiate to exchange traffic at "peering points" and many would refuse." "But Wallace's partner in the venture, Walt Rines, another e-mail marketer and president of Quantum Communications of Stratham, N.H., says three compaines are being considered, and all have peering agreements through 2006 or 2008. "That allows us time to make this thing happen so everybody's happy," he says. "We know things have to change." ------- Forwarded Message Newsgroups: news.admin.net-abuse.email Subject: USA Today Article..... Date: Thu, 06 Nov 1997 06:21:51 GMT OK, for those who couldn't or didn't want to get the November 5, 1997 USA Today article on Scamford...here are some excerpts. Section D, page 4D. Two articles by Leslie Miller, one doesn't give credit. A big picture of Scamford sitting on the floor of his office, he's holding a mail box with the letter EMAIL on the side. He is surrounded by computer equipment and cheap church dinner looking tables. "On-line lament: Deliver us from junk email" Talks about hijack servers, AOL lawsuits.... A real good tidbit here, something most predicted about the USA Today survey.. "Despite the annoyance, many users (55% in a Harris Survey in April) think spam is no big deal. "Just hit the delete button," said numerous respondents to a recent informal servey on USA TODAY's Web site." "Despised 'Spam King' sends no regrets" "He expects to sell more than 2 million in marketing-related products this year. And though temporarily sidelined, he says he's within days of announcing a deal that will give him "ownership and control" of one of the 20 or so providers whose networks make up the "backbone" of the Internet. The agreement will allow his company "to connect without fear of getting the lines turned off." "AGIS engineers expressed skepticism that a deal like the one Wallace describes would be possible; even if one of the smaller backbone companies agreed to team up with him, backbones must negotiate to exchange traffic at "peering points" and many would refuse." "But Wallace's partner in the venture, Walt Rines, another e-mail marketer and president of Quantum Communications of Stratham, N.H., says three compaines are being considered, and all have peering agreements through 2006 or 2008. "That allows us time to make this thing happen so everybody's happy," he says. "We know things have to change." [rest of article skipped] ------- End of Forwarded Message

2 1

Re: YKYBHTLW
by Jay R. Ashworth 06 Nov '97

06 Nov '97

[CC of a followup to your news posting] On Sun, 02 Nov 1997 15:37:09 -0800, Matthew Sayler wrote: > You know you've been hacking too long when you read "Evergreen Point > Floating Bridge" as "Evergreen Floating Point Bridge".. :-) Even routers don't need floating point... why would bridges need it? Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592

1 0

RE: IPv8 < IPv6
by Rodney Joffe 06 Nov '97

06 Nov '97

> Alan Hannan said: > > Physical topology is likely to map to geographic topology. > Circuits certainly do take odd L1 paths to connect L1 endpoints, > but these are exceptions, not he rule. > > Accordingly, not allocating in a geographic fashion lends to > deaggregation, which is bad. > > A good sentiment, but not neccessarily practical. The one constant we > can count on is that things change. > So, if I look at my crystal ball, and predict that I will need n addresses in a particular physical location, using your planning exemplar I will allocate n addresses in an aggregate. The fact that I only need 1/2 n now means that I will temporarily waste 1/2 n. But what happens when I need n + 1 addresses in that city? Which is the lesser of two evils? So there is also a good argument to *not* rely on a congruence of physical and geographic topology. Some form of NAT still appears preferable. > > Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net

1 0

Ascend GRF
by Mark Tripod 06 Nov '97

06 Nov '97

Anyone care to share their experiences with the GRF? I am interested in hearing some real world opinions on its ease of use, stability, compatibility, and realiability. Private emails are fine if you don't want public. Thanks in advance for any insight. Mark Tripod Senior Backbone Engineer Exodus Communications

5 5

Re: New MAE-EAST
by Tim Salo 06 Nov '97

06 Nov '97

> Date: Thu, 6 Nov 1997 10:05:31 -0500 (EST) > From: "Paul D. Robertson" <root(a)gannett.com> > Subject: Re: New MAE-EAST > [...] > I'm sure that's a part of it, I initially saw a lot of dropped packets > through a couple of ATM clouds. I'm seeing some improvements in > some of the providers, however, given the trumpeting of ATM (magic bullet > syndrome), it seems that it's just not something which happens correctly > by default. Some ATM switches are better than others. In particular, some of the early ATM switches had very small buffers. They simply weren't designed to support bursty data like IP. There are a number of "good" ATM switches, at least in the sense that they have adequate buffering, available. Depending on whether you are using ATM as a fine-grained, relatively static multiplexing service (CBR) or as a bandwidth-on-demand service (UBR or ABR), the amount of buffering in the network may make a difference. This is probably a good question to ask your prospective service provider. > before we go off on the 'nothing happens correctly by > default' tangent, it's just been my general observation that whenever > my packets have been transited over ATM, my latency has been less than > ideal. I would have figured that oversubscription would result more in > lost packets and timed out connections (which were also seen, but more > easily screamed about) than latency, but I guess that's a factor of how > oversubscribed the line is. > [...] While I don't know your particular circumstances, lots of things can cause latency. Distance, or perhaps unexpected distance, is often an explanation for propagation delay. Some carriers may backhaul your ATM traffic to a switch far away. So, you don't really know what latency to expect unless you know the physical path your data traverse. By the way, the same sort of thing can happen can happen with point-to- point leased lines. We recently had a line which used a rather circuitous route to reach its destination. We asked the carrier to find a shorter path, which they did. -tjs

1 0

New MAE-EAST
by Adam Hersh 06 Nov '97

06 Nov '97

With all of the problems with MAE-EAST..... Any plans from anyone to create a ATM exchange point in the DC area? -Adam Hersh

9 12

Re: /19 addresses and redundancy
by Harold Willison 06 Nov '97

06 Nov '97

Actually, AGIS currently filters like this: We filter everything at /24. We will apply next-hop-self to all exchange point peering sessions. We expect peers to do likewise and we will route map if necessary. We dropped the filtering of smaller net blocks to facilitate multi-homed customers. We used to feel that the total size of the routing tables was a significant issue but we have seen it hit around 90,000 on a really bad net day and we have been able to hold the tables. Our GRFs are equiped to hold a table with 250,000 routes. I don't know how close to this total the table could successfully hold but it's certainly more than the tables today. CIDR has also helped to lower the total route table size. So AGIS has elected to opt for the solution which will serve the customer the best and we accept every /24 and larger announcement. > >Agis also has a policy statement: > >We will filter TWD at /24. > We will filter 206+ at /19. > We will filter everything else at /16. > We will apply next-hop-self to all exchange point peering sessions. > We expect peers to do likewise and we will route map if necessary. > > >Again, whether these are adhered to strictly by these two providers, or any >others, will remain to be seen when you give it a try. > >Keep persuing your own addressing in the meantime. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Harold Willison AGIS Network Engineering | * Network Engineer 313-730-5151 * | News Admin. 313-730-1130 | | news(a)agis.net 24 hours a day, 7 days a week | * harold(a)agis.net noc(a)agis.net * | <bold><italic> <underline>http://www.agis.net</underline></italic></bold> |<bold><italic> </italic></bold>\*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

1 0

Re: Architectural Solutions to Internet Congestion Based On SS7 and Intelligent Network Capabilities
by Tony Li 06 Nov '97

06 Nov '97

> The operative concept in this paper is 'telephone networks'. > > "Architectural Solutions to Internet Congestion Based On > SS7 and Intelligent Network Capabilities" I particularly liked the myopic use of the term "Internet Congestion". And here I thought that they had a solution for MAE-East.... ;-) I think the paper would have been more accurately titled: "Kludges to get around modems that don't say goodbye." or "We never should have introduced flat rate local dialing. What now?" ;-) ;-) Tony

3 3