July 1997 - Test - lists.nanog.org

Re: Another UUNET Explanation
by Joe McGuckin 02 Jul '97

02 Jul '97

I've noticed that several of the larger networks use frame-relay. Why? Our experience with frame-relay with the local telco has had mixed results. What technical advantages does a frame-relay network have over an IP routed network? Thanks! Joe

11 14

Re: Keynote/Boardwatch Internet Backbone Index A better test!!!
by Dennis Simpson 02 Jul '97

02 Jul '97

> To: nanog(a)merit.edu > Subject: Re: Keynote/Boardwatch Internet Backbone Index A better test!!! > From: smd(a)clock.org (Sean M. Doran) > Date: 01 Jul 1997 11:02:25 -0400 > > randy(a)psg.com (Randy Bush) writes: > > > > Just out of curiosity, why do many (not all) of the large backbone providers > > > establish their face to the web (their corporate webserver) on slow, > > > badly positioned machines? > > > > Because it is done by marketing, not engineering? > > In my opinion, this alone should reduce the Value Number > of any given provider. I can't imagine valuing more highly, any company whose marketing department runs the place with enough sway, that their own promotion devices are technically better than their competitor's (including many highly respected organizations) by large factors. You don't suppose that might be related to Compuserve's ranking first, then getting out what appears to be the first advertising based on the results? Nah, couldn't be. Thx, dennis

1 0

Re: FW: UUNET Current Network Status
by Neil J. McRae 02 Jul '97

02 Jul '97

On Wed, 2 Jul 1997 08:49:15 -0500 James Saker <jsaker(a)intellitek.com> wrote: > didn't see this here yet... first cisco problems, now cascade? > What ever it is, they are flapping like crazy its a PITA. Neil -- Neil J. McRae. Alive and Kicking. Domino: In the glow of the night. neil(a)DOMINO.ORG NetBSD/sparc: 100% SpF (Solaris protection Factor) Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A>

1 0

Re: Another UUNET Explanation
by Wolfgang Henke 02 Jul '97

02 Jul '97

> Well sorry for the "delay" but I was in Paris for > some time ... > OK .. "delay" IS THE ISSUE! > Voice over IP ... etc can not take the long delay > times that ATM and Frame Relay may inccure. > It's the same reason high earth orbit sat comm is not > good for that type of communication. ........ > The "delay" of my exported X based Mailtool over a 64K > line between the US and Netherlands is driving me crazy! Here are some approximate light speed latencies: silicon valley to Chicago 40 milliseconds silicon valley to East Coast 60 milliseconds East Coast to Europe 110 milliseconds Via geostationary satellite 260 milliseconds Wolfgang http://www.whnet.com

1 0

FW: UUNET Current Network Status
by James Saker 02 Jul '97

02 Jul '97

didn't see this here yet... first cisco problems, now cascade? -----Original Message----- From: UUNET Network Operations [SMTP:noc@UU.NET] Sent: Tuesday, July 01, 1997 3:17 PM To: alter-ops(a)UU.NET Subject: UUNET Current Network Status July 01, 1997 Dear UUNET Customer, Please accept our apologies if you have experienced any service interruptions over the past 24 hours. The cause of these problems has been traced to a software defect within our Cascade Frame Relay network. UUNET is working closely with Cascade to fully understand the cause and effects of these problems and is in the process of identifying a permanent fix. This may include rapidly deploying new software into the network. We will provide periodic updates throughout the day as further information becomes available. Routing instabilities may continue at a diminished capacity over the next 24-48 hours as switches receive updates. Thank you for your patience during this period. Again, we apologize for any inconvenience which these outages may have caused you or your customers. Sincerely, UUNET Technologies, Inc.

1 0

Routing vs Switching (was Re: Another UUNET Explanation)
by smd＠clock.org 02 Jul '97

02 Jul '97

