- NANOG - lists.nanog.org

Re: Readiness for IPV6
by Niels Bakker 14 Jul '02

14 Jul '02

> Niels Bakker wrote: >> It would also be nice if operators with end users started offering >> native multicast. Although the AMS-IX multicast initiative started >> off with lots of enthusiasm, two years later it seems to have died >> almost completely. * pete(a)he.iki.fi (Petri Helenius) [Tue 09 Jul 2002, 15:27 CEST]: > Most multicast projects go this way. The reason usually being one or more of; > A) ISP's want to charge extra for multicast > B) No content is being served over multicast > C) Firewalls do not pass multicast (usually non-issue on home users) Indeed. I'm personally most amazed that B) companies like shoutcast.com (who must be spending fortunes on bandwidth for all their streams) aren't pushing multicast more. Cheers, -- Niels.

17 27

Re: The Cidr Report - web site inaccessible ?
by Gregory Hicks 14 Jul '02

14 Jul '02

> Date: Sun, 14 Jul 2002 21:36:01 +0300 (IDT) > From: Rafi Sadowsky <rafi-nanog(a)meron.openu.ac.il> > > Is it just me ? Internet-wide. I sent a note to Philip Smith re this very item. The wesite IS down. > Date: Sun, 14 Jul 2002 08:56:34 +1000 > From: Philip Smith <pfs(a)cisco.com> > > Gregory, > > Yes, the website is down at the moment due to a failure on the server - > I'm told it will be back in the next few days... Sorry about this. > We'd no obvious way of telling everyone without spamming the whole > mailing list... > > (If it isn't back by the next report, I'll have to do that..) > > best wishes! > > philip > -- At 00:07 13/07/2002 -0700, Gregory Hicks wrote: >Um-m-m-m... I tried to get to your report... But failed with this >error for each URL (listed below) shown in the CIDR report. [...snip...] Unquote Regards, Gregory Hicks > [...snip remainder of both messages...] --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479 San Jose, CA 95134 | Internet: ghicks(a)cadence.com Never attribute to malice that which is adequately explained by ignorance or stupidity. Asking the wrong questions is the leading cause of wrong answers "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton You can have it done good, fast, or cheap -- pick any two.

2 1

no-export problem resolved
by Stephen Stuart 14 Jul '02

14 Jul '02

The problem I had with one of my upstreams' handling of no-export has been resolved. They were, you'll be happy to hear, full of desire to do the right thing (and had apparently been doing it until the syntax for doing so changed out from under them, so clearly you can't turn your back on those router vendors) and the ticket was closed. So, yes, my assertion that no-export support was not built-in was wrong. Mea culpa. Stephen

1 1

The Cidr Report
by CIDR Report 14 Jul '02

14 Jul '02

This is an auto-generated mail on Fri Jul 12 23:00:00 PDT 2002 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amount of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 12Jul02 0) General Status Table History ------------- Date Prefixes 050702 110820 060702 111129 070702 111069 080702 111088 090702 111212 100702 111153 110702 111369 120702 111339 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 13208 Number of ASes announcing only one prefix: 8040 (4516 cidr, 3524 classful) Largest number of cidr routes: 615 announced by AS3908 Largest number of classful routes: 1230 announced by AS701 1) Gains by aggregating at the origin AS level --- 12Jul02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1089 840 249 22.9% Telstra Pty Ltd AS701 1230 982 248 20.2% UUNET Technologies, Inc. AS17557 304 107 197 64.8% Pakistan Telecom AS6595 221 54 167 75.6% DoD Education Activity Network As AS852 549 407 142 25.9% Telus Advanced Communications AS7018 794 668 126 15.9% AT&T AS16473 195 77 118 60.5% Bell South AS7303 167 72 95 56.9% Telecom Argentina Stet-France Tel AS4151 235 140 95 40.4% USDA AS19632 99 5 94 94.9% Metropolis Intercom S.A. AS1239 519 425 94 18.1% Sprint AS12302 118 30 88 74.6% MobiFon S.A. AS16814 105 20 85 81.0% NSS, S.A. AS7046 315 231 84 26.7% UUNET Technologies, Inc. AS2048 181 103 78 43.1% State of Louisiana AS2149 367 294 73 19.9% Performance Systems, Inc. AS577 262 190 72 27.5% Bell Advanced Communications Inc. AS724 231 163 68 29.4% DLA Systems Automation Center AS4323 402 334 68 16.9% Time Warner Communications, Inc. AS3464 163 102 61 37.4% Alabama SuperComputer Network AS19834 64 4 60 93.8% NetForce, Inc. AS10620 84 24 60 71.4% TVCABLE BOGOTA AS1 444 386 58 13.1% GENUITY AS16758 63 6 57 90.5% IKON Office Solutions AS3908 296 240 56 18.9% Supernet, Inc. AS209 310 254 56 18.1% Qwest AS9498 83 28 55 66.3% BHARTI BT INTERNET LTD. AS9051 81 29 52 64.2% INCONET Autonomous System AS6535 65 16 49 75.4% Chilesat Servicios Empresariales AS703 271 225 46 17.0% UUNET Technologies, Inc. Total 54793 42301 12492 22.8% For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

