- Test - lists.nanog.org

The Cidr Report
by cidr-report＠potaroo.net 04 Feb '05

04 Feb '05

This report has been generated at Fri Feb 4 21:40:00 2005 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 28-01-05 150969 103249 29-01-05 151037 103352 30-01-05 151188 103402 31-01-05 151242 103080 01-02-05 151393 103170 02-02-05 151585 103143 03-02-05 151613 103143 04-02-05 134555056 103143 AS Summary 0 Number of ASes in routing system 0 Number of ASes announcing only one prefix 1440 Largest number of prefixes announced by an AS AS7018 : ATTW AT&T WorldNet Services 0 Largest address span announced by an AS (/32s) pp) : Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 04Feb05 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 151613 103143 48470 32.0% All ASes AS7015 796 22 774 97.2% CCCH-3 Comcast Cable Communications Holdings, Inc AS18566 768 7 761 99.1% CVAD Covad Communications AS4134 835 202 633 75.8% CHINANET-BACKBONE No.31,Jin-rong Street AS4323 839 226 613 73.1% TWTC Time Warner Telecom AS721 1127 578 549 48.7% DNIC DoD Network Information Center AS7018 1440 962 478 33.2% ATTW AT&T WorldNet Services AS27364 460 34 426 92.6% ARMC Armstrong Cable Services AS22773 442 21 421 95.2% CXA Cox Communications Inc. AS6197 847 449 398 47.0% BNS-14 BellSouth Network Solutions, Inc AS6478 501 114 387 77.2% ATTW AT&T WorldNet Services AS3602 493 140 353 71.6% SPCA Sprint Canada Inc. AS22909 421 71 350 83.1% CMCS Comcast Cable Communications, Inc. AS1239 938 625 313 33.4% SPRN Sprint AS9929 340 35 305 89.7% CNCNET-CN China Netcom Corp. AS17676 391 103 288 73.7% JPNIC-JP-ASN-BLOCK Japan Network Information Center AS4766 566 279 287 50.7% KIXS-AS-KR Korea Telecom AS14654 262 7 255 97.3% WAYPOR-3 Wayport AS6140 379 134 245 64.6% IMPSA ImpSat AS9443 366 121 245 66.9% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4355 300 64 236 78.7% ERSD EARTHLINK, INC AS25844 244 15 229 93.9% SASMFL-2 Skadden, Arps, Slate, Meagher & Flom LLP AS9583 574 351 223 38.9% SIFY-AS-IN Sify Limited AS6198 446 224 222 49.8% BNS-14 BellSouth Network Solutions, Inc AS15270 248 34 214 86.3% PDP-14 PaeTec.net -a division of PaeTecCommunications, Inc. AS2386 812 602 210 25.9% ADCS-1 AT&T Data Communications Services AS5668 431 227 204 47.3% CIH-12 CenturyTel Internet Holdings, Inc. AS23126 211 18 193 91.5% KTEL KMC Telecom, Inc. AS19632 191 8 183 95.8% Metropolis Intercom AS6517 301 119 182 60.5% YIPS Yipes Communications, Inc. AS9498 235 54 181 77.0% BBIL-AP BHARTI BT INTERNET LTD. Total 16204 5846 10358 63.9% Top 30 total Possible Bogus Routes 24.138.80.0/20 AS11260 AHSICHCL Andara High Speed Internet c/o Halifax Cable Ltd. 24.246.0.0/17 AS7018 ATTW AT&T WorldNet Services 24.246.38.0/24 AS25994 NPGCAB NPG Cable, INC 24.246.128.0/18 AS7018 ATTW AT&T WorldNet Services 64.17.32.0/24 AS5024 BRIDGE-75 BridgeNet, LC 64.17.33.0/24 AS5024 BRIDGE-75 BridgeNet, LC 64.17.37.0/24 AS5024 BRIDGE-75 BridgeNet, LC 64.46.27.0/24 AS8674 NETNOD-IX Netnod Internet Exchange Sverige AB 64.57.160.0/19 AS3561 SAVVI-3 Savvis 64.92.128.0/19 AS3561 SAVVI-3 Savvis 64.127.0.0/18 AS7018 ATTW AT&T WorldNet Services 64.209.192.0/18 AS3561 SAVVI-3 Savvis 69.26.32.0/19 AS17307 VIRTEL-15 Virtela Communications 132.0.0.0/10 AS721 DNIC DoD Network Information Center 137.0.0.0/13 AS721 DNIC DoD Network Information Center 138.136.0.0/13 AS721 DNIC DoD Network Information Center 158.0.0.0/13 AS721 DNIC DoD Network Information Center 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.30.127.0/24 AS719 ELISA-AS Elisa Oyj 192.40.105.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.44.0.0/19 AS702 AS702 MCI EMEA - Commercial IP service provider in Europe 192.70.164.0/24 AS11814 IGST Information Gateway Services - Toronto 192.81.182.0/24 AS719 ELISA-AS Elisa Oyj 192.81.183.0/24 AS719 ELISA-AS Elisa Oyj 192.81.184.0/24 AS719 ELISA-AS Elisa Oyj 192.119.135.0/24 AS270 NASA National Aeronautics and Space Administration 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.133.6.0/24 AS4004 GLOBALONE-EQUANT-UK Equant UK & Greece Autonomous System 192.135.50.0/24 AS7018 ATTW AT&T WorldNet Services 192.153.144.0/21 AS721 DNIC DoD Network Information Center 192.172.0.0/19 AS721 DNIC DoD Network Information Center 192.188.208.0/20 AS721 DNIC DoD Network Information Center 192.200.100.0/24 AS7018 ATTW AT&T WorldNet Services 196.2.95.0/24 AS8668 TELONE-AS TelOne Zimbabwe P/L 198.23.26.0/24 AS4390 BELLAT-7 Bell Atlantic, Inc. 198.97.72.0/21 AS721 DNIC DoD Network Information Center 198.97.80.0/20 AS721 DNIC DoD Network Information Center 198.97.88.0/24 AS89 NUSC-1 Naval Underwater Systems Center 198.97.240.0/20 AS721 DNIC DoD Network Information Center 198.97.247.0/24 AS3475 DEPART-52 Department of the Navy 198.101.4.0/22 AS721 DNIC DoD Network Information Center 198.136.32.0/20 AS19329 MCBCC Martin County Board of County Commissioners 198.144.32.0/19 AS3998 CITY CityNet, Inc. 198.161.87.0/24 AS6539 GTGR GT Group Telecom Services Corp. 198.163.155.0/24 AS684 MRN Manitoba Regional Network 198.167.0.0/16 AS7456 INS-51 Interhop Network SERVICES Inc. 198.167.163.0/24 AS15290 ACCA-2 Allstream Corp. Corporation Allstream 198.168.0.0/16 AS701 UU UUNET Technologies, Inc. 198.169.0.0/16 AS803 SASK SaskTel 198.232.133.0/24 AS23075 SKOTOS Skotos Tech, Inc 199.10.0.0/16 AS721 DNIC DoD Network Information Center 199.60.0.0/20 AS271 UBC-3 University of British Columbia 199.96.44.0/23 AS19092 360NE-1 360Networks (USA) Inc. 199.96.46.0/24 AS19092 360NE-1 360Networks (USA) Inc. 199.114.0.0/21 AS721 DNIC DoD Network Information Center 199.114.128.0/18 AS721 DNIC DoD Network Information Center 199.114.130.0/24 AS721 DNIC DoD Network Information Center 199.114.132.0/24 AS721 DNIC DoD Network Information Center 199.114.134.0/24 AS3541 DISAUN DISA/UNRRA 199.114.136.0/24 AS27044 DNIC DoD Network Information Center 199.114.138.0/24 AS721 DNIC DoD Network Information Center 199.114.140.0/24 AS3544 DISAUN DISA/UNRRA 199.114.142.0/24 AS721 DNIC DoD Network Information Center 199.114.144.0/24 AS721 DNIC DoD Network Information Center 199.114.148.0/24 AS721 DNIC DoD Network Information Center 199.114.150.0/24 AS721 DNIC DoD Network Information Center 199.114.152.0/24 AS27033 DNIC DoD Network Information Center 199.114.154.0/24 AS1733 ADP-41 AF DDN PMO 199.114.156.0/24 AS27034 DNIC DoD Network Information Center 199.114.160.0/24 AS1733 ADP-41 AF DDN PMO 199.120.32.0/19 AS16582 NXLI NEXTLEVEL INTERNET, INC. 199.121.0.0/16 AS721 DNIC DoD Network Information Center 199.123.0.0/18 AS721 DNIC DoD Network Information Center 199.123.16.0/20 AS721 DNIC DoD Network Information Center 199.123.80.0/21 AS721 DNIC DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST IQuest Internet 199.202.0.0/16 AS701 UU UUNET Technologies, Inc. 201.239.0.0/16 AS22047 VTR BANDA ANCHA S.A. 202.72.240.0/20 AS24320 RAILCOM Mongolian Railway Commercial Center Railcom 202.73.128.0/22 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.86.252.0/22 AS4748 RESOLINK-AS Resources Linke Network Limited 202.93.0.0/20 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 202.164.224.0/19 AS7599 IPXC-AS-AP IP Exchange 203.32.4.0/23 AS7617 TELEONE-HK TeleTeleOne (HK) Limited 203.62.0.0/17 AS7572 AARNET-ACT-RNO Australian Academic and Reasearch Network (AARNet) 203.99.0.0/19 AS17746 ORCONINTERNET-NZ-AP Orcon Internet 203.170.14.0/23 AS6648 ASN-SKYINTERNET Autonomous System Number peering of BAYANTEL 203.210.69.0/24 AS17536 PRODIGY-AS-AP Prodidgy Telecommunications 204.154.125.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.194.110.0/23 AS30653 EXOBI Exobit Networks Inc. 205.150.0.0/15 AS701 UU UUNET Technologies, Inc. 206.29.168.0/21 AS10248 IPI Internet Partners, Inc. 206.128.104.0/21 AS11709 VIIN VIRTUAL INTERACTIVE CENTER 206.167.57.0/24 AS376 RISQR-3 Reseau Interordinateurs Scientique Quebecois (RISQ) 206.191.64.0/18 AS15290 ACCA-2 Allstream Corp. Corporation Allstream 207.231.96.0/19 AS11194 NUNETI NuNet Inc 208.81.187.0/24 AS19194 SNL-8 Sentris Network LLC 208.138.48.0/20 AS7955 SOURCE-48 SourceNet Corporation 209.27.51.0/24 AS14132 INTERN-582 Internet Gateway Inc. 209.205.69.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.70.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.81.0/24 AS15066 SkyNet de Colombia S.A. 209.205.82.0/24 AS15066 SkyNet de Colombia S.A. 209.205.84.0/24 AS15066 SkyNet de Colombia S.A. 209.213.32.0/19 AS10629 INS-52 Inter-Pacific Network Services 209.213.48.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.49.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.251.0.0/19 AS11036 SISCOM-1 SISCOM, Inc 216.37.110.0/23 AS4264 CERFN California Education and Research Federation Network 216.96.128.0/18 AS7018 ATTW AT&T WorldNet Services 216.145.156.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.158.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.176.0/21 AS20304 JIS-32 JVLNET Internet Services 216.145.177.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.178.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.184.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.185.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.186.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.187.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.188.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.189.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.190.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.191.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.200.0/21 AS20304 JIS-32 JVLNET Internet Services 216.171.96.0/20 AS3356 LEVEL3 Level 3 Communications 216.186.151.0/24 AS3356 LEVEL3 Level 3 Communications 216.186.152.0/21 AS3356 LEVEL3 Level 3 Communications 216.186.160.0/23 AS3356 LEVEL3 Level 3 Communications 216.186.164.0/22 AS3356 LEVEL3 Level 3 Communications 216.186.192.0/22 AS3356 LEVEL3 Level 3 Communications 216.186.198.0/23 AS3356 LEVEL3 Level 3 Communications 216.186.248.0/23 AS3356 LEVEL3 Level 3 Communications Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org swinog(a)swinog.ch

