- Test - lists.nanog.org

APRICOT Announcement
by Geoff Huston 24 Nov '95

24 Nov '95

There are a number of reasons for posting this announcement here: - Hans-Werner asked me to, - the weather in Singapore at that time of the year will be much warmer than _anywhere_ on the North American continent, - it will be an interesting operational workshop! cheers, Geoff Huston CALL FOR PARTICPATION In The First - - - - - - - A P R I C O T - - - - - - - ASIA PACIFIC REGIONAL INTERNET CONFERENCE ON OPERATIONAL TECHNOLOGY http://www.apricot.net/apricot/ Jan 17-22 '96, Singapore Sponsored In Part By: * The Commercial Internet Exchange ( http://www.cix.org/ ) * & Others T.B.A. shortly SUMMARY: APRICOT is a forum for the exchange of technical know-how for In- ternet Service Providers and Network Operators OVERVIEW: The rapid growth of the Internet has brought many newcomers into positions of critical operational responsibility. They are ex- pected to be experts in the design, configuration, operation and maintenance of routers, terminal servers, WWW & UNIX servers, and a myriad of specific hardware/software systems. They must operate network management centers, customer support lines, and handle security incidents. They must liase with network registries, com- munications carriers, and their colleague operators. They must perform these duties efficiently even as their networks grow in- creasingly large and complex. Yet, the resources for learning the skills necessary to perform these tasks successfully are sparse and rarely provide specific information and examples. To address this critical need, the ASIA PACIFIC NETWORK INFORMA- TION (APNIC) has initiated the ASIA PACIFIC REGIONAL INTERNET CONFERENCE ON OPERATIONAL TECHNOLOGY (APRICOT). APRICOT consists of seminars, conference sessions, and forums all with the goal of spreading and sharing the specific technical in- formation required to operate the increasingly complex Asia Pa- cific Internet topologies. APRICOT will be held immediately preceding the APNIC general meeting and the Asia Pacific Networking Group (APNG) meetings which includes the commercial sub-group and the internationaliza- tion and localization subgroup meetings. VENUE: SEAMEO Regional Language Centre (RELC), Singapore SCHEDULE: * Jan 17 Tutorials from invited speakers. * Jan 18 Conference * Jan 19 Morning: Conference Afternoon: Forum * Jan 20 APNG-commercial * Jan 21 APNIC Asia Pacific Network Information Center meeting * Jan 22 APNG Asia Pacific Networking Group general meeting (being organized separately) APRICOT TOPICS: * IP and ASN Addressing issues & techniques * Exterior and Interior Gateway Protocols and Interexchanges * Telco DDN Systems * Domain Name Server * Usenet News * WWW, FTP, Shell, & Email Servers * Server and Network Security * Billing & Accounting Systems INVITED SPEAKERS FOR TUTORIALS The APRICOT organizing committee is inviting world-recognized ex- perts to lecture on the above topics. CALL FOR PRESENTATIONS Presentations on the above or related topics are solicited from from the Internet operations community. Presentations should present your experiences with the above is- sues and share solutions to them. VENDOR EXHIBITS Space for up to 10 Vendor booths will be available. ATTENDEE REGISTRATION: USD175 CLOSE DATES FOR PRESENTATION ABSTRACTS: To Be Announced ORGANIZERS, CONTRIBUTORS * APNIC * Cogwheel Internet Technolgy Consulting * Singapore Computer Society * Internet R&D Unit, ComCen, National University of Singapore * SingNet * Internet Association of Japan * National Computer Board, Singapore SPONSORS * Commercial Internet Exchange ( http://www.cix.org/ ) * Others T.B.A. shortly. INFORMATION / PRE-REGISTRATION Browse the following WWW URL to join the apricot information email list. We will send you more detail shortly. http://www.apricot.net/apricot/register.html/ SUBMISSIONS / SPONSORSHIPS Send email to: apricot-oc(a)apricot.net ----

1 0

Re: Westnet and Utah outage
by Scott Bradner 23 Nov '95

23 Nov '95

> The IETF is essentially a protocol standardization group, not > an operations group. As one of the ADs in the Operational Requirements area of the IETF I'll second what Hans-Werner said. The Operational Requirements area is designed mostly to be able to provide feedback to protocol developers about what happened when a new protocol was tried out in the real world. It also can house efforts to establish measurement methodologies and has been used as a meeting place and self help group for people who are deploying some technology. There is a new effort in the IETF working on figuring out what to measure to gage the QoS of a network (the IPPM effort in the Benchmarking Methodology Working Group) but Mike O'Dell (the other AD) and I made it very clear that the working group could talk about termonology, methodology & even tools but could not start saying what a "good" or a "bad" service would be. Bestowing good housekeeping awards on Internet providers can not be the task of an organization that has the level of participation that the IETF does from the Internet providers. There are a number of legal issues here. If someone would like to start up an Internet users group, I'd sure be interested in watching the mailing list discussions but the IETF would not be a good home for such a group. Scott

1 0

Subscribe
by James D. Butt 'J.D.' 23 Nov '95

23 Nov '95

subscribe jbutt(a)mwci.net ----------------------------------------------------------- James 'J.D.' Butt Voice 319.557.8463 MidWest Communications, Inc. fax 319.557.9771 241 Main St. jbutt(a)mwci.net Dubuque, IA 52001 ----------------------------------------------------------- "I used up all my sick days... so I'm calling in dead"

1 0