Alex Rubenstein <alex(a)nac.net> writes: > Ummm.. Maybe you are missing my point. Those of us that do not have > bottomless pockets to pay for a "EVERY ROUTET HAS A CONNECTION TO EVERY > OTHER ROUTER (VIA PPP -- added by me). Hmmm... a router that is connected to every other router via PPP has precisely the same problems as a router connected to every other router by PVCs using some kind of CBR-like service. If I had bottomless pockets I would still design a maximally hierarchical network. Some routers would be connected to long-haul point-to-point circuits. Other routers would talk either via some sort of LAN thing or if money were no object, probably via POSIP. The idea would be to create a tree-like fan-out from the "backbone" routers (the ones with the long-haul circuits) to the "customer aggregation" routers, aggregating traffic and reachability information upwards from many customers towards a set of crunchy boxes with relatively few (but very fat) interfaces. The idea is to conserve the amount of work any given router has to do with respect to convergence, since that's a poorly-scalable hot-spot. In the past the hot-spot may have been the amount of traffic through a box, such that so few fat interfaces could be used that it was economically compelling to move that particular load into some sort of L2 switch and take the lumps wrt inherent routing scalability problems and the lack of conservation of configuration effort. Since there are existence proofs that this hot spot is now no longer economically insurmountable, and some much crunchier boxes are on the near horizon, the argument for using smart L2 fabrics at all is becoming weaker. > I never said it was the catch all / fix all. But, it is cheaper, and n our > environment, works well and affordably. Backhoes can only do so much > damage, and that is why one has backup ISDN or some > other means. ISDN does a lousy job of backing up 140Mbps worth of traffic... However, as I said in another message, I buy the argument that tariffs and vendor pricing (particularly cost/port for low-speed interfaces, modulo things like the CT-3 card) make fast-packet L2 fabrics attractive. What I don't understand is the "why route when you can switch?" assertion, and I'd love someone to explain it to me in simple terms. > In a high scale network (like BlueBlue Net), they have > several DS3 Frame Relay trunks leaving each PoP, so that > dismisses the backhow bit also. Something has to do the converging when the underlying physical topology changes, no? Sean. (out-of-touch former network hack) - -- Sean Doran <smd(a)ab.use.net> "Boy, you obviously don't have a clue!" -- Chad Skidmore, Datasource L.L.C.

2 1

Re: Another UUNET Explanation
by mmiller＠CBIS.COM 02 Jul '97

02 Jul '97

Well sorry for the "delay" but I was in Paris for some time ... OK .. "delay" IS THE ISSUE! Voice over IP ... etc can not take the long delay times that ATM and Frame Relay may inccure. It's the same reason high earth orbit sat comm is not good for that type of communication. ........ The "delay" of my exported X based Mailtool over a 64K line between the US and Netherlands is driving me crazy! |]

1 0

FW: Another UUNET Explanation
by jan.novak＠aliatel.cz 02 Jul '97

02 Jul '97

We provided Internet access over FR also. You have to look on FR like level 2 transport for IP - you are doing IP routing not above leased line but above FR. The customer do not take care, what he has inside, for provider it is great profit - we had one Cisco 4700 for at least 30 customers on one serial port without problems. When the customers have some more complicated. meshed netowork, it is profit even for them - the save money on ports and several leased lines or expensive multiplexed E1/T1 interfaces. ---------- Od: Joe McGuckin[SMTP:joe@via.net] Odesláno: 2. července 1997 1:34 Komu: nanog(a)merit.edu Předmět: Re: Another UUNET Explanation I've noticed that several of the larger networks use frame-relay. Why? Our experience with frame-relay with the local telco has had mixed results. What technical advantages does a frame-relay network have over an IP routed network? Thanks! Joe

1 0

Routing vs Switching (was Re: Another UUNET Explanation)
by smd＠clock.org 02 Jul '97

02 Jul '97

"Chris A. Icide" <chris(a)nap.net> writes: smd> A clumsy tech or a backhoe takes out a physical path smd> between two POPs, each of which contains several routers smd> that form part of this flat network. smd> What happens now? > Layer 2 heals itself, without the knowledge of layer 3. Layer 3 > experiences a latency increase between certain paths. > > Sorry, had to do it. > > *duck* Well, this is certainly the obvious approach, and is certainly in line with the generally reasonable philosophy of "degraded performance rather than no performance" response to partitions, assuming the routers don't notice a topology change. There are some interesting issues with respect to convergence at the L2 layer (rerouting VCs takes time too), and I've seen problems where the fast-packet layer converged slowly enough that IS-IS adjacencies were lost, causing really neat routing slosh as the VC went and came back. (To augment one of my own questions, when you have two routers in a full mesh (FR, ATM, whatever using VCs) and the VC between N-1 and N-2 goes out of service, how do N-1 and N-2 decide what path(s) to use to talk to each other? Feel free to consider a network using any commonly available IGP and the iBGP hack.) I also have some anecdotes about VCs improperly travelling along the same path for long periods of time because of configuration errors or unnoticed physical disconnectivities between switches. There have also been neat tales of VCs going simplex from time to time. Monitoring two networks simultaneously, fun fun fun... :) I'm sure there are people here with practical experiences who might be willing to share what they've learned. > however, in this fast paced industry, will we > ever have the "perfect" protocol (okay, ever is a big > word). IPv6 over ATM/LANE with RSVP will someday change the world. Sean. - -- Sean Doran <smd(a)ab.use.net> "Boy, you obviously don't have a clue!" -- Chad Skidmore, Data Source L.L.C.

2 1