1 0

RE: Time to check the rate limits on your mail servers
by Miller, Mark 03 Feb '05

03 Feb '05

How come it is always about controlling the symptoms and not the illness? The vast majority of these "spam drones" are compromised WINDOWS machines. If the operating system and dominant email applications so easily allows the users' machines to be taken over by a third party, then there is something wrong with the operating system and the mail applications. It occurs to me that the solution is not to limit the range of destruction, but to defuse the bomb. Perhaps the focus for a solution should move up the model to layer 7. - Mark -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Michael.Dillon(a)radianz.com Sent: Thursday, February 03, 2005 8:47 AM To: nanog(a)merit.edu Subject: Re: Time to check the rate limits on your mail servers > > Do you let your customers send an unlimited number of emails per > > day? Per hour? Per minute? If so, then why? > > Doing that - especially now when this article has hit the popular > press and there's going to be lots more people doing the same thing - > is going to be equivalent of hanging out a "block my email" sign. I don't understand your comment. This is an arms race. The spammers and botnet builders are attempting to make their bots use the exact same email transmission channels as your customers' email clients. They are getting better at doing this as time goes on. I think we are at the point where the technical expertise of the botnet builders is greater than the technical expertise of most people working in email operations. ...

5 4

Qwest in bid to acquire MCI
by Hannigan, Martin 03 Feb '05