Re: Utah outage (fwd)
by Sean Doran 23 Nov '95

23 Nov '95

Chris - Thanks for your note; you're right on the ball. 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. Why so many people want to see my rantings and ravings is beyond me though. :-) Sean.

6 5

Seeing Double
by Scott Huddle 23 Nov '95

23 Nov '95

There is an often quoted statistic of the Internet doubling every 12 months. If we look at a snippet of data from the old NSFNet data from ANS, we can see this pretty clearly... Month Inbound Gigapackets/mo 9409 36 9410 44 9411 45 9412 46 [...] 9409 71 9410 85 9411 90 9412 78 9501 71 9502 57 9503 64 9504 36 (the decrease after November due to the different NSF regionals transitioning to their new providers) While it was never possible to have a view of all of the traffic on the Net, these NSFNet stats were useful as a representative sample of the entire whole. In particular, this doubling time is quite useful as a metric to try and judge general network growth and for planning. Obviously several things in the past year have occured that have greatly shortened this time. Amongst them the explosion of Web traffic and interactive applications, the huge number of new companies connecting their coporate LANS to the Net, the [I'm running out of synoymns for enormous, ah] enormous number of new companies selling and promoting Net and Web services. This is coupled with the big increase in infrastructure that ISPs and NSPs have built that help move all these bits about. I've see a few guesses on this list as to a doubling rate, but I'm wondering if there is a way to judge this growth in some sort of external and non-proprietary way. Perhaps a relationship between "average traffic" and the number of routes? This probably wouldn't hold in the specific (because of the degree of use of CIDR at a particular ISP), but may hold in the aggregate. Thinking caps? -scott (huddle(a)mci.net) MCI Internet Engineering

3 2

outages, quality monitoring, trouble tickets, etc
by William Allen Simpson 23 Nov '95

23 Nov '95

A bit of a rambling note, as I catch up with the unusually busy lists.... > From: Scott Huddle <huddle(a)mci.net> > 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. I firmly DISAGREE! None of us are particularly interested in hearing every jot and tittle about every network flap, but _BIG_ ones and their resolution are important to bring to this list! How else to get a handle on what the real problems are? How else to help each other avoid repeating the problem in the future? ---- As to the current state of the 'net, I have to agree whole-heartedly with Hans Werner (something I rarely did when he was around here....) The mindset in NANOG is pretty useless. It would be nice if folks stopped beating around the bush, worrying about "competitive" issues, and started cooperating! Leave the competitive posturing to the marketing departments. Fixing problems usually means focusing on a particular case. If analysis of the problems of a particular ISP/NSP shed some light on the resolution of a bigger scope, then a little embarrassment is a small price to pay; it's not fatal -- failing to fix the problem is fatal! ---- As to the earlier discussion about Frame Relay instead of direct links, my experience is that F-R within a LATA between a few routers is working reasonably well, but inter-LATA and wider is working poorly, and more than 5-6 routers is a disaster. Most of my recent link problems that can be pinpointed enough to trouble ticket have been directly due to F-R, primarily at PSI. A couple of weeks ago, they lost the entire Great Lakes area, and didn't notice for over 4.5 hours. And took another 6 hours to fix. They never did tell me the final solution. So, based on experience, I don't recommend F-R for long haul links. It's just not good enough! ---- One of the reasons that ISPs are flapping is the lack of Link Quality Monitoring. You can easily tell when the link is degrading, with very accurate reports on a packet or byte basis. This is particularly important for F-R links, as the switches don't seem to tell each other when the link is down. I was surprised to learn that some folks weren't using PPP LQM on high speed HDLC links. That's why we originally designed it! PPP also runs over F-R links, even if all you use it for is LQM. After 4 years, we are finally getting around to raising PPP LQM for Draft Standard, but it is pretty widely implemented.... Insist on LQM from your router vendors! ---- Has anybody else noticed how hard it is to get trouble tickets these days? Once upon a time, I just called the NSF NOC, and got a report to them in real time, so the problem could be fixed quickly. Nowadays, NOCs seem to want you to send email with 24 or 48 hour turnaround, or go through 2 layers of service representatives. Pretty hard to send email to them when their link is down, or go through "regular" support in the middle of the night! We really need more folks like MCI with an 800 number. I've found them very responsive. But then, I've also found that they have fewer problems than other ISPs I've dealt with lately. Maybe that's because they get faster problem reports? (See, I can give compliments, too.) Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: Westnet and Utah outage
by Sean Doran 23 Nov '95

23 Nov '95

HWB - You make some very important points through your frustration, the most key of which is this one: "...if someone points a finger at your competitor, don't be too happy about it. You may be next". Unfortunately with the available technology and labour pool, there is no entity which could provide a very clean global Internet, period. There is no organization you can pay more money to that will improve your general-case performance, unless your general-case utilization is really much more like a VPN than the Internet. That is to say, if what you're looking for is high performance to sites X, Y and Z, and OK current-Internet performance to everywhere else, there are several options open to you, one of which is putting X, Y, and Z on a VPN and hooking each of these sites individually to the Internet. This is something that Sprint Managed Router Networks does all the time and is very good at, and is essentially what (modulo policy) the vBNS is for. However, with respect to the Internet, anybody who tells you that they can provide a better quality of service, connectivity-wise, than their equivalent competitors is either lying or in for a really big shock. As to your other points, I'm not sure how to address them, but I think you probably have some ideas you'd be willing to share... :) Sean.

3 2

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