May 2002 - Test - lists.nanog.org

China's cable firms fight deadly turf war
by Sean Donelan 30 May '02

30 May '02

http://www.timesonline.co.uk/article/0,,3-311460,00.html China's cable firms fight deadly turf war >From Oliver August in Shanying May 30, 2002 "CLAD in a blue China Telecom jacket proclaiming We protect the nations cables, Hao Dawei sets off at sunrise from his parents mudbrick home in Shanying to ride his motorcycle along the route of his state-owned companys main cable to Beijing, 300 miles to the west. On the road to Huairen he finds 100 workers digging a trench right on top of the China Telecom line. He jumps off his bike. Stop immediately, he shouts. You'll cut our cable. The gang glare at him. Hao Dawei knows the type. They work for one of the many rival telecom companies who are laying their own cables. He calls for backup, but the five colleagues who arrive within minutes are no match for the workers. Soon 20 of them are beating the 26-year-old patrol rider as a crouches in the grass. His colleagues flee and he ends up in hospital having stitches in his head."

6 5

Is this list working?
by John Palmer 30 May '02

30 May '02

Posted a message several times and it never made it out Is the list broken?

2 1

Betr.: KPNQwest
by eric＠mails.ch 30 May '02

30 May '02

Anyone able to outline a worst case scenario, on what the effect would be, if the KPN network really goes down? cheers eric > > > Considering the number of messages about companies going bust, this > one seems vaguely operational for some... > http://biz.yahoo.com/djus/020529/200205292257000882_2.html > > There are a number of quotes from "people familiar with the matter," > but as I understand it the background is sound. If KPNQ does have to > switch off their network, it will affect a large number of businesses > in Europe, as they offer both circuits (via their extensive "Eurorings" > network) and IP connectivity (they acquired Ebone not too long ago). > > Rob

6 5

Abuse Contact at NuVox
by Daniel Lark 30 May '02

30 May '02

I am consistently seeing a host from within nuvox.net trying to send spam through one of my mail servers. Anybody have a contact name, etc. for them? The abuse auto-reply is obviously less than helpful. -dan

3 2

KPNQwest
by Rob Evans 30 May '02

30 May '02

Considering the number of messages about companies going bust, this one seems vaguely operational for some... http://biz.yahoo.com/djus/020529/200205292257000882_2.html There are a number of quotes from "people familiar with the matter," but as I understand it the background is sound. If KPNQ does have to switch off their network, it will affect a large number of businesses in Europe, as they offer both circuits (via their extensive "Eurorings" network) and IP connectivity (they acquired Ebone not too long ago). Rob

3 2

Is there any one from Network Access Solutions (NAS-CORP) on this list?
by John Palmer (NANOG Acct) 30 May '02

30 May '02

Typical - NAS took over our account from ARDENT and did the cutover today. They botched it up. Our routes are not being announced. If you are out there please contact me at jpp(a)well.com

1 0

ATT problems
by Ian A Finlay 30 May '02

30 May '02

Hi, I can't read a shared imap folder for Nanog right now, so could someone please reply to me off list and let me know if they are seeing problems with ATT's network, especially on the east coast? Thanks, Ian

2 2

Re: IP renumbering timeframe
by k claffy 29 May '02

29 May '02