03 Feb '05

UUQwest? http://www.reuters.com/financeNewsArticle.jhtml?type=bondsNews&storyID=75273 08 -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan(a)verisign.com

1 0

RE: long as path games - additional question
by Chris Burton 02 Feb '05

02 Feb '05

Well there are many reasons but the most common in my opinion is that usually people do this to influence route preference; by pre-pending your own AS path several times you effectively make the route less desirable to use. Chris -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Gniewomir Krol Sent: Tuesday, February 01, 2005 3:18 AM To: nanog(a)merit.edu Subject: long as path games - additional question hello there, perhaps it's trivial question ( if so, please give mi direction to some source of information); suppose i've received as-path which contains about 8 as-numbers, four of which are the same; what exactly this could mean? thanks in advance, best regards, gk

1 0

NANOG 33 Peering BOF VIII Notes
by William B. Norton 02 Feb '05

02 Feb '05

For those of you who could not attend or listen in to the Peering BOF VIII Monday evening: Here are my notes from the NANOG 33 Peering BOF VIII held late Monday Night...(comments welcome.) We started the Peering BOF VIII at 9:00 PM Monday Night, and we voted on the ranking of the nine issues that peering folks shared with Bill as "Things on the mind of Peering Coordinators in 2005": 1. Peering vs. Transit tradeoff 33 2. Capacity Planning for Peering 10 3. Traffic Analysis Tools Needed 15 4. Comcast still doesn't peer 14 5. De-peering 1 6. Remote Peering 3 7. VOIP Peering 15 8. Peer2Peer Traffic (40%-70%) 6 It was interesting that so many people said that "Peering vs. Transit tradeoff" was highest on the list, and that this was by a factor of 2:1 over the next largest issues. The next three items of interest to the Peering Community were Traffic Analysis Tools (15), VOIP Peering (15) and "Comcast still not Peering" (14). ------------------------------------------------------------- The Great Debate The Great Debate was on the topic of "Remote Peering" – the practice of peering without a collocated router at an IX. This has emerged as a *contentious* issue primarily across the Wide Area – peering from Europe by connecting to a US IX via MPLS-encapsulated Ethernet frames for example. The Pro side (Remote Peering is a good thing) was presented by Patrick Gilmore and the Con side (Remote Peering is a bad thing) was presented by Stephen Wilcox. Key Points from Patrick (why remote peering is a good thing): 1) Peering Costs of router, colo, local loop, etc. can be removed from the cost equation enabling companies to peer 2) The underlying method of getting to the IX should be irrelevant to the peer 3) Many MPLS providers deliver highly robust and stable services, at least as reliable as SONET alternatives. 4)Allows company to meet geographic diversity requirements for peering 5)Remote Peering transport is metered so allows companies to pay for only what they use Key Points from Stephen (why remote peering is a bad thing) 1)Remote Peering is more complex, more network elements to break, leads to BGP instability which hurts everyone 2)Debugging underlying infrastructure is more difficult if not impossible 3)Remote Peering allows peers to circumvent the intent of the geometric distribution requirements in peering policies. For example, one can meet a peer on the East Coast, West Coast and in the middle to meet the three time zones requirement without having the expected underlying infrastructure (multiple routers connected by circuits). A single router failure could bring down all peering sessions with the Remote Peer. 4) Remote Peering instability potential – it implies multiple l2 interconnected nets which may introduce probs ie loops may also allow problems to spill between l2 systems such as IXes 5) Greater Variability in Peering Performance - reroutes may cause ccts to do strange things such as switching to a much longer path. You don't see this with SONET. 6) Detrimental to the Community - the other isp may want equal peers not a network over extending themselves just to save a few $$s and this may lead to peers increasing their peering requirements ie volume/locations which will be detrimental to the genuine networks Both debaters sparred on these points a second round, with a reinforced point from Patrick that a peer should *not* need to care about the others peer's implementation of infrastructure, only that the peering sessions are stable or not. The debaters summed their arguments, and we took a vote: THE VOTE: "Which debater presented the more compelling case." Stephen Wilcox (Con: Remote Peering is a bad idea) 11 Patrick Gilmore (Pro: Remote Peering is a good idea) 50 --------- We invited the audience to chime in and present points that did not come up in the debate. There were many additional good points raised, and the discussion in the community was very lively. Notable among these points: - "Peers" implies similar investment in infrastructure and similar benefits from peering – a similar distribution of customers and content. Remote peering circumvents this perceived notion of fairness." Peering increasingly involves signing NDAs and exchanging network maps and the fake peering would be found out here or during an outage in either case, peering policies would not change and appropriate depeering would result. -Lack of visibility is critical in operations- when things break, a simple infrastructure (layer3 routers, layer 1 circuits with framing) provides visibility essential for debugging. - Route Convergence becomes an issue if a single router is used with tentacles all over the world remotely peering. Price seems to be the main driver – you only do remote peering if you are poor and trying to save capex and colo/IX fees. Maybe you shouldn't be peering then. +The ability to try an IX before you buy without going through a difficult install is a strong benefit of remote peering. +Lack of visbility is lessened when Remote Peering is used for Private Peering +It is a fallacy that "It just feels wrong" - The world is complex – deal with it! +The guys running these MPLS cloud are doing a great job; you may seen some latency/jitter during regrooming but that is about it. Not that instable. +Saves money, both capex and opex - Creating a "Fake" network to meet peering prereqs is not generating an ideal Internet topology. - May save $ but Peering Policies will soon adjust to deal with this, making it difficult for "real" networks to get peering. - General – More Complexity->More Problems->BGP instability for all of us Community VOTE: We took a different vote, given the points raised by the broader audience along with the debater points, asking the question: Is remote peering a good thing? 33 Is remote peering a bad thing? 24 Interesting – I would have thought the peering coordinators would have said uniformly that remote peering was a bad thing, but given all the points shared and discussed, the Peering Community in the room were clearly more accepting of remote peering. Peeringdb.com – Richard Steenbergen Richard shared his community service project to collect and disseminate Peering Contacts in the Peering Coordinator Community. The group felt this was a valuable and noble endeavor and thanks Richard for taking this on. ------------------------------------------ Peering Personals Yahoo! AS#: 10310 US, 15635 in the UK Brokaw Price bprice(a)yahoo-inc.com Samsung Networks AS#: 6619 Woohyong Choi <woohyong.choi(a)samsung.com> McLeodUSA Telecommunications AS#: 7228 Thomas Barrera tbarrera(a)mcleodusa.com VitalStream, Inc. AS#:13980, 30282, 30636, 30637 Kim W. Summers ksummers(a)vitalstream.com NASA UNITeS / SAIC AS#: 297 Michael Turner Michael.S.Turner(a)msfc.nasa.gov USC AS#: 226 Walt Prue prue(a)usc.edu CENIC AS#: 2152 Darrell Newcomb darrell(a)cenic.org Company: Akamai Technologies AS#: 12222, 20940 • Patrick W. Gilmore patrick(a)akamai.com Title: Director, Network Strategy & Support Webair Internet Development Inc AS#: 27257 Sagi Brody sagi(a)webair.com TELUS AS#: 852 Domenica Roda / Geoffrey Holan <Domenica.Roda(a)telus.com> <Geoffrey.Holan(a)telus.com> Net Access Corp. AS#: 8001 Steven J. Schecter <sjs(a)nac.net> Giganews AS#: 30094 Edward Henigin ed(a)giganews.com University of Washington / Pacific Northwest Gigapop AS#: 73 / 101 Dave McGaugh dmcgaugh(a)cac.washington.edu Electric Lightwave, LLC AS#: 5650 Steven Raymond <sraymond(a)eli.net> China Telecom (USA) AS#: 4134 Joe Zhu <ctusa_joe(a)yahoo.com> ESnet AS#293 Name:Yvonne Hines peering(a)es.net -------------------------------------- Closing – The Peering BOF closed around 11:00 but people hung around and talked toward midnight. This time slot might be a bit tough for those on Eastern Time who were effectively up until 3AM discussing peering, and rehashing the great debate. -- //------------------------------------------------ // William B. Norton <wbn(a)equinix.com> // GSM Mobile: 650-315-8635

