- Test - lists.nanog.org

Re: Utah outage
by Sean Doran 23 Nov '95

23 Nov '95

On that note, NSI was key for us figuring out what was really going on at MAE-EAST wrt the outages there. Sean.

1 0

Re: Westnet and Utah outage
by Joe Provo 22 Nov '95

22 Nov '95

[clip] >>It looks in this >>case however like people want me to yell on the sprint outage list rather >>than here so I'll check out the possibility of doing that. Do you guys >>have an outtage list I can join? My apologies if I have offended anyone. Gordon, you're taking my comments a bit differently than intended. More of a "outage was notified and then commented when closed" than a "go yell there". The current outage list at sprint is light-years better than the old sl-<mumble> lists where no traffic lived. My point was that if you want to know the specifics for a suppliers outages, go get on their list[s]. When in doubt, go off an VRFY some standard list-managers at the mail-hosts you see people's mail coming from. IMO, nanog is like a mega-NAP for the humans involved... a meetpoint, not a notification list. [clip] >the main processor." Give me a working network, better tools, or SHUT >THE HELL UP AND GO BACK TO FARMING. I will be glad to shut up myself, >once you get your act together and provide smooth and transparent >network services. > >Obviously I am able to send much more polite notes, but I am really >getting sick and tired of this lousy performance and degrading network >service qualities. I think this may be the first case *for* decaf. [hwb, if you want to flame, then please direct to <flamage(a)rsuc.gen.ma.us>. I'll deal with it when there's time. Or delete it. none of us need it here.] Seriously, though, while we _are_ seeing the impact of the End of NSFnet and the insane increase in day-to-day, joe-average network usage, it was obviously impending and affects everyone, anywhere and ranting will do no-one no good. >*At least* let people know if things are broken, so they look for >alternatives (be it a cup of tea if short term, or another service >provider if persistent). Again, all providers have [at least private] outages-lists. Some of them only have them as part of their normal local annoucements, but that's due to change RSN according to my crystal ball... we all affect each other so much that we all will benefit, at least in exchanging outage data with near neighbors. Perhaps "known outage lists" would be a good appendix to the FAQ-in-progress? I like the idea of a meta-list, but it would have to be out-bound only [to be useful] and then you're starting to establish "who is important enough to be allowed" or "who/what method for moderation" etc etc... No-one's got time for that. What gets me is when you said earlier: >I suspect at least 80% of the problem is non-technical, but >abministrative and mindset. On what do you base this suspicion? Everone working on these things has to work on facts and tangibles. "It's broke! Fix it!" is less useful than looking down the fiber jumper to see what's clogging the data. Anyway, here's to second mo's comment; may your pagers not go off while carving the [turkey|tofu]. Cheers, Joe Provo Network Operations Center UltraNet Communications, Inc.

2 1

Re: Utah outage (fwd)
by Brett D. Watson 22 Nov '95

22 Nov '95

> You know if Sprint is gutsy enough (maybe customer centered would be a > better word?) to do this, why can't MCI? I had private mail today from a > network manager at a major MCI customer lamenting that the MCI higher ups > refused to allow MCI to show their customers this courtesy (creation of an > MCI outtage list). Is this attitude part of what HWB was complaining about? i dont' think anyone at mci is refusing to do this. we've had many customers and even non-customers ask for this and i've passed this on to management. i do believe mci's provisioning group is working on making this happen in the near future. it certainly is a good idea. (these comments do not necessarily reflect those of mci) -brett > ******************************************************************** > Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 > The COOK Report on Internet Non Profit. $150 > 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 > (609) 882-2572 Corporate $350 > Internet: cook(a)cookreport.com Corporate. Site Lic $650 > Newly expanded COOK Report Web Pages http://pobox.com/cook/ > ******************************************************************** > > > On Wed, 22 Nov 1995, Walter O. Haas wrote: > > > Sean wrote: > > > outage-request(a)sprint.net I believe typically will subscribe > > >anybody who's interested. There are several sizeable lists > > >which are on the exploder here, so adding more probably is a non-issue. > > > > Make that: > > > > To: majordomo(a)sprint.net > > > > with message text: > > > > subscribe outage > > > > -- Walt > >

