September 2005 - Test - lists.nanog.org

Hurricane Rita targeting Texas Gulf Coast
by Fergie (Paul Ferguson) 21 Sep '05

21 Sep '05

This looks really bad, folks. - ferg (in Austin, TX) [snip] 000 WTNT63 KNHC 212351 TCUAT3 HURRICANE RITA TROPICAL CYCLONE UPDATE NWS TPC/NATIONAL HURRICANE CENTER MIAMI FL 650 PM CDT WED SEP 21 2005 ...RITA BECOMES THE THIRD MOST INTENSE HURRICANE ON RECORD... DROPSONDE DATA FROM AN AIR FORCE RESERVE UNIT RECONNAISSANCE AIRCRAFT AT 623 PM CDT...2323Z...INDICATED THE CENTRAL PRESSURE HAS FALLEN TO BELOW 899 MB...OR 26.55 INCHES. THE DROPSONDE INSTRUMENT MEASURED 32 KT/35 MPH WINDS AT THE SURFACE...WHICH MEANS IT LIKELY DID NOT RECORD THE LOWEST PRESSURE IN THE EYE OF RITA. THE CENTRAL PRESSURE IS PROBABLY AT LEAST AS LOW AS 898 MB...AND PERHAPS EVEN LOWER. FOR OFFICIAL PURPOSES... A PRESSURE OF 898 MB IS ASSUMED... WHICH NOW MAKES RITA THE THIRD MOST INTENSE HURRICANE IN TERMS OF PRESSURE IN THE ATLANTIC BASIN. SOME ADDITIONAL DEEPENING AND INTENSIFICATION IS POSSIBLE FOR THE NEXT 12 HOURS OR SO. RITA CURRENTLY RANKS BEHIND HURRICANE GILBERT IN 1988 WITH 888 MB AND THE 1935 LABOR DAY HURRICANE WITH 892 MB. [snip] http://www.nhc.noaa.gov/text/refresh/MIATCUAT3+shtml/211955.shtml - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

3 2

RE: Don't Cache that check
by Hannigan, Martin 21 Sep '05

21 Sep '05

> > Somewhere, there's a shepard listening for your cries of "Wolf..." > > > > -doug > > Shouldn't a provider know their cache servers are "STORING" > copyrights. You demonstrate why companies need lawyers. And why this list isn't called "The Lawyers Operator Group". Did Vint mark you yet? -M<

1 0

RE: tli back in start-up mode...
by Susan Hares 21 Sep '05

21 Sep '05

Best of luck to Tony Li. Sue Hares -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Fergie (Paul Ferguson) Sent: Tuesday, September 20, 2005 9:37 AM To: nanog(a)merit.edu Subject: tli back in start-up mode... http://www.businessweek.com/technology/content/sep2005/tc20050920_0054_t c024.htm :-) - ferg p.s. BTW, good luck, Tony.

1 0

MCI refusing to turn up OC-3 due to katrina relief efforts?
by Drew Weaver 21 Sep '05

21 Sep '05

Howdy, has anyone heard of MCI putting orders on hold in order to help with the Katrina relief effort? We ordered an OC-3 from them about 2 months ago and they've missed the install deadline 4 times now. The reseller we're working with said that they claim that they can't turn it up due to Katrina relief efforts. The local loop is installed and the port is connected, they just cant turn the order up. Has anyone else heard this or should I assume (as usual) the reseller is BS'ing me? -Drew

4 3

Don't Cache that check
by J. Oquendo 21 Sep '05

21 Sep '05

Might or might not be offtopic: 1. Plaintiffs are published authors and The Authors Guild, the nation's largest organization of book authors, which has as its primary purpose to advocate for and support the copyright and contractual interests of published writers. The authors' works are contained in certain public and university libraries, and have not been licensed for commercial use. 2. Defendant Google Inc. (.Google.) owns and operates a major Internet search engine that, among other things, provides access to commercial and other sites on the Internet. Google has contracted with several public and university libraries to create digital "archives" of the libraries' collections of books, including that of the University of Michigan library. As part of the consideration for creating digital copies of these collections, the agreement entitles Google to reproduce and retain for its own commercial use a digital copy of the libraries' archives. http://wendy.seltzer.org/media/AuthorsGuild-v-Google.pdf I wonder what this will do for you ISP guys out there that use Cache servers. Technically if the suit holds, your company too would be violating laws. Which makes me wonder... If I listened to say a streaming audio clip of an unreleased album... That album goes to my computer's cache, can I be sued if I turn around and sell my cache. ;) =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x97B43D89 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x97B43D89 "Just one more time for the sake of sanity tell me why explain the gravity that drove you to this..." Assemblage

7 6

RE: MCI refusing to turn up OC-3 due to katrina relief efforts?
by Peering 21 Sep '05

21 Sep '05

I agree. We just turned up an OC3 with them the day before yesterday, with no issues. Diane Turley Sr. Network Engineer Xspedius Communications Co. 636-625-7178 -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Henry Linneweh Sent: Wednesday, September 21, 2005 3:40 PM To: Drew Weaver; nanog(a)merit.edu Subject: Re: MCI refusing to turn up OC-3 due to katrina relief efforts? that would be very uncharacteristic of MCI to do that, and they do have a katria team down in that area working on restoring all services. Your client would know via his sales rep what the implementation team is doing and pressures would be brought to deal with that kind of problem, I think someone is clowning you -Henry --- Drew Weaver <drew.weaver(a)thenap.com> wrote: > > Howdy, has anyone heard of MCI putting orders on > hold in order to help > with the Katrina relief effort? We ordered an OC-3 > from them about 2 > months ago and they've missed the install deadline 4 > times now. The > reseller we're working with said that they claim > that they can't turn it > up due to Katrina relief efforts. The local loop is > installed and the > port is connected, they just cant turn the order up. > > Has anyone else heard this or should I assume (as > usual) the reseller is > BS'ing me? > > -Drew >