1 0

Verizon DSL email policy
by doug＠safeport.com 02 Feb '05

02 Feb '05

It appears that Verizon is blocking our mail server. Calls to the online DSL support center have produced a unique answer to each call. A sampling: there is no problem; customers with dynamic IP addresses can not use 3rd party email servers either to read or send mail; ditto but a universal policy; you have been declared a spam source; hung up on; hmmmm. One call got a guy that attempted to help. Any clueful insights appreciated. _____ Douglas Denault http://www.safeport.com doug(a)safeport.com Voice: 301-469-8766 Fax: 301-469-0601

3 3

An Optical Revolution may be Undermining Carrier Viability
by Gordon Cook 02 Feb '05

02 Feb '05

Here is an abstract of a study I have just completed. Enjoy. Optical Revolution Increases Obsolescence of Legacy Carrier Networks Highly Efficient Layer One and Two Optical Networks Will Spell End of the Road for ATT, Sprint & MCI in Their Current Form Intelligent Acquisition Could Lead to Quick Write Offs of Obsolete Equipment & Result in Modernization of "Telco" Infrastructure An examination of the infrastructure of the Leading optical research networks (SURFnet 6, CA*Net4, and TransLight) shows that we may well be headed towards optical networks owned, built, and operated by enterprises and other large entities that are sources of, and/or, sinks for data, with the public Internet and carrier backbone networks merely acting as inter-connecting vehicles for private bit carriage. We examine the emergence of new enterprise-owned and -operated networks. These will be composed of hybrid networks that, for certain Quality of Service and security-mandated applications set up lightpaths, when needed, and then tear them down. Best-effort Layer 3 IP services for email and web browsing will utilize a separate allocation of bandwidth elsewhere within the optical spectrum of physical glass. This new enterprise-owned optical network is likely to be one that could switch lightpaths back and forth on an as-needed basis sending payloads over dedicated lightpaths where appropriate and needed, while best-effort routing continues to function on its own over intranet or Internet routes, thus filling in the gaps between highly mission-critical and business-as-usual applications. For independent verification of our basic conclusions see Dark fiber: Businesses see the light. http://news.com.com/Dark+fiber+Businesses+see+the+light/2100-1037_3-5557910… For complete Introduction and Executive Summary and Table of contents see http://cookreport.com/14.01.shtml -- ============================================================= The COOK Report on Internet Protocol, 431 Greenway Ave, Ewing, NJ 08618 USA 609 882-2572 (PSTN) 415 651-4147 (Lingo) cook(a)cookreport.com Subscription info: http://cookreport.com/subscriptions.shtml New report: Optical Research Net- works and an Enterprise Networks Revolution at: http://cookreport.com/14.01.shtml =============================================================

