- NANOG - lists.nanog.org

Re: Kremen's Buddy?
by Martin Hannigan 13 Sep '06

13 Sep '06

Michael [mumble] spewed: > >ARIN does have a way of figuring out that the space >is no longer in use. No, they don't. ARIN has problems around v4 allocation that need to be fixed for sure. I fit ras's mold of a person who is part of the machine and (I'll take a STEAK dinner ras, thank you) I disagree with some of his statements. Anyone could take someone elses documentation and exploit the system to some extent. I have a 105mb of zip you can use to acquire space if you need it _that bad_. You'd likely get the space as long as you changed some bits of information within it. I have found that the more legitimate your need the easier the process, right in line with membership expectation IMHO. Let use "volume" as the justification in this discussion and put it at at least a /16 for general purposes. Show up asking for the entire /16 you are going nowhere, but show that you have that many hosts that need access to the net and you are a service provider, you'll at least get started with something to get you on the road to a renumbering and return of provider space. It ain't that hard. How would you feel if along with the trust measure, some legal measures were added in? Perhaps this made it easy and eliminated the entire process of templates altogehter? - officers of applying companies sign a document stating that the demonstrated utilization is accurate and that the IP's will be used for purposes in compliance with Internet standards - companies agreed to have IP space allocation and utilization reviewed and certified by their auditors and results submitted to ARIN on a yearly basis as condition of use I'll see you in the lobby Sunday for my free trip to McCormack and Schmicks. ;-) -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan(a)renesys.com

1 0

Fwd: Blogger post failed
by Owen DeLong 13 Sep '06

13 Sep '06

Apologies to the list, but, I have no other way to contact the person who thought this was a good idea... Could whoever thought it was a good idea to gateway NANOG messages to a blogger please fix their blogger gateway or turn it off. Owen Begin forwarded message: > From: postgateway(a)blogger.com > Date: September 13, 2006 9:14:44 AM PDT (CA) > To: owen(a)delong.com > Subject: Blogger post failed > > Blogger does not accept multipart/signed files. > > Error code: 7.5CD98C > > Original message: > From: owen(a)delong.com > Date: Wed, 13 Sep 2006 08:56:30 -0700 > Subject: Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have > feedback?] > None

1 0

Qwest event 70 min ago?
by Charlie Watts 13 Sep '06

13 Sep '06

Did anybody see a Qwest "event" ~70 minutes ago? I'm not a direct customer so they won't talk to me, but we lost connectivity to a number of Qwest-connected sites for about 12 minutes. The data is falling off of the 1hr report, but you can still see it now: http://www.internetpulse.net/ http://www.internetpulse.net/Main.aspx?OriginValue=Qwest&OriginLevel=1 Thanks! -- Charlie Watts cewatts(a)frontier.net

3 3

Transport providers in UK
by Payam Tarverdyan Chychi 13 Sep '06

13 Sep '06

Hey guys, Looking for assistance in finding transport providers between either Amsterdam to Lisbon, or London to Lisbon. Preferably a wavelength service (OC48) providers that have a good track record would be fantastic! you can send all replies offlist Thanks, Payam T Chychi

1 0

NANOG 38 - Prelliminary Agenda
by Steve Feldman 13 Sep '06

13 Sep '06