1 0

Re: Westnet and Utah outage
by Scott Huddle 22 Nov '95

22 Nov '95

Gordon, I'm sorry if I misinterpreted your note, but you seemed to be trying to suggest exactly that. In one breath you excuse yourself from pointing one finger in hopes that people don't notice the other arm wildly gesturing the other way. Its quite disengenous to state otherwise. It wasn't appropriate for you to do this to Sprint and it wouldn't be appropriate to do this to anyone else, either. I consider this list a place for ISPs to discuss general policy and planning issues that effect all of us. It is a very inappropriate place to discuss problems with a specific provider. If you have a problem with a specific provider, whether it be Sprint, or ANS, or MCI, or podunk-ISP, it would seem to me that it would be most appropriate to be talking to them directly rather than shouting to the wind. As to the rest, this is a competitive market with lots of fine service providers both national, regional, and local with more coming on board all the time. Some problems we will all face and other problems will be provider specific. This list has always been appropriate and useful to discuss the first, lets stick with it. -scott (huddle(a)mci.net) Gordon Cook <gcook(a)tigger.jvnc.net> writes > Scott asks: > > So this is to imply that you do have a problem w/ Sprint and that > you are picking on them in a specific way? > > COOK: your suggestion scott not mine.......

1 0

Utah outage (fwd)
by Gordon Cook 22 Nov '95

22 Nov '95

Anyone know what happened this time? ---------- Forwarded message ---------- Date: Tue, 21 Nov 1995 21:55:09 -0700 (MST) To: cook(a)cookreport.com Subject: Utah outage (fwd) Forwarded message: >From spot.Colorado.EDU!westnet-site-people-request Tue Nov 21 12:59:14 1995 From: Chris Garner <cgarner(a)westnet.net> Message-Id: <199511211925.MAA15849(a)ubu.colorado.edu> Subject: Utah outage To: westnet-site-people(a)westnet.net Date: Tue, 21 Nov 1995 12:25:23 -0700 (MST) X-Mailer: ELM [version 2.4 PL24alpha3] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit OUTAGE: Westnet in Utah All Westnet sites in Utah are currently down. The SprintLink lines from the University of Utah are all down due to the loss of SprintLink's Stockton 9 router. The lines went down at 11:20am. Backup routing through Idaho is running, but the T1 from Utah to Idaho is severely overloaded by the Utah traffic, meaning the sites are effectively down. -- -Chris (cgarner(a)westnet.net)

2 1

Westnet and Utah outage
by Gordon Cook 22 Nov '95

22 Nov '95

small clarification. I have no problem with westnet and do not mean to be picking on it in anyway. I have a friend who lives in westnet's service area who gets bothered by these outages and passes them on to me. ******************************************************************** Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 The COOK Report on Internet Non Profit. $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook(a)cookreport.com Corporate. Site Lic $650 Newly expanded COOK Report Web Pages http://pobox.com/cook/ ********************************************************************

1 0

MBONE ENGINEERING heads up!
by Matt Mathis 21 Nov '95

21 Nov '95

