- NANOG - lists.nanog.org

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

ARIN to allocate from 74/8 & 75/8
by Leslie Nobile 21 Sep '05

21 Sep '05

Apologies for duplicate messages. ARIN will begin allocating IP address space from 74.0.0.0 /8 and 75.0.0.0 /8 within the next 2 weeks. ARIN was issued 74 /8, 75 /8, and 76 /8 by the IANA on June 17, 2005. Connectivity testing is currently being done by Team Cymru on the following three /20s (one from each /8). All of these test allocations originate with AS36666. 74.63.0.0/20 75.127.0.0/20 76.191.0.0/20 This is a reminder message that you may need to adjust any filters you have in place for these three blocks accordingly. For informational purposes, a list of ARIN's currently administered IP blocks can be found at: http://www.arin.net/reference/ip_blocks.html#ipv4 Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN)

7 7

Re: OT - Vint Cerf joins Google
by Fergie (Paul Ferguson) 21 Sep '05

21 Sep '05

Cool. That kind of goes hand-in-hand with Vint's Galactic Internet theme. :-) - ferg -- ops.lists(a)gmail.com (Suresh Ramasubramanian) wrote: For once I'll do a Fergie http://www.google.com/press/pressrel/vintcerf.html Vint's now Chief Internet Evangelist at GOOG srs -- "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/

38 70

Re: [afnog] ARIN to allocate from 74/8 & 75/8
by Fergie (Paul Ferguson) 21 Sep '05

21 Sep '05

May be? Is. Routing and forwarding _is_ a known policy issue in virtually all ASNs. - ferg -- Todd Underwood <todd(a)renesys.com> wrote: [...] 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. -- "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/

1 0

Re: router worms and International Infrastructure
by Fergie (Paul Ferguson) 20 Sep '05

20 Sep '05

If only there was a marked improvement in _this_ issue alone, it would be a vastly enormous step in the right direction... - ferg -- Valdis.Kletnieks(a)vt.edu wrote: [...] Keep in mind that the problem isn't the providers that already do altruistic things like BCP38, actually reading their abuse@ mailbox, and dealing with zombied users. -- "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/

1 0

Checkpoint contact
by J. Oquendo 20 Sep '05

20 Sep '05

Anyone from Checkpoint on the list contact me offlist on a vulnerablity I found for your firewalls. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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

1 0