Here's a very preliminary agenda for NANOG 38, October 8-10 in St. Louis. See http://www.nanog.org for more details. Also, a reminder that the early registration discount expires this Friday, September 15, and the hotel room block expires on Friday, September 22. See you in St. Louis! Steve Feldman PC CHair NANOG 38 - Preliminary Agenda (subject to change) Sunday, October 8 1:30 PM - 5:00 PM: Tutorials - BGP Multihoming Techniques - Philip Smith - Disaster Recovery and Global Site Load Balancing For Distributed Data Center Applications - Zeeshan Naseh, Cisco 5:00 PM - 7:00 PM: NANOG community meeting Monday, October 9 9:00 AM - 12:30 PM: Plenary I - Opening Remarks - How to Monitor SONET, TDM and Optical Transmission Devices Using TL1 and SMNP Monitoring Tools - Rachel K. Bicknell - Multi-Provider Ethernet Service Delivery - Ananda Rajagopal Foundry Networks - Peering Dragnet: Examining BGP routes received from peers - Tom Scholl, AT&T Labs, Aman Shaikh, AT&T Labs - Maximum-Prefix Tripping: The side effects of leaking on the Internet - Tom Scholl, AT&T Labs - Deployment Experience With BGP Flow Specification - Raul Lozano and Derek Gassen (Time Warner Telecom), Danny McPherson and Craig labovitz (Arbor Networks) 2:00 PM - 5:30 PM: BOFs - Peering BOF XIII - Bill Norton, moderator - ISP Security BOF - Danny McPherson, Arbor Networks, moderator 5:30 PM - 7:30 PM: Beer and Gear 7:30 PM - 10:30 PM: Informal BOFs - A meeting room will be made availble for informal BOFs on Monday evening. Signups will be taken on-site. Tuesday, October 10 9:00 AM - 12:00 PM: Plenary II - PHAS: A Prefix Hijack Alert System - Mohit Lad & Lixia Zhang (UCLA), Yan Chen & Dan Massey (Colorado State University), Beichuan Zhang (University of Arizona) - Securing SIP: Scalable Mechanisms For Protecting SIP-Based - Dan McBride, CloudShield; Somdutt B. Patnaik, Eilon Yardeni, and Henning Schulzrinne, Columbia University; Gaston Ormazabal, Verizon Labs; David Helms, CloudShield Technologies - Resarch Forum: - Revealing Botnet Membership Using DNSBL Counter-Intelligence - Nick Feamster, Georgia Tech - Analyzing the Impact of Major Social Events on Internet eXchange Traffic - Yukiyasu Tarui, Internet Multifeeed Co. / JPNAP - Lightning Talks! 1:30 PM - 5:00 PM: Plenary III - PANEL: Pragmatismv6: a grown-up, critical examination of IPv6 - Todd Underwood (moderator), Daniel Golding, Jason Schiller, David Meyer - The NetIO stack in Windows Vista: Functionality and Deployment - Abolade Gbadegesin - Serious Progress on X.509 Certification of RIR Resource Allocations - Randy Bush, IIJ - Closing Remarks Various times: - PGP Key Signing - Joe Abley

1 0

ip reclamation was Re: Kremen's Buddy?
by Scott Weeks 13 Sep '06

13 Sep '06

----- Original Message Follows ----- From: Joe Abley <jabley(a)ca.afilias.info> > Le 2006-09-12 à 15:10, <andrew2(a)one.net> <andrew2(a)one.net> > a écrit : > > > It makes me wonder just how much space like that there > > is out there artifically increasing IP scarcity. > > The fact that there is a lot of space assigned/allocated > and not used in any easily observable way is well known > to those who track the address exhaustion issue, I > think. How much, though, is used, but not routed publically? Something that has been brought up from time to time here. It's not easily observable, but allowed. scott

2 2