2 1

Re: QoS/CoS in the real world?
by JC Dill 14 Jul '02

14 Jul '02

On 04:46 PM 7/13/02, Stephen J. Wilcox wrote: >I conclude either the people doing this are successful and keep their secret >safe or the world is yet to sell largescale QoS across IP. There's a world of difference between "sell" and "actually provide". IMHO, QoS is sold by many networks, but not actually provided (at the router). What IS provided is a system to give the QoS paying Customer credit if they A) notice they didn't get the quality of service their contract specified, and B) they request a credit. jc

3 2

RE: No one behind the wheel at WorldCom
by Frank Scalzo 14 Jul '02

14 Jul '02

What vendor by default does not take action on no-export??? Certainly cisco and juniper both honor it by default. To get back to the original question of 63/9 being announced it can be entertaining to watch for other fishy routes to show up in the routing table, like 63/8. I know of at least one outage caused because someone advertised a route like that. The underlying problem, is that there are no good widely deployed solutions for controlling what the large backbones inject into the routing table at peering points. A large tier 1 deaggregates towards another bad things happen. It would be nice if there was a supportable way to only allow one isp to advertise appropriate routes to another. The IRR stuff is a neat idea but I dont think many ISPs trust it enough to use it to build ACLs. -----Original Message----- From: Stephen Stuart [mailto:stuart@tech.org] Sent: Sat 7/13/2002 7:00 PM To: nanog(a)merit.edu Cc: Paul Schultz Subject: Re: No one behind the wheel at WorldCom > I'm wondering how many folks out there choose not to honor this > community and why. If anyone on the list chooses not to I'd be > interested to hear (either on-list or off) the reasonings behind it. Please also respond if you weren't aware that you have to explicitly implement the policy of honoring no-export - while the community vaue is "well-known," the policy is not built-in.

3 3

No one behind the wheel at WorldCom
by Phil Rosenthal 14 Jul '02

14 Jul '02