1 0

long as path games - additional question - CASE CLOSED ;)
by Gniewomir Krol 01 Feb '05

01 Feb '05

hello there, thanks a lot for your support (public and private); now it looks clear for me; once again, thanks for your time; regards, gk

1 0

Vendor Vulnerability Release Problem
by Hannigan, Martin 01 Feb '05

01 Feb '05

I attended the ISP Security BoF this evening and listened to Juniper and Cisco defend their positions of determining who gets notifications first. Decent talk. Folks did defend the "you need to reach us" to get the patch method, but some of it was "me too" I'd like to suggest to the Program Committee that a talk related to just this be solicited at the next NANOG and include all of the vendors who want to participate. They did concur that the current system is broken. This is part of the reason I decided to post this. To let everyone know that this is a problem and the vendors agree. I *was disappointed in was the harsh criticism of DHS. The vendors called DHS and the Pentagon the biggest source of leaks related to 'their' security vulnerabilities. I don't know if that's true, but if they are, I hope they're leaking to the right people. Thanks to Juniper and Cisco for holding the talk. -M< -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan(a)verisign.com

2 1

RE: Vendor Vulnerability Release Problem
by Hannigan, Martin 01 Feb '05

01 Feb '05

> -----Original Message----- > From: mathews(a)uhunix2.hawaii.edu [mailto:mathews@uhunix2.hawaii.edu]On > Behalf Of Robert Mathews > Sent: Tuesday, February 01, 2005 11:01 AM > To: Hannigan, Martin > Subject: Re: Vendor Vulnerability Release Problem > > > > > On Tue, 1 Feb 2005, Hannigan, Martin wrote: > > > Date: Tue, 01 Feb 2005 01:17:42 -0500 > > From: "Hannigan, Martin" <hannigan(a)verisign.com> > > To: "'nanog(a)merit.edu'" <nanog(a)merit.edu> > > Subject: Vendor Vulnerability Release Problem > > > > > > [ .... ] > > > > They did concur that the current system is broken. This is > part of the > > reason I decided to post this. To let everyone know that this is a > > problem and the vendors agree. > > > Martin: > > Thank you for posting this note, as the subject item is of immense > interest to me personally, and to many within US Government. > My question, > which I will pose to you shortly -- is a broader one; one > that goes beyond > the world of ISPs and NSPs to the vastness of the IT world. > Still, your > concerns are very much valid in such an area as well. > > Before I go forward, I would like to disclose that I do not > attend NANOG > meetings regularly. > > With regard to your post Martin, I would like to ask you -- > just how you > see it, when you say: that "they did concur that the current system is > broken." Studies done within Government indicate a LARGER > problem than > 'after-incident action' which directly points to vendor > acknowledgement > itself. I am not at liberty to provide further details to > the studies or > their details but, it suffices to say that vendor behavior > is seen as a > significant problem. So, what of Vendor Behaviour? There appeared to be a consensus that the current methodology is broken. The vendors stated this themselves. The two presenters would need to clarify that further. As far as vendor behavior is related, I can't comment on that. It was clear, at least to me, there is no transparent or uniform method of distributing serious vulnerabilities. At least that participants of NANOG are aware of. I will concur that the vendors may not currently have a way to proceed with these problems, but I don't know that the operator community, ground zero for these vulnerabilities, hasn't been consulted as a whole. ((archives)). > > I *was disappointed in was the harsh criticism of DHS. The > vendors called > > DHS and the Pentagon the biggest source of leaks related to > 'their' security > > vulnerabilities. I don't know if that's true, but if they > are, I hope > > they're leaking to the right people. > > > Since I was not there for the discussion, I could not > appropriately relate > to the exchange held but, I would just like to understand if > I may -- what > the perception by the many gathered of DHS and the Pentagon were > respectively. My interpretation of the event was that the speakers considered DHS and the Pentagon to share some level of responsibility as to why vendors can't detail serious vulnerabilities. The feedback seemed to deride the Pentagon more than DHS. I can't gauge what the participants felt. As a guess, I think it was believable in the way it was presented. The overall impression was that the relevant government agencies are not credible. (I disagree from my own experience). > If you feel that this matter would be of interest to the > NANOG community, > do feel free to re-post. Reposted whole. > > > > -M< > > Thank you for your time Martin.. > > > Best, > Robert. > ------- > > ************************************************************** > ************* > * Robert Mathews, MSc. - Mgmt. (Honors), Ad.PD. - Econ. (Honors) > * Chancellor's Professor of Science & > * Distinguished Senior Scholar on > * National Security Affairs & U.S Industrial Preparedness > * @ University of Hawai'i > * Telephone: 315.853.7853 (NY) / 703.655.7124 (VA/WDC) > * Telecopier: 808.933.3473 (HI) / 315.859.1998 (NY) > * E.mail: mathews(a)hawaii.edu >

1 0