- NANOG - lists.nanog.org

FYI: South Asia Network Operators Group (SANOG)
by Philip Smith 28 Nov '02

28 Nov '02

This is an FYI only... The first meeting of the South Asia Network Operators Group (SANOG) will take place alongside ITConference2003 (http://www.itconference.org.np/) in Kathmandu, Nepal on 23rd-27th January 2003. Its aimed at ISPs and Network Operators in the South Asia region, basically encompassing the Indian subcontinent and neighbouring countries. SANOG doesn't quite yet have a website, but hopefully this isn't too far off. This is the first attempt to create such an operators group in this part of Asia; if anyone is interested in supporting this new NOG, please feel free to contact Gaurab Raj Upadhaya <gaurab(a)lahai.com> who is organising the event. philip --

1 0

None
by Steve Bellovin 27 Nov '02

27 Nov '02

Genuity filed for bankruptcy today as part of a deal to sell nearly all of its assets to Level 3. http://biz.yahoo.com/djus/021127/1744000711_1.html --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book)

2 1

Re: Risk of Internet collapse grows
by David Diaz 27 Nov '02

27 Nov '02

I think this is old news. There was a cover story back in 1996 time frame on Mae_east. We have to ask how likely is this with many of the top backbones doing private peering over local loops, how much damage would occur if an exchange point where hit? I have 2 different questions. 1) In the current environment, are peering circuits running fuller then in previous years. I ask after there has been questions on UUNET/L3 Capacity in europe etc. If the case is so, then an attack in one peering location/region might cause major problems as other peering sessions become overloaded. 2) Wouldnt an attach on particular servers that are NOT redundant have a more significant affect? Are microsoft's servers mirrored? Just posing a scenario. Thought this might be worth passing on: <http://news.bbc.co.uk/2/hi/technology/2514651.stm>http://news.bbc.co.uk/2/hi/technology/2514651.stm There is a recent book out called "Linked: The New Science of Networks" which details the potential for causing widespread Internet damage by targeting a few hubs instead of random or widespread attacks against large numbers of hosts. This simulation seems to backup the author's concerns. Irwin -- David Diaz dave(a)smoton.net [Email] pagedave(a)smoton.net [Pager] www.smoton.net [Peering Site under development] Smotons (Smart Photons) trump dumb photons

5 5

Broken Netmask?
by Palmer, John 27 Nov '02

27 Nov '02