sorry about long latency but andre did some analysis that's relevant to joe's message during this nanog thread earlier this month. include joe's message for context and andre's response below. (andre's response relates to last paragraph of joe's message) k ================================================== Date: Mon, 6 May 2002 14:14:34 -0400 From: Joe Abley <jabley(a)automagic.org> Subject: Re: IP renumbering timeframe To: David Conrad <david.conrad(a)nominum.com> Cc: grant(a)tnarg.org, nanog <nanog(a)merit.edu> On Mon, May 06, 2002 at 10:41:09AM -0700, David Conrad wrote: > On 5/6/02 10:20 AM, "Grant A. Kirkwood" <grant(a)tnarg.org> wrote: > > I'm sorry, but ARIN's policy practically _encourages_ the "efficient > > wasting" of space to qualify for PI space. This is one of the most > > frustrating things to deal with. > > As someone who used to run a registry, one of the most frustrating things to > deal with was watching ISPs pee in their own pool and then scream at the > registries 'cause the water was yellow. > > Just how big should the DFZ be? > > Given the Internet is not (yet, at least) a fascist state, the registries > rely on ISPs to be aware of the environment in which they are operating. As > it is unlikely any of the registries will be hiring independent auditing > firms to verify true utilization, there is need for a certain level of > trust. If an ISP is too small to justify the allocation of a /20, then they > should obtain address space from an upstream provider so that they do not > add yet another entry to the DFZ. A multi-homed ISP who advertises PA space to multiple transit providers adds state to the DFZ. It is common practice for PA-delegating transit providers to punch a whole in their covering supernet advertisements in order to facilitate this. The PI/PA distinction seems unhelpful in the case of a multi-homed ISP. > The term "tragedy" in "the tragedy of the commons" is not a mistake... It would be interesting to see multi-homed ISPs take the time to classify the parts of the infrastructure which are hard to renumber, versus those that are easy to renumber. It may be quite trivial to renumber large dial/cable/DSL address pools every now and then, as and when transit providers change. It may be a minor nightmare to renumber nameservers that report authoritatively for domains in a large collection of separately-managed TLDs. I wonder whether the average small, multi-homed ISP who currently lusts after PI space would find all their renumbering nightmares reduced to entirely manageable levels by the delegation of (say) 1 x /24 PI netblock to number nameservers and mail exchangers, and n x /whatever netblocks to number everything else. If the justification requirements for PI space were relaxed to accommodate this kind of scenario (or if ISPs were more inclined to use the existing requirements in this way), perhaps fewer multi- omed ISPs would feel obliged to tell lies to RIRs to obtain address delegations they don't really need. But the DFZ still accumulates additional state every time an edge network multi-homes. It would be interesting to compare the growth in the numbers of single-homed vs. multi-homed edge networks. If the edge of the network is becoming predominantly multi-homed, the goals of the RIRs wrt DFZ state containment might usefully be modified to better serve other objectives. Joe ----- End forwarded message ----- From: broido(a)caida.org Joe, We tracked this trend in "Internet expansion, refinement and churn" -- http://www.caida.org/outreach/papers/2002/EGR/ We also just looked at the data available from RouteViews for May 15, 2001. We selected 36 tables (each from a different RouteViews peer) that each had over 109K prefixes. We define prefixes representing DFZ ('default free zone') as those present in 19 or more tables ("semiglobal prefixes"). (See above paper for details on terminology/methodology). Multihoming was on the rise in 1997-1999, but slowed in 2000-2002. As of May 15, 2002, multihomed ASes make up 63% of all ASes. This is an increase of 1.4% since November 2001 (in 6 months). Currently available BGP data sheds doubt on the assumption that multihoming is the dominant contributor to growth of DFZ state. Note that when people refer to the "[problem of] multi-homed ASes" (i.e., ASes with multiple adjacent upstream ASes), they usually mean "nontransit multihomed" since most (over 75%) transit ASes are multihomed, and single homed transit ASes (i.e. ASes with only one upstream AS -- 541 out of 13281 ASes found in these BGP tables) may be an artifact of the undercoverage of BGP AS connectivity data. Multihomed nontransit ASes make up 60% of all non-transit ASes. So, as it stands now, A. The share of DFZ prefixes announced by non-transit multihomed ASes remained at 30% throughout 2000-2002, whereas the share of non-transit multihomed ASes grew 4.7%: May 2000 May 2001 15 May 2002 %ASes: 45.66 48.61 50.36 %prefixes: 29.43 31.30 30.15 This data shows that non-transit multhomed ASes contribute less than their `fair share' of prefixes to the DFZ BGP table. Multihoming would thus seem _not_ to be the primary cause of DFZ BGP table growth. B. As of 15 May 2002, multihomed transit and non-transit ASes originate 77.3% of all prefixes and 75.4% of all more specifics. These ASes announce their `fair' share of more specifics, i.e., proportionate to the total share of their prefixes in the table. The implication is that more specifics and multihoming are independent notions. C. The largest pool of prefixes (47.2%) is announced by transit multihomed ASes (as opposed to transit single-homed, or multi- and single- homed nontransit ASes.) Note that there is an inherent ambiguity in BGP data caused by availability of only a handful of representative tables, which leads us to suspect that there may be more multihomed ASes than this collection of BGP tables suggest. There may also be trends associated with prefixes carried from one group to another, e.g., when an AS becomes transit from non-transit or vice versa. As it stands now, however, we can only say that the largest set of DFZ prefixes, almost 1/2 of total, is announced by transit multihomed ASes (likely on behalf of their customers whose individual degree of multi- or single homing cannot be estimated using BGP tables.) The ultimate conclusion is that available data does not support the statement that multihoming is the dominant source of core BGP table growth. Andre, kc ps: last arin presentation may also be of interest http://www.caida.org/outreach/presentations/arin0402/

1 0

Contact for UniNet S.A. de C.V. (NETBLK-UNINET-NETBLK-12)
by Dan Hollis 29 May '02

29 May '02

Does anyone have a real contact for UniNet S.A. de C.V. (NETBLK-UNINET-NETBLK-12) ? The email address registered bounces "mailbox full". -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

