- Test - lists.nanog.org

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

07 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

Re: New MAE-EAST
by Sean Donelan 06 Nov '97

06 Nov '97

>Just try to bring up another point. Anyone has thought about Gigabit ethernet >switches? > >Prominet's Cajun switch has a 45GB backplane. Supports up to 24 full-duplex >Gigabit ethernet ports or 120 full-duplex fastethernet ports, or a mix >of both. The price is also very reasonable. There was a BOF at the last NANOG about the Digital version, Gigaswitch/Ethernet. However, it wasn't clear what the switch did when congested. There was some mention of IEEE congestion control, but that seems to use some sort of back pressure on the sender. I don't think that is what you want in an exchange point. A single congested egress port shouldn't block an ingress port at an exchange point. Especially if you are going to mix different types and speeds of ports. There was also some concern about the amount of buffering in the switch. And finally, when fully maxed out with ports the switch is oversubscribed, but that could be managed by only using two port cards rather than four port cards. And for a MAE-East size exchange, you will still quickly be faced with the problem tying two or more switches together, which makes the congestion control issue even more critical if it happens on a port between switches. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: New MAE-EAST
by Richard Irving 06 Nov '97

06 Nov '97

Richard Irving wrote: > > Reid Fishler wrote: > > > > Not to be rude or anything, but who is onecall? :-) > > Reid > > > > > We are a telco, specifically an IXC. We run an Exchange in Indiana. http://www.onecall.net/ http://www.indyx.net/ We, like Pac-Bell, and CHI, aren't having the same problems you are seeing at the FDDI exchanges.....

3 2

Re: New MAE-EAST
by Sean Donelan 06 Nov '97

06 Nov '97

>> I don't really fault MFS with these problems. Show me another >> exchange that is trying to pass as much traffic as MAE-east is and >> functioning properly. >> > > CHI is pretty close. Also, check Pac-Bell. > > Smooth surf. Pac-bell is running about 50% of MAE-East's aggregate inbound traffic level. AADS's web pages said they were going to get rid of their statistics pages, and it looks like they did because I can't find them anymore. But my memory was the Chicago-NAP was also much lower than MAE-East. The ATM NAPs have had different problems than the FDDI/Ethernet NAPs; but they've both had their growing pains. At one point both ATM NAPs installed FDDI rings as a work-around. Fortunately the Internet has had multiple types of NAPs available, and so far all the NAPs haven't had the same problems at the same time. However, all the NAPs do suffer from one common problem, providers who don't upgrade their egress from the NAPs when it is full. Even the ATM NAPs are having huge numbers of cell drops on certain providers' ports. This goes all the way back to the CIX router. Even the private interconnects between some providers have this problem. I think the third-party problem is pretty much a red-herring. Everyone is getting paid for service by somebody. The third-party problem seems to be one of finger-pointing. If I give all my Internet traffic to Sprintlink, Sprintlink act as much like a third-party as the Sprint-NAP acts when there are end-to-end performance problems. There isn't a single circuit in the Internet that isn't nominally 'managed' by someone, so there shouldn't be a single circuit connection problem that can't be isolated. No matter what the public may think, Internet circuits don't grow on trees. There is a observation problem for an outside observer, which lets the poorly performing provider shift blame. I've had an ISP tell me the reason packets were being dropped was MAE-East was full. Ok, open a ticket with MFS and after checking, it turned out the provider's circuit was running at capacity. Go back to the original provider, escalate it to their 'backbone engineering group' and find out they knew the port was full. It was just easier for their customer service people to blame it on "MAE-East," rather than the lack of facilities on the ISPs side. I see much of the same behavior from providers when it comes to fiber cuts. Mythology says the Internet can survive a atomic bomb, but not the backhoe. MFS has a MTTR of 2 hours, and a 99.99% availability target for its MAE's which is a higher target service-level than I see from most ISPs. I couldn't find any target performance goals for either of the Bellcore ATM NAPs, or most other exchange points. Of course, whether MFS is meeting their target service-levels is questionable. I had a question a few weeks ago, what is the best way to interconnect multiple things? If N providers want to exchange traffic, should each connect one large pipe to a common exchange point, or should each connect N smaller pipes with all the other providers? If I went out today, and tried to connect individual pipes between all the providers I exchange traffic, I end up with the same scaling problem as any other NAP. So far the solution I've seen from providers doing trying this is simply not scale past a small number n (3, 4, etc). Some folks try to limit connections by using unknowable numbers like the percentage of total Internet traffic a provider carries. Since no one knows or can even measure the total amount of Internet traffic, it is impossible to know any single provider's percentage of the total. Claims like 3 ISPs account for 90% of the Internet traffic are in the catagory that 80% of all statistics are made up. Even measuring just the traffic between end-points on two different providers is difficult because multi-homing may lead the traffic through diverse paths. I didn't know the InterNIC had so many different providers until I started peering with different providers. Besides Mark Kosters, I don't know if anyone on the outside NSI can really be sure they know of every single path to the InterNIC. Predicting what adding an additional path will do to existing traffic levels remains a problem. Simulating the Internet on anything smaller than the Internet is one of those traditional research problems, or a Scientific Wild-A** Guesses. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0