We have a /23 (199.5.156/23) and seem to be having a problem with our ISP (Network Access Solutions - NAS) . We do not do our own route advertising - they do it for us and route the block to our connection. The problem is that the second part of the block (199.5.157.0 - 199.5.157.255) seems to be mis-routed within the ISP's network. I think its a netmask problem. The symptoms are that packets get through from some destinations and not from others. Also, packets sometimes fail based on port numbers (ie: if I come from x.y.z.w to 199.5.157.x on port 80, it works but not from x.y.z.w to 199.5.157.x on port 25) Furthermore, the port and source addresses that have problems changes over time (ie: x.y.z.w to port 25 will work tommorrow). We dont block these ports nor do they. NAS seems to be light on technical talent and can't seem to solve this problem. Interesting note, if you check 199.5.157.1 bgp from any of the looking glass websites you get multiple occurrences of NAS (and other AS numbers): ie: (from AADS) BGP routing table entry for 199.5.156.0/23, version 6041537 Paths: (6 available, best #1) Advertised to peer-groups: AS4544-INTERNAL AS4544-CLIENT AS4544-HOT-ROUTE AS4544-DATA-CENTER AS4544-CORE-CUSTOMER-FULL 16631 16631 16631 13953 13953 13953 13953 13953 13953 206.220.243.177 from 206.220.243.177 (66.28.1.8) Origin IGP, metric 100, localpref 80, valid, external, best Community: 4544:300 16631 16631 16631 13953 13953 13953 13953 13953 13953, (received-only) 206.220.243.177 from 206.220.243.177 (66.28.1.8) Origin IGP, metric 30802, localpref 100, valid, external 16631 16631 16631 13953 13953 13953 13953 13953 13953, (received & used) 206.204.251.196 (metric 113851) from 206.204.251.196 (206.204.251.196) Origin IGP, metric 100, localpref 80, valid, internal Community: 4544:300 4544:5005 16631 16631 16631 13953 13953 13953 13953 13953 13953, (received & used) 206.204.251.206 (metric 43484) from 206.204.251.206 (206.204.251.206) Origin IGP, metric 100, localpref 80, valid, internal Community: 4544:300 4544:5001 6461 16631 16631 16631 13953 13953 13953 13953 13953 13953 206.220.243.71 from 206.220.243.71 (207.126.96.35) Origin IGP, metric 110, localpref 80, valid, external Community: 4544:300 6461 16631 16631 16631 13953 13953 13953 13953 13953 13953, (received-only) 206.220.243.71 from 206.220.243.71 (207.126.96.35) Origin IGP, metric 1295, localpref 100, valid, external Notice the multiple occurrences of 16631 and 13953. I know there are valid reasons to add multiple occurrences, but can anyone tell if this is broken? These duplicate numbers are new - they were'nt there before (when things worked). The intermittant failure problem reminds me of a time when someone's IGRP had a bad netmask somwhere. I'm wondering if they may have a /24 netmask internally somewhere and not a /23 like they should. Any help would be appreciated. NAS doesn't seem to have a clue.

2 1

updates to complexity pages
by David Meyer 27 Nov '02

27 Nov '02

Many people have asked to to update my complexity pages with a bit of theoretical background to to support some of the material there (in particular, percolation theory). So, as promised, I've updated http://www.maoz.com/~dmm/complexity_and_the_internet with a little (very little) bit of material on percolation theory. Questions and comments on all of this very much welcomed, Dave

1 0

NANOG27 Call for Presentations
by Susan Harris 27 Nov '02

27 Nov '02

* * * * * * * * * * * * * * * * * CALL FOR PRESENTATIONS NANOG 27 GENERAL SESSION TUTORIALS CASE STUDIES OPERATIONS RESEARCH POSTER SESSION February 9 - 11, 2003 * * * * * * * * * * * * * * * * * The North American Network Operators' Group (NANOG) will hold its 27th meeting February 9-11, 2003, in Phoenix, Arizona. The meeting will be hosted by Rodney Joffe and UltraDNS. Registration opens January 2. NANOG conferences provide a forum for the coordination and dissemination of technical information related to large-scale (i.e., national/international) Internet backbone networking technologies and operational practices. Meetings are held three times each year, and include two days of short presentations, plus afternoon/evening tutorial sessions. The meetings are informal, with an emphasis on relevance to current backbone engineering practices. NANOG conferences draw over 500 participants, mainly consisting of engineering staff from national service providers, and members of the research and education community. For more information about NANOG meetings, schedules, and logistics, see: http://www.nanog.org ------------------------------------------------------------------------------ CALL FOR PRESENTATIONS NANOG invites presentations on backbone engineering, coordination, and research topics. Presentations should highlight issues relating to technology already deployed or soon to be deployed in core Internet backbones and exchange points. Network operators are invited to present case studies detailing their experiences with network planning and design, protocol implementation, provisioning, automation, useful tools, traffic engineering, troubleshooting, problems solved, and DoS. Researchers are invited to present short (10-minute) summaries of their work for operator feedback. Topics include routing, network performance, statistical measurement and analysis, and protocol development and implementation. Studies presented may be works in progress. Researchers from academia, government, and industry are encouraged to present. Previous NANOG meetings have included presentations on: - Backbone traffic engineering - Freely available configuration, management, and measurement tools - Inter-provider security and routing protocol authentication - Routing scalability in backbone infrastructures - Security issues for the Internet core - Routing policy specification and backbone router configuration - Building large-scale measurement infrastructure - Cooperative inter-provider caching - Alternatives to hot-potato routing - Recommendations on queue management and congestion avoidance - Experience with differentiated services - Inter-domain multicast deployment - Backbone network failure analysis Tutorials have covered topics such as: - BGP troubleshooting techniques - ISP security: real world techniques - IPv6 basics - IP multicast technologies ------------------------------------------------------------------------------ HOW TO PRESENT Submit a detailed abstract or outline describing the presentation in email to nanog-support(a)nanog.org. The deadline for proposals is January 6, 2003. While the majority of speaking slots will be filled by January 6, a limited number of slots will be available after that date for topics that are exceptionally timely and important. Submissions will be reviewed by the NANOG Program Committee, and presenters will be notified of acceptance by January 20, 2003. Final drafts of presentation slides are due by January 29, and final versions February 5. NANOG also welcomes suggestions/recommendations for tutorials, panels, and other presentation topics. ---------------------------------------------------------------------------

1 0

Re: Risk of Internet collapse grows
by Andrew Odlyzko 27 Nov '02

27 Nov '02

> On Wed, 27 Nov 2002, variable(a)ednet.co.uk wrote: On Wed, 27 Nov 2002, David Diaz wrote: > I think this is old news. There was a cover story back in 1996 time > frame on Mae_east. We have to ask how likely is this with many of > the top backbones doing private peering over local loops, how much > damage would occur if an exchange point where hit? It depends which exchange point is hit. There are a couple of buildings in London which if hit would have a disasterous affect on UK and European peering. What about fibre landing stations? Are these diverse enough? Again, most of the transatlantic fibre (for the UK) appears to come in near Lands End. Rich There is not all that much diversity in many aspects of the telecommunications infrastructure. There are some interesting pages prepared by John Young at Cryptome <http://cryptome.org>. It is a nice combination of public source maps and aerial photographs. Eyeballing Telephone Switching Hubs in Downtown Manhattan (10th July 2002) http://cryptome.org/nytel-eyeball.htm Eyeballing US Transpacific Cable Landings (July 2002) http://cryptome.org/cablew-eyeball.htm Eyeballing US Transatlantic Cable Landings (7th July 2002) Full list of Eyeballing projects http://cryptome.org/eyeball.htm Andrew

1 0

New IPv4 blcok allocated to RIPE NCC
by leo vegoda 27 Nov '02

27 Nov '02

Dear Colleagues, The RIPE NCC received the IPv4 address range 82.0.0.0/8 from the IANA in November 2002. We will begin allocating from this range in the near future. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Kind regards, -- leo vegoda RIPE NCC Registration Services

1 0

virus or?
by Randy Rostie 26 Nov '02

26 Nov '02

We received the following email, with an incredible number of email addresses in the cc: field. We did not even get the original message. Maybe someone has a virus on their computer? I am guessing this is every NOC email address in someone's address book. The email caused us to receive 45 auto-replies from around 5 different domains, that were forwarded to us (and all the addresses below), by digitalwest.net. Randy Received: from wiggum.snlo01.digitalwest.net ([65.164.24.67]) by communitech.net ; Mon, 25 Nov 2002 19:08:17 -0600 Received: from wiggum.snlo01.digitalwest.net (localhost [127.0.0.1]) by wiggum.snlo01.digitalwest.net (8.12.6/8.12.6/Debian-7) with ESMTP id gAQ0x0fN021784; Mon, 25 Nov 2002 16:59:08 -0800 Received: (from mail@localhost) by wiggum.snlo01.digitalwest.net (8.12.6/8.12.6/Debian-7) id gAQ0ljgR020003; Mon, 25 Nov 2002 16:47:45 -0800 ----- Original Message ----- From: "Josh Richards via RT" <noc(a)digitalwest.net> To: <James_Meslovich(a)icgcomm.com> Cc: <noc(a)home.net>; <noc(a)alink.net>; <noc(a)above.net>; <noc(a)abs.net>; <support(a)access.net.id>; <noc(a)aces.com>; <noctech(a)adelphia.net>; <noc(a)agis.net>; <noc(a)akamai.com>; <data-nocc(a)algx.com>; <support(a)alpha.net>; <inetnoc(a)aol.com>; <noc(a)amisp.net>; <ops(a)content.ameritech.net>; <trouble(a)ans.net>; <support(a)appliedtheory.com>; <noc(a)aracnet.com>; <trouble(a)ntt.net>; <noc(a)att.net>; <noc(a)cerf.net>; <noc(a)att-disc.net>; <noc(a)attens.com>; <noc(a)attglobal.net>; <ops(a)atomfilms.com>; <trouble(a)aucu.europe>; <trouble(a)att-unisource.net>; <sales(a)awwm.com>; <ipnoc(a)axxent.ca>; <it(a)bconnex.net>; <ops(a)bbnplanet.com>; <noc(a)bellatlantic.net>; <noc(a)in.bell.ca>; <nnmc(a)on.bell.ca>; <noc(a)bellsouth.net>; <noc(a)best.net>; <noc(a)mail.sprintmail.net>; <noc(a)cihost.com>; <noc(a)canet.ca>; <noc(a)cweurope.net>; <noc(a)cwix.net>; <trouble(a)cw.net>; <trouble(a)cw.net>; <noc(a)cableinet.net>; <noc(a)cv.net>; <noc(a)cad-net.co.uk>; <noc(a)cais.net>; <noc(a)calweb.com>; <tech(a)cancom.net>; <inoc(a)carrier1.com>; <noc(a)cetlink.net>; <cgsc(a)chello.com>; <noc(a)circle.net>; <noc(a)cnz.com>; <noc(a)clix.net.nz>; <ops(a)clear.net.nz>; <webmaster(a)colosource.com>; <webmaster(a)colosource.com>; <ops(a)colt.net>; <noc(a)fr.colt.net>; <noc(a)com.net>; <noc(a)comindico.com.au>; <noc(a)communitech.net>; <noc(a)compuhelp.com>; <noc(a)internex.net>; <noc(a)connect.com.au>; <noc(a)connectnet.com>; <noc(a)conxion.net>; <noc(a)cp.net>; <noc(a)crl.com>; <paul.witta(a)cubit.at>; <noc(a)cyberverse.com>; <noc(a)bora.net>; <noc(a)bora.net>; <noc(a)dtg.com>; <noc(a)dra.net>; <noc(a)dataphone.net>; <support(a)datapipe.com>; <noc(a)datapipe.net>; <noc(a)datapipe.com>; <support(a)magna.com.au>; <noc(a)deckpoint.ch>; <noc(a)deckpoint.ch>; <support(a)delaware.net>; <noc-fl(a)demon.net>; <noc(a)nic.dtag.de>; <noc(a)dialtoneinternet.net>; <support(a)digex.net>; <ops(a)digisle.net>; <NOC(a)digisle.net>; <noc(a)dn.net>; <routing(a)crcc.disa.mil>; <noc(a)dls.net>; <noc(a)dnai.com>; <noc(a)domain.net>; <noc(a)dpnet.net>; <support-request(a)dsl.net>; <noc(a)dxstorm.net>; <noc(a)Corp.EarthLink.Net>; <noc(a)Corp.EarthLink.Net>; <noc(a)earthstation.net>; <noc(a)east.ru>; <noc(a)easynet.net>; <noc(a)edmin.com>; <support(a)eli.net>; <apoio(a)embratel.net.br>; <noc(a)empireone.net>; <noc(a)ena.com>; <noc(a)energis-ecs.com>; <noc(a)enron.net>; <noc(a)ENTERZONE.NET>; <noc(a)ENTERZONE.NET>; <noc(a)ENTERZONE.NET>; <noc(a)eni.net>; <noc(a)ergogroup.net>; <noc(a)erols.com>; <trouble(a)es.net>; <noc(a)eu.net>; <noc(a)Romania.EU.net>; <noc(a)sweden.eu.net>; <noc(a)euro.net>; <hostmaster(a)ep.net>; <support(a)exodus.net>; <snvnoc(a)globalcenter.net>; <noc(a)expnet.net>; <noc(a)expnet.net>; <noc(a)fast.net>; <noc(a)fast.net>; <noc(a)fnsi.net>; <noc(a)flash.net>; <noc(a)fdt.net>; <noc(a)fdt.net>; <noc(a)flyingcroc.net>; <mike(a)tampabay.net>; <noc(a)genuity.net>; <ops(a)genuity.net>; <admin(a)geotec.net>; <noc(a)geotec.net>; <noc(a)gigabell.net>; <apardo(a)ipf.es>; <noc(a)gin.cz>; <gc-noc(a)gblx.net>; <noc(a)gnac.com>; <hostmaster(a)globalone.no>; <support(a)globix.net>; <noc(a)good.net>; <noc(a)gxn.net>; <support(a)hnt.com>; <noc(a)harvard.net>; <noc(a)harvard.net>; <noc(a)hknet.com>; <noc(a)hopone.net>; <noc(a)ibizcorp.com>; <noc(a)ibm.net>; <noc(a)noc.icg.net>; <noc(a)ico.com>; <noc(a)iconnet.net>; <noc(a)idc.ad.jp>; <noc(a)idcglobal.net>; <noc(a)idt.net>; <support(a)ihighway.net>; <noc(a)ihug.net>; <noc(a)iij.ad.jp>; <noc(a)cdc-inc.net>; <noc(a)impulse.net>; <noc(a)inet-solutions.net>; <noc(a)nuri.net>; <trouble.desk(a)infoave.net>; <noc(a)info.net>; <trouble(a)infonet-europe.net>; <noc(a)rtn.net.mx>; <noc(a)inow.com>; <noc(a)insnet.net>; <network(a)insync.net>; <noc(a)intelenet.net>; <noc(a)intelideas.com>; <noc(a)intelideas.com>; <noc(a)intelideas.com>; <noc(a)interaccess.com>; <noc(a)jersey.net>; <noc(a)unlisys.net>; <noc(a)icix.net>; <noc(a)internap.com>; <noc(a)i1.net>; <noc(a)airmail.net>; <noc(a)internex.net>; <noc(a)interpacket.net>; <smc(a)intira.com>; <noc(a)intouch.net>; <noc(a)ipf.net>; <noc(a)iphil.net>; <noc(a)iqonline.net>; <operations(a)iquest.net>; <admin(a)aria.nic.ir>; <noc(a)isi.edu>; <support(a)isite.net>; <noc(a)itv.se>; <internetnoc(a)ixc-comm.com>; <noc(a)kgns.net>; <support(a)kddnet.ad.jp>; <noc(a)kechara.net>; <sysadmin(a)keyconn.net>; <noc(a)keyconn.net>; <sysadmin(a)keyconn.net>; <sysadmin(a)keyconn.net>; <noc(a)kingston-internet.net>; <support(a)kivex.com>; <noc(a)kks.net>; <noc(a)kornet.net>; <ip-oper(a)kpnqwest.at>; <ip-oper(a)kpnqwest.no>; <noc(a)sri.lanka.net>; <admin(a)leftcoast.net>; <support(a)level3.com>; <noc(a)level3.net>; <noc(a)level3.net>; <noc(a)libertysurf.fr>; <noc(a)lightning.net>; <noc(a)lightrealm.com>; <noc(a)liveonthenet.com>; <support(a)linx.net>; <NOC(a)ln.net>; <noc(a)ln.net>; <noc(a)ltinet.net>; <netadm(a)magma.ca>; <support(a)magna.com.au>; <datos(a)mcmtelecom.com.mx>; <noc(a)tm.net>; <trouble(a)rsng.net>; <noc(a)mfs.net>; <trouble(a)merit.edu>; <msnnoc(a)microsoft.com>; <noc(a)mis.net>; <noc(a)mindspring.net>; <trouble(a)mr.net>; <noc(a)mne.com>; <noc(a)monmouth.com>; <noc(a)msen.com>; <noc(a)hotmail.com>; <noc(a)hotmail.com>; <noc(a)jsnet.com>; <noc(a)hotmail.com>; <noc(a)nacamar.net>; <noc(a)nanospace.net>; <noc(a)nap.net>; <noc(a)nationwide.net>; <noc(a)navi.net>; <nmcgroup(a)navinet.net>; <trouble(a)neo.net>; <noc(a)netaxs.com>; <noc(a)netaxs.com>; <network(a)nac.net>; <noc(a)netasset.com>; <noc(a)noc.netcom.com>; <noc(a)netcom.ca>; <noc(a)netconcept.com>; <noc(a)netmore.net>; <noc(a)netrail.net>; <noc(a)reach.net>; <noc(a)netreach.net>; <noc(a)netscalibur.co.uk>; <noc(a)netscalibur.co.uk>; <noc(a)ni.net>; <noc(a)netzero.net>; <noc(a)netzero.net>; <noc(a)nmix.net>; <noc(a)nm.net>; <noc(a)nextlec.net>; <ops(a)nmnap.net>; <support(a)nsn.com>; <noc(a)nwlink.com>; <noc(a)nvnw.net>; <noc(a)nsitel.net>; <noc(a)nsitel.net>; <noc(a)olywa.net>; <noc(a)onecall.net>; <help(a)one.net>; <trouble(a)onvoy.com>; <noc(a)onyx.net>; <noc(a)opusnet.com>; <noc(a)opusnet.com>; <noc(a)opusnet.com>; <trouble(a)pbi.net>; <trouble(a)pbi.net>; <noc(a)pacific.net.sg>; <noc(a)partan.com>; <noc(a)peak-10.com>; <admin(a)phenotek.com>; <noc(a)planet.net.uk>; <noc(a)power.net>; <noc(a)powertech.no>; <noc(a)primenet.net>; <noc(a)priori.net>; <engineering(a)pro-usa.net>; <noc(a)proxad.net>; <noc(a)psi.com>; <networks(a)uk.psi.com>; <noc(a)kr.psi.net>; <networks(a)uk.psi.com>; <noc(a)publichost.com>; <noc(a)qwest.net>; <noc(a)rackspace.com>; <noc(a)raetek.net>; <noc(a)cwasia.net.sg>; <noc(a)uunam.mx>; <noc(a)unam.mx>; <noc(a)reflexnet.net>; <noc(a)relcom.eu.net>; <noc(a)lists.rr.com>; <noc(a)rr.com>; <noc(a)rmi.net>; <noc(a)rt.ru>; <ncc(a)savvis.net>; <noc(a)semaphore.net>; <noc(a)servint.com>; <NOC(a)shaw.ca>; <support(a)shore.net>; <noc(a)shreve.net>; <noc(a)singnet.com.sg>; <dstroup(a)skycache.com>; <noc(a)solnet.ch>; <bobp(a)southcom.com.au>; <monitors(a)sover.net>; <noc(a)speedchoice.com>; <noc(a)splitrock.net>; <noc(a)sprint.net>; <neteng(a)sprintbroadband.com>; <isp(a)star.net.uk>; <noc(a)stargate.net>; <noc(a)megapop.net>; <noc(a)stealth.net>; <wmahoney(a)suffolk.edu>; <noc(a)supermedia.pl>; <noc(a)surfnetconnexion.com>; <noc(a)surfnetconnexion.com>; <noc(a)ip-plus.net>; <noc(a)switch.ch>; <noc(a)techline.com>; <noc(a)tegris.com>; <noc(a)tegris.com>; <staff(a)ip.tele.dk>; <trouble(a)teleglobe.net>; <noc(a)telerama.com>; <noc(a)sfo.com>; <ncc(a)telia.net>; <noc(a)telocity.net>; <trouble(a)the.net>; <noc(a)fix.net>; <support(a)is.co.za>; <support(a)is.co.za>; <operators(a)nally.evansville.in.us>; <noc(a)theplanet.com>; <noc(a)mediaone.net>; <noc(a)trivergent.net>; <noc(a)ttsg.com>; <noc(a)us.net>; <support(a)uunet.ca>; <noc(a)uunet.ca>; <noc(a)uunet.co.za>; <noc(a)uu.net>; <jpr(a)vcnet.com>; <noc(a)visi.com>; <noc(a)verio.net>; <noc(a)vianetworks.com>; <noc(a)viewinternet.com>; <support(a)villagenet.com>; <noc(a)vphos.net>; <noc(a)visi.net>; <lhamilton(a)vistavdi.com>; <support(a)vitts.com>; <noc(a)voicenet.com>; <noc(a)voyager.net>; <support(a)vii.com>; <noc(a)w3internet.net>; <noc(a)professionals.com>; <noc(a)webex.com>; <soc(a)corp.webtv.net>; <noc(a)webzone.net>; <noc(a)willamette.net>; <noc(a)wcg.net>; <support(a)wineasy.se>; <noc(a)wolfe.net>; <support(a)worldpath.net>; <noc(a)wyoming.com>; <nox(a)xcom.net>; <noc(a)xnet.com>; <stlnoc(a)xo.com>; <ops(a)xtratyme.com>; <netops(a)uk.yahoo-inc.com>; <info(a)zenon.net>; <noc(a)zeroknowledge.com>; <noc(a)ziplink.net>; <noc(a)zocalo.net> Sent: Monday, November 25, 2002 6:47 PM Subject: Re: [digitalwest.net #1368] Moratorium. > My guess is you are trying to reach Qwest Communications. If you got > our info off of the puck.nether.net NetOps page we've been trying to get > a typo fixed on there forever... :) > > -jr > > * ""Meslovich(a)wiggum.snlo01.digitalwest.net <""Meslovich(a)wiggum.snlo01.digitalwest.net> [20021120 10:13]: > > Hello, my name is Jim I am the Transport NOC Manager at ICG > > Telecommunications. I would like to know if you will be working under a > > moratorium during the holidays? I am also interested in building a solid > > working relationship between our departments. Please respond with contact > > information so that we can begin working together. > > > > Sincerely, > > > > Jim Meslovich > > NOC Transport Manager > > W Ph. 303-414-8087 > > Pager 303-826-6931 > > Cell 303-915-6344 > > James_Meslovich(a)icgcomm.com > > <<Meslovich, James.vcf>> > > -- > Josh Richards - <jrichard _at_ digitalwest.net> > Digital West Networks, Inc. - http://www.digitalwest.net > San Luis Obispo, CA 93401 - phone://+1-{888,805}-781-9378 >