I think some of the items in the plan below may be of interest/concern to the NANOG community.... If you will be in Dallas, you might want to attend. Sorry about the duplicate posts. --MM-- ------- Forwarded Message To: mbone(a)ISI.EDU, idmr(a)cs.ucl.ac.uk Cc: dino(a)cisco.com, deering(a)parc.xerox.com Subject: MBone Engineering BOF in Dallas Date: Tue, 21 Nov 1995 11:33:01 PST Sender: Steve Deering <deering(a)parc.xerox.com> From: Steve Deering <deering(a)parc.xerox.com> Message-Id: <95Nov21.113307pst.75270(a)digit.parc.xerox.com> [This message is being sent to both the mbone and idmr mailing lists; please post any follow-ups to the mbone list only.] An MBone Engineering BOF has been scheduled for the Dallas IETF, on Monday evening from 7:30 to 10:00. It will be chaired by Steve Deering and Dino Farinacci. The purpose of the BOF is: (1) to identify what problems need to be addressed and what steps need to be taken to evolve the current "experimental" MBone infrastructure into a ubiquitously-available, "native" IP multicast service in the Internet, (2) to learn the status of current and planned solutions to the outstanding problems, and (3) to begin planning for the deployment of those solutions. Like any IETF BOF, anyone is welcome to attend, but we particularly solicit participation by Internet service providers and IP multicast implementors. We invite ISPs to give brief (5 minute) presentations on what they see as the issues and obstacles to deployment of native multicast in their networks, and we invite implementors of IP multicast infrastructure technology (e.g., routing protocols, management and diagnostic tools, traffic management algorithms) to give brief (5 minute) status reports on their implementations. The BOF will be 'cast on the MBone (of course) to try to enable participation by those who cannot attend in person. Here is a tentative agenda; if you have any changes or additions to suggest, or if you are willing to give a presentation, please send mail to deering(a)parc.xerox.com and dino(a)cisco.com. o ISP presentations -- possible issues/topics: - ISP plans for / experiments with native multicast - un-met software requirements - routing, mgmt tools, etc. - need for hardware upgrades? - traffic management/congestion concerns - bandwidth availability forecasts - vulnerability to misconfiguration, "storms", etc. - other? o status reports on management and debugging tools - multicast debugging architecture - Van Jacobson - SNMP support for multicast - Dave Thaler - multicast traceroute - Bill Fenner - IGMP-based router info messages - Bill Fenner - other? o status reports on multicast routing implementations - 3Com - ?? - Bay - ?? - cisco - Dino Farinacci - PARC - Bill Fenner and/or Steve Deering - USC - ?? - SGI? Sun? Digital? UCL? Alantec? other? o status reports on multicast traffic management mechanisms (for best-efforts traffic only, i.e., excluding resource reservation approaches, which are being addressed in other forums) - multicast rate limits and priority dropping - Deering - administrative scope control - Jacobson? - RED? - other? o next steps for growing/improving the MBone - replacing tunnels with native multicast forwarding wherever possible. - using DVMRP routing through transit PIM clouds. - using route aggregation and default routes in DVMRP. - scheduling an "MBone re-engineering week", during which no one is allowed to complain that the MBone isn't working. - configuring administrative scope boundaries around all organizations, and change sd, etc. to allocate appropriately-scoped group addresses. - banning the use of multicast routing implementations that don't correctly support pruning, mtrace, and longest-match routing, e.g., pre-3.3 mrouted kernels and pre-3.5 mrouted demons. - raising the 500 Kbps MBone bandwidth ceiling. - ... Steve & Dino ------- End of Forwarded Message

1 0

Re: Links on the blink - reprise
by Sean Doran 21 Nov '95

21 Nov '95