BGP routing table entry for 63.0.0.0/9, version 7001923 Paths: (5 available, best #1, table Default-IP-Routing-Table) Advertised to peer-groups: customer Advertised to non peer-group peers: 209.123.37.30 701 157.130.9.141 (metric 65024) from 209.123.11.10 (209.123.12.59) Origin IGP, localpref 300, valid, internal, best Community: 8001:666 8001:701 701 157.130.9.141 (metric 65024) from 209.123.11.245 (209.123.12.59) Origin IGP, localpref 300, valid, internal Community: 8001:666 8001:701 8001 7911 3561 701 64.200.86.149 from 64.200.86.149 (64.200.87.10) Origin IGP, localpref 200, valid, external Community: 8001:666 8001:7911 7911 3561 701, (received-only) 64.200.86.149 from 64.200.86.149 (64.200.87.10) Origin IGP, localpref 100, valid, external 15036 16631 174 701 209.123.37.30 from 209.123.37.30 (209.123.132.181) Origin IGP, localpref 100, valid, external Community: 8001:666 8001:16631 15036:0 15036:666 15036:16631 16631:1000 From: http://eng.nac.net/lookingglass/nyc.html Bgp: 63.0.0.0 Uunet has been announcing this for more than 2 days now. (not sure when since I cleared my bgp tables 2 days ago). --Phil

8 16

KPNQwest to be shut down ?
by Andre Chapuis 14 Jul '02

14 Jul '02

http://www.cbronline.com/cbr.nsf/latestnews/3D7D494A2E3C728A80256BF4001084B… 07/12/2002 Curtain Being Drawn on KPNQwest Network The future of the KPNQwest network looks bleak, after the Customer Support KPNQwest foundation decided to withdraw its support for the operation from 23.00 hours tonight. The foundation was co-founded by Dutch carrier KPN NV to enable the bankrupt network to continue operating while possible buyers were found. Yesterday KPN said that much of the network had already been sold off and customers had found alternative options. Consequently, traffic had dropped and "the foundation sees no reason to continue supporting the network." Dutch incumbent KPN added that "the receivers and banks have still not responded positively to KPN's offer to take over the remaining sections of rings 1,2 and 3 in of the KPNQwest network in Northwestern Europe". KPN added that as far as it was aware, its offer was the only concrete one. It said, "whether the Foundation's decision to stop support of the network leads to its closure depends on the receivers and the banks." --------------------- André Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 chapuis(a)ip-plus.net CCIE #6023 ---------------------

3 2

Re: Paying for delivery of packets (was about Sprint Peering, and Importance of Content)
by JC Dill 13 Jul '02

13 Jul '02

On 11:31 AM 7/11/02, E.B. Dreger wrote: > >JD> Date: Thu, 11 Jul 2002 08:37:01 -0700 >JD> From: JC Dill > > >JD> It is my opinion that eventually the Internet will be mostly >JD> funded by those who send packets, and will be mostly free for >JD> those receiving said packets, much in the way that 800 >JD> numbers are funded in the telephone system. In order for >JD> that to work, we will need a settlement system. I predict >JD> that something like this will start happening before >JD> 12/2005. > >Agreed, except is any fancy settlement really needed? I predict >asymmetric pricing. The problem with asymmetric pricing is that the cost of passing the packets is equally born by both ends. Take 2 networks that peer, one with mostly content, one with mostly eyeballs. The content providers pay a higher price *per MB* for bandwidth to their provider than the end user does, but both networks have equal costs in transiting the packets from the server to the end user. >>From a political standpoint, it's easier to get a business to pay >an extra <x> per month to deliver their content than it is to get >Joe Public to pay an extra $10/mo for premium access. Joe's ISP needs to pay for fat pipes to get the data (from wherever Joe's ISP peers with the content provider's network) to Joe's eyeballs. That cost has to be borne by someone. Either Joe pays an equally high rate (per MB) for incoming packets as the content provider pays for sending them, or the content provider pays and there are settlements between the content provider's network and the Joe's network. My premise is that in the end, content providers want to send lots of packets more than end users want to pay to receive them. Joe is not willing to pay an equally high rate to get the packets that content providers are willing to pay to send them. Thus, settlements. >I think 12/2005 is conservative. Industry fallout begins >settling, and we see interesting tactics from "new breed" >upstarts run by laid-off engineers with a bit of money and a >bunch of clue. Beginning of 2005, significant presence by the >end of the year. I was hedging my bet. :-) I wouldn't be at all surprised to see it much sooner, even by the end of 2002. jc

4 4

OT - Importance of Content
by Owens, Shane (EPIK.ORL) 13 Jul '02

13 Jul '02

I was wondering the importance of content to IP providers. Is it feasible to go after a lot of hosting companies and such as a business model and greatly skew your traffic ratios to hopefully reach a critical mass. I would think at some point you would have so much content that people would start to come to you for peering or to purchase access to get to that content which would cause a reduction in overall transit costs, but what would that critical mass be and how valid is that thought? Opinions? Shane Owens

7 7