Re: Topological significance of transport technologies
by smd＠clock.org 02 Jul '97

02 Jul '97

Paul Ferguson <pferguso(a)cisco.com> writes: > Its not really Layer 2 vs. Layer 3, its how to integrate the > two layers and make it work. Mike O'Dell is fond of saying, > "Pure Layer 3 routed networks are dead," So does this mean that Falternet is dead? Hmmm. Wait, it's not a pure layer 3 network. Go figure. > and I can understand his point, although I don't > necessarily agree with it. The point is not so much to use one or the other or to integrate the two as much as it is to duplicate some of the handy functionality in PVC-using L2 protocols. This is something cisco has been doing (bravo), what with generic rate-limiting, better flow diagnostics and monitoring, and the like. In current and newer products from cisco and others, I expect to see some buffer management strategies that will eliminate the need for the fancy stuff one finds in FR and ATM and the like. If one has decent IP routers, one can essentially build on an L2 structure no more complicated than point-to-point PPP or HDLC talking circuits, modulo what one does wrt stuffing an add/drop MUX of some nature into the router itself. This tends to avoid the need to do horribly botched and sometimes proprietary redesigns of L3 routing protocols such as IS-IS, and lessens the need to do particularly ugly things with BGP, as one sees in L3 networks layered on top of NBMA L2 protocols. In turn, one should expect better stability from such networks over time. Trying to integrate "foreign" internetworking technologies in the manner done by UUNET (whether or not this is Mike O'Dell's grand design or merely a step in that direction I honestly don't know) leads to all sorts of interesting trouble. > Yes, they both get you there, but the pertinent summary to be > drawn from this comparison is that 'you' are the IP packet, > and you really don't care what the mode of transport is (e.g. > frame-relay, leased point-to-point lines, ATM). Actually you do care when you're carrying TCP segments; for instance, if your L2 network is too clever and messes up TCP's expectation that you see packets delayed and dropped when you send too quickly, like say with ABR when you end up seeing a VS dropping cells (or cell trains or whatever interesting stuff the ATM people have come up with to try to un-break ATM's anti-TCP behaviours) because it hasn't seen an RM come back across an uncongested network -- similar ugly things happen with FR congestion management schemes -- you can get really abysmal TCP performance. Moreover, management of disconnectivity under separate control loops is suboptimal; if you heal partitions at the L2 level you get ugly congestion invisible to traditional L3 routing protocols, and if you heal at the L3 level, then there seems to be alot of wasted effort in nailing up lots of VCs in the first place. > Some have more intrinsic flexibility than others (e.g. > virtual circuits) and therefore represent a significant reason > to employ a specific technology over another, given pricing, and > geographic availability. I will buy the pricing issue. If it werent that Telco N is offering ATM at OC-3-ish rates for about a fifth the price of a 155Mbps SONET tributary, and a notorious equipment vendor making it expensive in terms of equipment to build a point-to-point network with adequate buffering, I would expect ATM would be much less popular in several ATM-using internetworks. > Again, IP packets don't really care if it's a motorcycle, an > airplane, or an automobile (unless its a Harley :-). IP doesn't like it when SAR messes up or when cells get dropped in the middle of frames. TCP doesn't like it when IP gets confused and it also doesn't like it when non-ATM-forum workarounds for that set of problems allows one to confront the problems of conflicting congestion-control vs. congestion-avoidance systems. Admittedly none of those are inherent in VC-using L2 fabrics, however, most of the deployment rationalizations I've run into wrt that kind of thing involve congestion management, QoS, better monitoring and various other unfulfilled promises that could well find their way into IP routers Real Soon Now, assuming they aren't there already. I will, however, buy the argument that equipment-unavailable or equipment-unworkable exigencies drove the deployment of things like ATM and FR, and that the deployment was useful to push various equipment vendors into building what would have made the ATM and FR deployments unnecessary in the first place. In other words, hey, vendor, I have a gun to my forehead. It seems less painful right now than what will happen if we don't get the things we need from you. Give me what I want or I'll shoot. *Bang*. > It should also be noted that some technologies, such as > frame-relay are used only in *topologically significant* > places, ie. customer aggregation, for precisely these > reasons. In some networks, frame-relay is used for > customer aggregation, fast-ethernet is used in the PoP, > and ATM is used in the wide-area (just an example). And in some networks DS3s carry aggregated clear-channel DS1s and fractional DS1s into customer aggregation boxes, the DS3s for those and for the customers come right out of SONET ADMs, and 155Mbps POSIP (soon to be faster) is used essentially everywhere else. Or so goes the plans... Which networks are having the problems today? :-) Sean. (who thinks self-inflicted gunshot wounds can be self-healed, too, when there is no longer any economic need to wander around bleeding...)

3 2