[Fwd: RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
by Chris Jester 12 Sep '06

12 Sep '06

> >> Even if you assume that allocations made by ARIN are not property, > it's >> hard to argue that pre-ARIN allocations are not. They're not subject to >> revocation and their grant wasn't conditioned on compliance with > policies. > > The reason that ARIN allocations are not property is > that pre-ARIN allocations were not property. ARIN is > merely continuing the former process with more structure > and public oversight. Are telephone numbers property? > > In any case, since the conditions of the pre-ARIN allocations > were all informal, unrecorded and largely verbal, nobody > can prove that there was any kind of irrevocable grant. > > --Michael Dillon IP addresses appear to be property - - read http://news.findlaw.com/ hdocs/docs/cyberlaw/kremencohen72503opn.pdf. Given that domain names are property, IP addresses should be property, especially in California where are constitution states "All things of value are property" Also, what about ARINS hardcore attitude making it near impossible to aquire ip space, even when you justify it's use? I have had nightmares myself as well as MANY of my collegues share similar experiences. I am having an issue right now with a UNIVERSITY in Mexico tryin to get ip's from the mexican counterpart. Why is it that they involve lawyers, ask you all your customers names and etc... This is more information than I think they should be requiring. Any company that wishes to engage in business as an ISP or provider in some capacity should be granted the right to their own ip space. We cannot trust using ips swipped to us by upstreams and the like. Its just not safe to do that and you lose control. Actually, is there anyone else who shares these nightmares with me? I brought up the lawsuit with Kremen and ARIN to see if this is a common issue. What are your views, and can someone share nightmare stories? Don't get me wrong, I think there has to be SOME due dilligence, however their methodology is a bit hitlerish. If you have had similar problems, contact me off list or on, if you wish. I'd love to talk to you. AIM is preferred. Chris Jester Suavemente, INC. SplitInfinity Networks 619-227-8845 AIM: NJesterIII ICQ: 64791506

8 9

Data Center Wiring Standards
by Rick Kunkel 12 Sep '06

12 Sep '06

Heya folks, I hope this is on-topic. I read the charter, and it falls somewhere along the fuzzy border I think... Can anyone tell me the standard way to deal with patch panels, racks, and switches in a data center used for colocation? I've a sneaking suspicion that we're doing it in a fairly non-scalable way. (I am not responsible for the current method, and I think I'm glad to say that.) Strangely enough, I can find like NO resources on this. I've spent the better part of two hours looking. Right now, we have a rack filled with nothing but patch panels. We have some switches in another rack, and colocation customers scattered around other racks. When a new customer comes in, we run a long wire from their computer(s) and/or other device(s) to the patch panel. Then, from the appropriate block connectors on the back of the panel, we run another wire that terminates in a RJ-45 to plug into the switch. Sounds bonkers I think, doesn't it? My thoughts go like this: We put a patch panel in each rack. Each of these patch panels is permanently (more or less) wired to a patch panel in our main patch cabinet. So, essentially what you've got is a main patch cabinet with a patch panel that corresponds to a patch panel in each other cabinet. Making connection is cinchy and only requires 3-6 foot off-the-shelf cables. Does that sound more correct? I talked to someone else in the office here, and they believe that they've seen it done with a switch in each cabinet, although they couldn't remember is there was a patch panel as well. If you're running 802.1q trunks between a bunch of switches (no patch-panels needed), I can see that working too, I suppose. Any standards? Best practices? Suggestions? Resources, in the form of books, web pages, RFCs, or white papers? Thanks! Rick Kunkel

10 10

(OT) Verizon contact needed
by Rich Sena 12 Sep '06

12 Sep '06

Please reply off-list -- Rich Sena - ras(a)thick.net ThickNET Consulting "On the way to understanding; you understand, and forget."

1 0

proposed NANOG charter amendments
by Joe Abley 12 Sep '06

12 Sep '06

[this message has been cross-posted to nanog@ and nanog-futures@, with followups set accordingly, as we used to say back when Usenet was read by humans. If you're interested in discussing any of this, and you're not on nanog-futures@ already, see <http://www.nanog.org/ email.html>] ** If you're not interested in the continuing organisational aspects of NANOG, hit delete now. Zero operational content follows. ** There are several proposed charter amendments up for vote in St Louis. You'll see a summary of them here: http://www.nanog.org/charter/ There's one change pending to that summary, which is to break out the three options in proposal 2006-03 so that they can each be voted on separately (they're mutually exclusive, so you should only be able to to vote for one of them). If you have opinions on any of the proposals, now would be a good time to voice them on the nanog-futures@ list. Agents are standing by. Joe (for the steering committee)

2 1