6 5

Re: PAIX
by Michael.Dillon＠radianz.com 26 Nov '02

26 Nov '02

> > To power the IPv6 networks of refridgerators, ovens, and light switches, > > as well as your 3G video conferencing phone >None of these applications have any requirement for peering every 100km2. >I'd expect my refrigerator, oven, light switches, etc. to be behind my >house's firewall and only talk using link-local addresses anyways. Do you know how much traffic the high resolution MPEG4 video/audio stream from an oven uses!? Why on earth would a network operator want to haul that kind of traffic hundreds of kilometers when 99.5 % of it is going to a 3G mobile phone in the same city. Remember that this video stream from the oven is going to be carry far more data than the phone can handle so that the mobile phone operator can provide a zoom-in application that allows the customer to zoom in on a hotspot on the surface of the turkey to better evaluate whether to switch the oven from roast to broil. Oh, BTW, ask someone at Cisco to explain to you how firewalls work. Their purpose is security, not reduction in PPS or bps. People in general will communicate a lot more with other people who live nearby no matter what the communications medium. Therefore it is likely that as the Internet becomes a commonplace everyday tool for commonplace everyday communications, the vast majority of the traffic will be relatively local. And while there may be some technical gurus who believe in the purity of running a few mega peering points, over the long haul, the customers of networks will reject this kind of centralized system in the same way that they are rejecting every other form of centralized control. --Michael Dillon

4 3