- Test - lists.nanog.org

Jon Postel (Flowers & Donations) (fwd)
by Forrest Houston 20 Oct '98

20 Oct '98

I thought some people here might be interested in knowing this. This is for general distribution so please forward it on to where you feel it is appropriate. Please remove my name though as I already get enough mail as it is :-) Thanks Forrest Houston USC/ISI - IPCe [cut here] ---------------- Forwarded mail ---------------------- Jon's family has issued the following statement regarding flowers and donations: In lieu of flowers... Two funds have been established by the Internet Society: one for an endowed chair at UCLA and the other to endow an award for someone whose service to the Internet honors Jon's memory. Checks can be sent to: Jonathan B. Postel Endowed Chair Fund or Jonathan B. Postel Service Award Fund Internet Society 12020 Sunrise Valley Drive Suite 210 Reston, VA 20191-3429 USA Tel: 703-648-9888 Donations may be also directed in Jon's name to: The Sierra Club 3435 Wilshire Blvd., Suite 320 Los Angeles, CA 90010 Tel: 213-387-4287 The California Arboretum Foundation 301 N. Baldwin Ave Arcadia, CA 91007 Tel: 626-447-8207 The Red Cross [any chapter in the world] ...or to any charity of your choice. You can electronically post a condolence message about Jon by sending it to postel-condolences(a)isoc.org. They're being collected and displayed at http://www.isco.org/postel/condolences.shtml ----------------------------------------------------

3 2

Re: WARNING: AOL is hosed (again)
by Sean Donelan 20 Oct '98

20 Oct '98

markb(a)infi.NET (Mark Borchers) writes: >Yep, somebody modified the delegation via a forged domain >modification email. An emergency root server update has been done to >correct the problem. Gosh, I wonder if NSI would do an emergency root server update for me. Perhaps it would be a good time to review the Guardian documentation. Is there a way to review what the Guardian settings are for various objects? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Data Center Design Mailing List?
by Jeffrey C. Ollie 20 Oct '98

20 Oct '98

I've been extremely interested in the discussion that has happened lately regarding design considerations for data centers. I'm interested in having some more detailed discussions on this subject but I'm not sure that NANOG is the best place for such a discussion. If there isn't a list already out there for this purpose I'd be willing to host a mailing list on a system of mine (assuming that enough people participate). Comments? Jeff

2 1

NetEdge NES8000
by brandon＠rd.bbc.co.uk 20 Oct '98

20 Oct '98

I saw these mentioned a while ago, do people still use them? We have one we no longer need (seems a waste to bin it), would it be useful to anyone for spares? It's an 8000-00 rev c chassis with 3 * 4 port 10M AUI cards 8000-101 and the more useful bit a 8000-119 ATM card. Regards, brandon -- Brandon Butterworth phone: 01737 836592 BBC Research & Development fax: 01737 832336 Kingswood Warren, Tadworth email: brandon(a)rd.bbc.co.uk Surrey, KT20 6NP URL: http://www.bbc.co.uk/

4 3

Internet2 project
by Lou Camaratta 20 Oct '98

20 Oct '98

Hi, I'm a senior at the University of Pennsylvania. Myself and two other students are currently working on our senior design project. We are trying to design a process/method for the handling of trouble tickets for Internet2. Some of the issues we are trying to address are: tying existing trouble ticketing systems from various universities together; interaction between universities, GigaPoPs, and the 2 ISPs (Qwest and VBNS); structure of the ticketing system (access rights, handling procedures, etc. For those of you familiar with I2, we would be very grateful for any feedback you could provide. In addition, any information that you could provide concerning trouble ticket systems for high speed WANs would be greatly appreciated. All information will be used only for research purposes and will be kept confidential. Thanks for your time. Lou Camaratta - camaratt(a)seas.upenn.edu

2 1

Re: They pulled a BIFF
by Kelly J. Cooper 20 Oct '98

20 Oct '98

Early 1990's, when I was at Rutgers in NJ, we called it: "Backhoe-Induced Deep Fade" Kelly J. On Oct 20, 7:27am, TTSG wrote: > Subject: They pulled a BIFF *Hi, * * I was wondering if anyone has heard of the following term. I *received it as a notification of an outtage from a vendor : * *At 5:35 CST, October 19, 1998 our AT&T backbone had 23 T-3's cut by a *contractor. This caused a massive BIFF (Backhoe Induced Fiber Failure). * * Tuc/TTSG * >-- End of excerpt from TTSG