3 3

Draft agenda for Toronto
by Susan Harris 29 May '02

29 May '02

Agenda: NANOG 25 June 9-11, 2002 Richmond Hill, Ontario, Canada SUNDAY TUTORIALS 1:30 - 3:00 p.m. Introduction to RPSL Level: Intermediate Ambrose Magee, Ericsson 1:30 - 3:00 p.m. BGP Techniques for Service Providers Level: Intermediate Philip Smith, Cisco 1:30 - 3:00 p.m. Inter-domain Traffic Engineering: Overview and Case Examples Level: Intermediate Josh Wepman, Ixia; Joe Abley, MFN; Andrew Lange, CW; Matthew Meyer, Global Crossing 3:00 - 3:30 p.m. BREAK 3:30 - 5:00 p.m. Intro to RPSL (cont'd.) 3:30 - 5:00 p.m. BGP Techniques (cont'd.) 3:30 - 5:00 p.m. Inter-domain TE (cont'd.) 5:00 - 7:30 p.m. DINNER BREAK 7:30 - 9:00 p.m. Deploying Tight-SLA Services on an Internet Backbone: ISIS Fast Convergence and Differentiated Services Design Level: Intermediate Clarence Filsfils, Cisco Monday, June 10 General Session --------------- 9:00 a.m. Welcome, Introductions Susan Harris, Merit Robert Watson, GT 9:15 a.m. Panel: Core Network Design and Vendor Prophecies Danny McPherson, TCB, moderator Carey Parker, Chiaro; Riad Hartani, Caspia; Dave Ward, Cisco; Puneet Agarwal, Pluris; Scott Poretsky, Avici; Dave O'Leary, Juniper; Ori Aruj, Charlotte's Web 10:45 a.m. BREAK 11:00 a.m. Why Are we Scared of SPF? IGP Scaling and Stability Dave Katz, Juniper 12:00 p.m. LUNCH 1:30 p.m. Convergence and Restoration Techniques for ISP Interior Routing Curtis Villamizar, Avici 2:30 p.m. Controlling the Impact of BGP Policy Changes on IP Traffic Nick Feamster, MIT Jennifer Rexford & Jay Borkenhagen, AT&T Labs 3:15 p.m. BREAK 3:40 p.m. Redistribution Communities for Interdomain Traffic Engineering Bruno Quoitin & Olivier Bonaventure Univ. of Namur, Belgium 4:10 p.m. Panel: Economic Differences Between Transit and Peering Exchanges Bill Woodcock, Packet Clearing House, moderator Keith Mitchell, XchangePoint Philip Smith, Cisco MONDAY EVENING BOFs ------------------- 7:30 - 9:00 p.m. Peering BOF V Bill Norton, Equinix, moderator 7:30 - 9:00 p.m. BGP Benchmarking BOF Sue Hares, NextHop, moderator 7:00 - 9:30 p.m. What Would You Like to Get Out of NANOG That You're not Getting Now? Susan Harris, Merit, moderator Tuesday, June 11 General Session ---------------- 9:00 a.m. Panel: Smart Routing Technologies 9:00-9:15 a.m. - Overview 9:15-10:15 a.m. - Vendor Presentations 10:15-10:30 a.m. - Q & A Sue Hares, NextHop, moderator Jeremy Johnson, netVmg; Aaron Britt, Opnix; Robert Bays, Proficient; Mike Lloyd, RouteScience; Daniel Golding & Brandon Ross, Sockeye 10:30 a.m. BREAK 10:45 a.m. Smart Routing (cont'd.)1 10:45-11:20 a.m. - BGP Issues 11:20-11:35 a.m. - Q & A 11:35 a.m. 10 Gigabit Ethernet Technology and Market Overview Dave O'Leary, Juniper 12:00 p.m. LUNCH 1:30 p.m. Protecting the BGP Routes to Top Level DNS Servers Lan Wang, UCLA; Xiaoliang Zhao, NCSU; Dan Pei, UC Davis; Randy Bush, AT&T; Daniel Massey & Allison Mankin, USC/ISI; Felix Wu, UC Davis; Lixia Zhang, UCLA 2:15 p.m. BGP Security Update Barry Raveendran Greene, Cisco 3:00 p.m. BREAK 3:15 p.m. Industry/Government Infrastructure Vulnerability Assessment: Background and Recommendations Avi Freedman, Akamai 3:45 p.m. Core Router Testing for High Availability Scott Poretsky, Avici 4:15 p.m. Using the New ARIN WHOIS Server Ginny Listman, ARIN 4:35 p.m. Adjourn Susan Harris, Merit

1 0