The jury is still very much out on whether layering IP on top of frame relay with frame relay switches providing the principal long-haul switching fabric and routers making decisions about which PVCs to direct IP datagrams into is a reasonable, scalable approach. There are several advantages to the approach, vis. greater port density, especially in terms of ports-per-dollar on most FR devices than on high-end Ciscos; the (perhaps safe) bet that a medium-size user and channel of routers might have more of an influence over the development and engineering of an FR vendor's Internet-oriented products than over Cisco; that an organization with expenditure limits on bandwidth and relatively long minimum term committment lengths on cross-country circuits could do better traffic management, particularly in the presence of multiple parallel DS1s, than a similar setup using either inverse multiplexors or load balancing; and the fact that using a mesh along these lines is something that readily can interoperate with a migration to clear-channel DS3s or other technologies, or from a melting-down cross-country ethernet-over-ATM or FR-over-ATM backbone. As well, there is the probability that the users of the model you're asking about have lots and lots of points-of-presence used in an effort to reduce backhaul costs, which get quite substantial as the numbers of customers grow. Also, having lots of POPs interconnected at varying bandwidths can make designing a topology that is friendly to routers a bit more difficult in some ways. The model generally also very neatly hides the underlying topology from the IP layer, rendering traceroute essentially useless as a means of diagnosing weird time asymmetries and the like. There may be 13 physical hops between A and B on a network using this model, but traceroute might reveal only two. This has some obvious advantages to the provider keen on hiding the design of its network from "outsiders", or even from its own customers. Key to the decision is the gamble that the switching ability of FR switches will compare with the switching ability of high-end routers in the same environment. This is not a gamble I am comfortable with, particularly as I have very strong ideas of how well an SSE-equipped 7000 can switch packets in a backbone environment, and so far have only early impressions about one variety of popular FR switch in a similar environment. Also key to the decision is a bet on how well the FR-switch-based networks will scale beyond multiple DS1s and DS3s, especially in comparison to routers. There are substantial disadvantages, too. In order to take advantage of the greater port-density(-per-dollar) on FR switches right now, the end user has to use FR, which is not always practical or desirable. The monitoring and management systems of all FR switching products with which I am familiar are not router-geek-friendly. PVCs can do strange things, as can underlying circuits, which one really wants the IP-switching layer to recognize and adapt to; at present there is effectively no practical means to do this in anything but a failure of a PVC. There is a serious management nightmare in maintaining anything approaching a full mesh in a large network, and it worsens if one pushes the routing decisions right out to the edges of a given network. Maintaining lots of PVCs has many of the well-known disadvantages of maintaining lots of standard iBGP neighbours or any other system in which involves configuration length, complexity or both approaching or equivalent to N**2. There are a number of other deeply technical questions about the model which remain the subject of occasionally heated speculation, but the bottom line is that nobody really knows how well it will work as this type of network grows really big, or even as heavily trafficked as SprintLink and InternetMCI. Finally, pushing the envelope of technology is hard work at all times; I believe a pragmatic approach is to push only n things at any given time where n is ideally the smallest possible number. Adding frame relay switching technology into the mix of things that backbone NSPs have to deal with already strikes me as asking for trouble. | PSI and UUNET have apparently been following this strategy with their | backbones for some time. Netcom has also come on board. Your information may be better than mine, but I gathered that UUNET has just recently migrated over to this model from the previous MFS-supplied technologies they had been using. Frankly, neither netcom nor PSI does sufficient traffic to learn anything interesting about how the model behaves under stressful conditions. Alternet's experience over the next few months will be enlightening. Sean.

3 2

Re: Links on the blink - what will/should mci & sprint do?
by Sean Doran 20 Nov '95

20 Nov '95

| Can a 7500 being fed a single routing view switch IP packts among 6 OC3 AIP | cards running point-to-point AIP-AIP OC3 links to other 7500s at reasonable | speeds, one wonders. If you change "Can" to "Will", this is unclear right now. What apparently is clear (at least to me) after much beating up of the 7500 series beta boxes we got to play with in ICM land and the 7500 series software in the Cisco test lab, is that SprintLink's plan to use 7500s in the four new cities (Atlanta, Kansas City, Cheyenne and Seattle) that will be on-line imminently is reasonable. Firstly the 7500s, even without the smarter technology cards in development by Cisco will currently handle the load requirements of those cities. Secondly since everything currently is done in the RSPs, we have opportunities to try quick and experimental changes to the IOS software at very low-levels that don't exist with the 7000+SSP (but presumably if the proofs-of-concept work really well we can get a port done). Thirdly, there are some very cunning ideas being proposed by various hardware people for making the 7500 do interesting things on the switching front that very probably will get the router to deal with the kinds of loads you're asking about. Finally, the key advantage of the 7500 is the much better ports-per-dollar and ports-per-rack numbers over the 7000s using current technology, and even better numbers as Cisco rolls out the type of channelizing hardware we have been asking for. Specific performance questions wrt the Cisco 7500 series should probably be asked through your favourite Cisco information channels. I'm pretty sure everyone's going to find out how well 7500s work in practice, backbone-wise, Real Soon Now. The big risk, naturally, is that the platform just doesn't hold up in practice, which would force us to do a redesign along the lines of what Gordon has been asking about. Frankly, though, I'm not too worried. Many very smart people have put alot of work into making sure the 7500 doesn't become a complete corporate embarassment for Cisco. Sean.

4 3

Re: Links on the blink - what will/should mci & sprint do?
by Sean Doran 20 Nov '95

20 Nov '95

| Sounds like there is a need for a good ip switch. Something simple, | very fast, and low cost that you can download "static" routes to. It's called an SSP. Sean.

4 4