1 0

Re: Don't Cache that check
by J. Oquendo 21 Sep '05

21 Sep '05

On Wed, 21 Sep 2005, Douglas Dever wrote: > It will have zero impact on people running caching servers... > > Please see points 2 through 5 in the nature of the action. > Specifically, "Google knew or should have known... to obtain > authorization from the holders of the copyrights in these literary > works before creating and reproducing digital copies of the Works for > its own commercial use..." > > Somewhere, there's a shepard listening for your cries of "Wolf..." > > -doug Shouldn't a provider know their cache servers are "STORING" copyrights. Definitions of Cache Server on the Web: A cache server (sometimes called a cache engine) is a server relatively close to Internet users and typically within a business enterprise that saves (caches) Web pages and possibly FTP and other files that all server users have requested so that successive requests for these pages or files can be satisfied by the cache server rather than requiring the user of the Internet. A cache server not only serves its users by getting information more quickly but also reduces Internet traffic. Again, you run an ISP. You run a cache server that stores something for easier retrieval from your end users. You should be following the law. Supposing some of your users paid for the right to access BookB so your cache server decided to cache it for quicker loading: http://cacheserver.foobarisp.com/9f3f65a2d28767c9cc2676dcf0e1dff7/BookB.pdf Somehow someone else along the `net` gets ahold of that cache's URL and reposts it to say a forum. Your ISP is now acting as a proxy to distribute (unbeknownst to the author) that book. How does that differ." Ignorance is no excuse" either way you cut it a law is being broken. So again I ask, how can this law apply to ISP's and those in the "networking" arena that serve content via cache servers. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x97B43D89 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x97B43D89 "Just one more time for the sake of sanity tell me why explain the gravity that drove you to this..." Assemblage

2 1

Upcoming Network Event: Rita
by Deepak Jain 21 Sep '05

21 Sep '05

Not to be a doomsayer, however if anyone is in the path of Rita and wants to reflect/replicate/duplicate any services out of the region in a sort of timely fashion, we're offering our services at *no charge* to any/all who think they could benefit -- including all of our Disaster Recovery services: Colocation, Bandwidth, Hosting, DNS as well as things like Mainframe/Supercomputer Replication, SAN extension, Call Center Redirection, Disaster Tree Execution, etc. Contact me off list. Hope everything goes well and none of this is needed. Deepak Jain AiNET

1 0

RE: [afnog] ARIN to allocate from 74/8 & 75/8
by Hannigan, Martin 21 Sep '05

21 Sep '05

> > > i.e. is there a pingable address in each, as has been > > discussed here just a few times? > > ping is ok, but routing table entry existence seems better. ping can > fail for lots of reasons and what we're really testing is routing, not > icmp end-to-end, right? There's a difference between reachability and routability. The lack of a routing table entry indicates a different problem which implicates routing and reachability problems. I don't agree that reachability is implied with routability. > if it's useful, i'd be happy to report what percentage of my peers > have/don't have routes to these prefixes. I'd be interested. Best, -M<

1 0

Re: [afnog] ARIN to allocate from 74/8 & 75/8
by Todd Underwood 21 Sep '05

21 Sep '05

> > > route-views and ris provide pretty good views of route propagation. > > > > > > but, as you seem to understand, that's only half the story. luckily, > > > the other, more useful, half is easily testable if arin/cymru would > > > just follow the long-discussed path. yep, that's clear. routing and firewalling may be orthogonal. obviously, without routing there is no forwarding and *many* people filtered announcements within 69/8. i acknowledge that many people also accepted the route and filtered traffic. my point was (as should have been clear) that the right place to *start* is routing. the other point i was making, about which i should have been clearer, is that willy-nilly pinging from random places won't really help much, as is probably obvious. it can identify gross unreachability problems but it cannot give a clear picture of unreachability across all of routed space (unless your willy-nilly sample happens to evenly cover all of routed address space--a neat trick!). an announcement to some mailing list asking whoever happens to be a member (and paying attention, with free time on her hands) to ping some addresses (or http or whtever) will also not give a complete picture. this has probably already been thought-out, but outbound reachability testing *from* the address block to a representative spread of addressing makes much more sense and would be much more indicative of forwarding (versus routing) problems, and would do so with some method and statistical reliability. presumably that is coming and just hasn't been discussed or carried out yet. for what it's worth, these three /20s appear to have no systematic unreachability problems across renesys's peerset. the first announcement we saw were quite some time ago: 22:37:43 UTC 22 Aug 2005 with paths ending 174 23028 36666 all three /20s showed up for *one* peer with a path that looked like that for almost 5 days while 23028 worked on allowing their upstreams to accept the announcement (reasonable speculation, not observed fact). 3561 starts accepting the announcements on 05:47 UTC 27 Aug 2005. a couple of other major networks on the 30th, and 31st August. lots of people follow suit the 2nd november, and then slow propagation throughout renesys's peerset. the most recent peer of renesys's peers to finally accept those /20s did so on at 00:08 UTC 21 Sep 2005 (today or tomorrow, depending on where and when you read this). i'm guessing that routeviews and ripe ris data have similar findings, although i have not checked them (left as an exercise to the reader? :-) i'd be happy to provide more detail if it seems useful. t. -- _____________________________________________________________________ todd underwood director of operations & security renesys - interdomain intelligence todd(a)renesys.com www.renesys.com

6 9