- Test - lists.nanog.org

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

Global Crossing issues?
by Brandon Galbraith 11 Sep '06

11 Sep '06

Is anyone seeing any problems when their traffic is hitting Global Crossing in the Midwest? I have equipment at several different carrier-neutral POPs, and any traffic going through gblx.net is having horrible latency or getting dropped entirely. Thanks, -brandon -- Brandon Galbraith Email: brandon.galbraith(a)gmail.com AIM: brandong00 Voice: 630.400.6992 "A true pirate starts drinking before the sun hits the yard-arm. Yarrrr. --thelost"

2 1

Re: comast email issues, who else has them?
by Fergie 11 Sep '06

11 Sep '06

Ack: X-Originating-From should be mandatory. $.02, - ferg -- David Ulevitch <davidu(a)everydns.net> wrote: On Sep 1, 2006, at 6:33 PM, Brandon Galbraith wrote: > I never understood why Gmail didn't put an X-Originating-From > header in mail sent out by web users. Seconded! It may not be a requirement but the omission is certainly inconsistent with most web-based email services, particularly a popular one like Gmail. A lot of abuse ends at a dead-end because trying to deal with security/abuse @ gmail is a losing cause. -david -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

7 9

RE: [Fwd: RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
by Jim McBurnett 11 Sep '06

11 Sep '06

Owen, I totally agree-- In the last 2 years I have worked with ARIN and received several assignments for end users and NONE of them were difficult for the assignment. I think the worst I saw was getting an outdated ORG ID record changed! The time from request to assignment in one case was less than 2 weeks, and the worst was 6 weeks. That one required ORG ID changes, contact changes, ASN assignment, and was interlaced with both me and the customer contact being out of town on different weeks. If you read carefully and just call the helpdesk they are there to help. NOT hinder. Sure the ORG ID change was difficult and I would have had it no other way! That protects all of us! Remember all those hijacked IP blocks? Where is William L?(sorry I can't remember your last name) Later, Jim

1 0

Re: [routing-wg]BGP Update Report
by Vince Fuller 11 Sep '06

11 Sep '06

>> The comment still applies. Imagine that this system were implemented >> globally on all international/intercontinental air routes. It would still >> be nice to avoid having each of those airplanes cause a globally-visible >> routing update whenever it crosses some geographical boundary. > > The problem is physics: The speed of light is about 300.000km/s in air > and about 200.000km/s in fibre, which means a VPN solution causes an > _additional_ >70ms delay for some additional 7000km VPN distance. If one assumes a well-engineered VPN solution that interconnects the ground stations to "peering" points to the rest of the Internet, then there should be no increase in delay for traffic outbound from the plane toward the Internet - traffic path will still be plane -> ground station -> nearest exit point to Internet. The amount of delay increase for return traffic is hard to quantify; it will depend on how well the Conxion service network/VPN is connected to its upstream providers, how well-connected those providers are to interconnect points to the rest of the Internet, whether shortest-exit routing (or some other "optimized exit routing") is implemented between the various providers, etc. Many of these issues will apply to the current, dynamically-route-every- prefix model, too. In some cases, the VPN will make little or no different in delay; in some cases, it may increase one-way delay a bit. On the upside, worries about more-specific filtering and route-dampening will go away. > No, VPN and NAT and PA and shim are not the solution for todays > mobile communications demands. From the view point of the developer > of such an intercontinental communications system todays internet > technology looks outdated, the BGP re-anouncement is just a hack. > Indeed, RFC1661 is dated July 1994. > > This is just another example for the obvious demand of a true dynamic > routing system beeing capable to handle large numbers of prefixes and > dynamic changes in the routing table. Other demand results from mobile > networks, IPv6 PI etc. > > The demand _is_ there, simply saying "don't use PI, do keep 200 customers > rules (IPv6), don't accept small prefixes, don't permit dynamic changes, > do wait for our perfect shim solution which takes short additional 10 years > to develop, do purely theoretical discussions on geoadressing" as the > "restrictive approach" is not the solution. > > Either the Internet community will find good answers to these demands, > or the markets will find solutions without the Internet community ... > > Ceterum Censeo: BGP_Standard_Update subito, IPv6 PI subito ... If one assumes no changes to ipv6 semantics, it is hard to envision such a solution being possible. "PI routing" degenerates into flat routing and building "a true dynamic routing system beeing capable to handle large numbers of prefixes and dynamic changes in the routing table" is difficult to impossible if one assumes a) a single number space that accomodates both routing information and endpoint-identification (which is a fundamental design assumption in ipv6 as currently specified) and b) continued super-linear growth in the number of unique subnets that are identified using that numbering space. There are smart people who have been looking at how to fix this for more than a decade (some would say that research along these lines dates back to the 1960s...see http://www.nanog.org/mtg-0606/fuller.html for a recent NANOG presentation on this topic, with pointers to earlier work); virtually all of the designs that have been offered require routing locator/endpoint-id separation. Unfortunately, those who put together the current ipv6 did not choose to follow the locator/endpoint-id separation path. For a variety of reasons, trying to retro-fit the split into ipv6 with something like shim6 is difficult and it running into a lot of resistance. --Vince

1 0