1 0

Re: Jon Postel (Flowers & Donations) (fwd)
by Forrest Houston 20 Oct '98

20 Oct '98

Oops! Sorry about that, someone just sent a correction for the URL. It should be: http://www.isoc.org/postel/condolences.shtml Forrest On Tue, 20 Oct 1998, Forrest Houston wrote: > > You can electronically post a condolence message about Jon by sending > it to postel-condolences(a)isoc.org. They're being collected and > displayed at http://www.isco.org/postel/condolences.shtml > > ---------------------------------------------------- > >

1 0

Re: IP address space management
by Brian Dickson 20 Oct '98

20 Oct '98

> > Use "tree". > Actually, given IANA's current requirements, and most ISP's desires to abide by both the letter and intent of these guidelines, I'd have to day, "don't". The reason is, tree is a program designed to allocate 'growable' blocks, which translates into deliberately anti-optimal allocation. (Apologies to the authors for any perceived negativity - tree does what it was intended to do, wonderfully - it's just the opposite of what IANA says to do.) This maximizes the number of holes, while minimizing the hole size. At a very early point in allocation, you stop being able to allocate blocks, when your density is basically minimum. To keep IANA happy, and to cause maximal-density usage of CIDR blocks, what should be allocated is un-growable blocks, just big enough for customer needs. This ensures that once the CIDR block is allocated-out, density is sufficient to justify trivially another CIDR block. This is basically a space-packing problem, which while non-trivial, yields solutions which are quite simple to code. The general process is as follows. To do this, you want to avoid breaking up any 'holes', so that you will most likely be able to accommodate the needs of any customer, big or small. If you have an unused power-of-two chunck which exactly fits your customer's needs, give it to them. If not, break up the smallest "hole" bigger that they need. This minimizes the number of "holes", maximizes "hole" size, and maximizes probability that all customers needs will be met, and that all holes will be used before you need to get another block to meet new needs. At a previous employer, I developed a perl script to do just this. I'll see whether it's possible to get them to release this code to the public domain, since they aren't using it (my previous employer was acquired (read: absorbed) by PSInet, and all engineering and associated development is now done by PSI, with any prior work non-PSI code basically abandoned (or so I am lead to believe). > Brandon Ross wrote: >> We are in need of a software package to manage our IP space. We've looked at >> several products on the market but haven't found anything that really suits >> an ISP's needs very well. Does anyone know of anything on the market that >> works well? It should understand CIDR and be hierarchical. I guess the question would be, what is meant by hierarchical... do you mean assigning sub-CIDR blocks to customers, and then managing customers' space as well as your own? CIDR and VLSM goes without saying... -- Brian Dickson, Email: briand(a)teleglobe.net Teleglobe USA, Inc., Tel : +1 703 821 4818 Suite 400, 8251 Greensboro Drive, Fax : +1 703 821 4885 McLean, Virginia, USA, 22102 http://www.teleglobe.com

4 3

They pulled a BIFF
by TTSG 20 Oct '98

20 Oct '98

Hi, I was wondering if anyone has heard of the following term. I received it as a notification of an outtage from a vendor : At 5:35 CST, October 19, 1998 our AT&T backbone had 23 T-3's cut by a contractor. This caused a massive BIFF (Backhoe Induced Fiber Failure). Tuc/TTSG

3 2

Is ripe allocating /24's?
by Sean Donelan 20 Oct '98

20 Oct '98

A provider has made the claim to me that RIPE is allocating /24's addresses to various European providers. Is this true? What affect does this have on providers with prefix-length filters? Or is this provider just mis-reading the RIPE allocation database. It isn't always clear at what point RIPE has delegate something, and at what point a provider has registered a more specific route since the delegation and routing database appear to be merged in the RIPE model. And in fact the RBnet could aggregate many of these announcements. > Network [...] > *>i62.76.0.0/22 [...] > *>i62.76.4.0/23 [...] > *>i62.76.6.0/23 [...] > *>i62.76.8.0/24 [...] > *>i62.76.122.0/24 [...] > *>i62.76.124.0/23 [...] > *>i62.76.128.0/23 [...] > *>i62.76.130.0/24 [...] > *>i62.76.136.0/23 [...] > *>i62.76.144.0/21 [...] -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

6 5