October 2001 - routing-wg - mailman.ripe.net

Re: more specific routes in today reality
by Gert Doering 10 Oct '01

10 Oct '01

Hi, On Tue, Oct 09, 2001 at 10:00:37PM +0100, Aled Morris wrote: > On Tue, Oct 09, 2001 at 09:29:54PM +0200, Gert Doering wrote: > >If you want to be multihomed, the costs for routers & co. are far higher > >than for being LIR. If you can't afford being LIR, be single-homed. > > Surely there is more to being a LIR than simply as a way of buying a /20 > for multihoming! Yes. > RIPE is effectively a member-run organisation; being an LIR means taking > part responsibility and getting involved via the working groups. Yes. > The argument "buying the RIPE membership is cheaper than the router you > need to run full BGP" basically sends a message that anyone with enough > money can buy their own /20 and AS number without having to justify how > they will use the address space, and without any obligation to the > Internet community at large. Which is not the way it should be (and it is not, according to policies), but you're twisting my sentence without quoting the statement above. Jan was complaining that it's too expensive to become a LIR. I put that cost into relation to the cost people have to pay anyway if they want to do *proper* multihoming, or put more precisely, be part of the default-free zone. And compared to that cost, becoming a LIR should be the least of your worries. I do not advocate that everybody that wants to have globally visible address space become a LIR. It is one way, for ISPs it's a good way (because it means you can handle address requirements of your customers in a practical and direct way), but for other entities it might be the wrong way. But *costs* are not a good criterium to decide that. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

3 2

RE: more specific routes in today reality
by Lu, Ping 10 Oct '01

10 Oct '01

Comments followed. > > Hi, > > On Tue, Oct 09, 2001 at 09:13:05PM +0200, Jan-Ahrent-Czmok wrote: > > Some providers are multihomed > > but cannot cover the costs, even for a small lir. > > If you want to be multihomed, the costs for routers & co. are > far higher > than for being LIR. If you can't afford being LIR, be single-homed. > Great! Now we have to collect routing policies from thousands of small LIRs while still have to deal with thousands of small prefixes. > > Nonsense. Nobody is announcing 192.0.0.0/8, or supernets of other's > networks - and what is in the RIPE database doesn't affect routing. > > To show the first few things from 192/8: > > *>i192.0.32.0 195.158.244.133 100 0 > 1755 1239 5676 226 > i > *>i192.0.34.0 195.158.244.133 100 0 > 1755 1239 5676 226 > i > * i192.0.36.0 195.206.66.61 3 100 0 > 3300 701 2914 20144 > i > *>i 195.158.244.133 100 0 > 1755 1239 2914 2014 > 4 i > * i192.1.0.0/16 195.206.66.61 3 100 0 > 3300 701 1 i > *>i 195.158.244.133 100 0 > 1755 1239 1 i > * i192.2.0.0/16 195.206.66.61 3 100 0 > 3300 701 1 i > *>i 195.158.244.133 100 0 > 1755 1239 1 i > > so if I filter those, why should the traffic go to XLink? > Why should > *any* traffic go to RIPE? It will be just blackholed (or > default-routed > to one of my upstreams, if I happen to have a default-route). > > Please do your homework about routing and BGP before selling people > consulting about multihoming. > Now more and more major ISPs are filtering out routes from other ISPs ( becuase we don't have transit agreements) so the multi-homed customer have to have their own AS. And if the major ISPs stop listening to the more specfic routes then even using the address from PI space won't work (unless you are big enough). All these solutions kind of imply that if you can't have /20 prefix then you can't be multi-homed. What happen if a customer want to have an OC-48 multi-homed link but only use prefix < /20 (that happens to the Internet Exchange people a lot ) ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

3 3

Reminder: RIPE-181 to RPSL Migration; Phase 3.
by Andrei Robachevsky 09 Oct '01

09 Oct '01

Dear Colleagues, [Apologies for multiple messages] On and from Monday, 15th October, 2001, the RIPE Database will no longer accept updates in RIPE-181 format. Mail robot at <auto-181(a)ripe.net> will be shutdown. The update path for the TEST database will also be changed. We plan to discontinue <test-181(a)ripe.net> service on 11th October, 2001. If you are still sending updates in RIPE-181 format, we advise you to switch to RPSL before 15th October. Please send your objects in RPSL format to <auto-dbm(a)ripe.net>. You may use ripe2rpsl utility to convert your RIPE-181 objects to RPSL format before sending them to the RIPE Database. The utility can be found at ftp://ftp.ripe.net/tools/ripe2rpsl-3.0.2.tar.gz. As part of this final step we will also make some cleanup of the ftp.ripe.net site. - The top directory for the RIPE Database software and flat object files is ftp://ftp.ripe.net/ripe/dbase. - "Short" versions of flat object files [*] will not be supported. [*]Version of a flat object file where attribute names are abbreviated to 2 letter code starting with '*'. The name of the object file also contains the object type in abbreviated form. For example ripe.db.in is the "short" version of the flat file for inetnum objects, while ripe.db.inetnum is the "long " version that is RPSL compliant. For more information please visit http://www.ripe.net/rpsl If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 1

RE: more specific routes in today reality
by Boyan Krosnov 09 Oct '01

09 Oct '01

Hi, There are other solutions for multihoming with NAT but I think we are again hitting that NAT against no NAT issue. I think that I should say it now to avoid further flamewars. NAT is not always a possible solution. It may be good to use it in some cases but it is not in others. Those other cases are the ones that this discussion is about. Or at least I think so :) CCNP Boyan Krosnov Network Administrator Lirex Net phone: +359-2-91815 > -----Original Message----- > From: Mirta Matic [mailto:mirta.matic@hinet.hr] > Sent: Tuesday, October 09, 2001 4:55 PM > To: Sascha E. Pollok > Cc: Gert Doering; Vladimir A. Jakovenko; lir-wg(a)ripe.net; > routing-wg(a)ripe.net > Subject: Re: more specific routes in today reality > > > Hello, > > have you ever heard for RADWARE solution for that problem? > Some RADWARE box can check distance to destination via both > ISP's and makes > decision from what IP address range have to get address for > NAT (of course, > customer have to have two ranges of addresses). If connection > via one ISP > failed, all traffic will be rerouted via another using IP > address from IP > address range of that ISP. > > Mirta Matic > mirta.matic(a)hinet.hr > > tel: +385 1 4914 207 > fax: +385 1 4914 222

1 0

The Cidr Report
by CIDR Report 06 Oct '01

06 Oct '01

This is an auto-generated mail on Fri Oct 5 23:00:01 PDT 2001 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 amont 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 05Oct01 0) General Status Table History ------------- Date Prefixes 280901 104483 290901 104988 300901 104943 011001 105036 021001 105301 031001 104637 041001 104254 051001 104449 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: 11739 Number of ASes announcing only one prefix: 6989 (3974 cidr, 3015 classful) Largest number of cidr routes: 844 announced by AS701 Largest number of classful routes: 1394 announced by AS701 1) Gains by aggregating at the origin AS level --- 05Oct01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1258 958 300 23.8% Telstra Pty Ltd AS4151 302 170 132 43.7% USDA AS16473 201 76 125 62.2% Bell South AS577 307 187 120 39.1% Bell Advanced Communications Inc. AS13999 131 20 111 84.7% Mega Cable S.A. de C.V. AS4293 375 267 108 28.8% Cable & Wireless USA AS2048 215 116 99 46.0% State of Louisiana AS4755 208 131 77 37.0% Videsh Sanchar Nigam Ltd. Autonom AS1239 481 410 71 14.8% Sprint AS3464 163 95 68 41.7% Alabama SuperComputer Network AS12302 98 32 66 67.3% MobiFon S.A. AS11686 192 126 66 34.4% Education Networks of America AS6471 128 63 65 50.8% ENTEL CHILE S.A. AS4200 137 72 65 47.4% Apex Global Information Services, AS17557 124 65 59 47.6% Pakistan Telecom AS16758 63 6 57 90.5% IKON Office Solutions AS209 309 254 55 17.8% Qwest AS306 60 6 54 90.0% National Guard Bureau AS3908 291 238 53 18.2% Supernet, Inc. AS400 137 85 52 38.0% Headquarters Standard Systems Cen AS226 145 93 52 35.9% Los Nettos AS17561 113 62 51 45.1% Internet service provision to Wes AS1 537 486 51 9.5% BBN Planet AS637 106 58 48 45.3% Department of Navy AS4323 246 198 48 19.5% Time Warner Communications, Inc. AS1913 152 104 48 31.6% Defense Logistics Agency AS10620 68 21 47 69.1% TVCABLE BOGOTA AS15290 246 200 46 18.7% AT&T Canada IES AS376 120 76 44 36.7% Reseau Interordinateurs Scientiqu AS5416 51 9 42 82.4% BATELCO-BH 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

1 0

Weekly Routing Table Report
by Routing Analysis 04 Oct '01

04 Oct '01

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats(a)lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Routing Table Report 05 Oct, 2001 Analysis Summary ---------------- BGP routing table entries examined: 109173 Origin ASes present in the Internet Routing Table: 11828 Origin ASes announcing only one prefix: 4342 Transit ASes present in the Internet Routing Table: 1528 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 17 Illegal AS announcements present in the Routing Table: 70 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 14 Number of addresses announced to Internet: 1258644271 Equivalent to 75 /8s, 5 /16s and 99 /24s Percentage of available address space announced: 34.0 Percentage of allocated address space announced: 65.4 Percentage of available address space allocated: 51.9 Total number of prefixes smaller than registry allocations: 73973 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 16423 Prefixes being announced from the APNIC address blocks: 14867 APNIC Region origin ASes present in the Internet Routing Table: 1381 APNIC Region origin ASes announcing only one prefix: 459 APNIC Region transit ASes present in the Internet Routing Table: 234 Average APNIC Region AS path length visible: 5.1 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 81201752 Equivalent to 4 /8s, 215 /16s and 10 /24s Percentage of available APNIC address space announced: 79.8 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7, 210/7 and 218/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 75127 Prefixes being announced from the ARIN address blocks: 53630 ARIN Region origin ASes present in the Internet Routing Table: 7110 ARIN Region origin ASes announcing only one prefix: 2114 ARIN Region transit ASes present in the Internet Routing Table: 710 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 17 Number of ARIN addresses announced to Internet: 232748348 Equivalent to 13 /8s, 223 /16s and 117 /24s Percentage of available ARIN address space announced: 86.7 ARIN AS Blocks 1 - 1876, 1902 - 2042, 2044 - 2046, 2048 - 2106 2138 - 2584, 2615 - 2772, 2823 - 2829, 2880 - 3153 3354 - 4607, 4865 - 5119, 5632 - 6655, 6912 - 7466 7723 - 8191, 10240 - 12287, 13312 - 15359 16384 - 17407, 18432 - 20479, 21504 - 22527 ARIN Address Blocks 24/8, 63/8, 64/6, 68/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 17617 Prefixes being announced from the RIPE address blocks: 14020 RIPE Region origin ASes present in the Internet Routing Table: 3345 RIPE Region origin ASes announcing only one prefix: 1769 RIPE Region transit ASes present in the Internet Routing Table: 586 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 15 Number of RIPE addresses announced to Internet: 108070239 Equivalent to 6 /8s, 113 /16s and 5 /24s Percentage of available RIPE address space announced: 71.6 RIPE AS Blocks 1877 - 1901, 2043, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 20480 - 21503 RIPE Address Blocks 62/8, 80/7, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv Description 1221 1616 1313 Telstra Pty Ltd 2764 412 374 connect.com.au pty ltd 703 398 372 UUNET Technologies, Inc. 2907 369 1847 SINET Japan 4755 292 160 Videsh Sanchar Nigam Ltd. Aut 7474 246 274 Optus Communications Pty Ltd 4134 235 1805 Data Communications Bureau 4740 186 23 OzEmail ISP 4766 182 1466 Korea Internet Exchange for " 7539 180 186 TANet2, sponsored by NSC, TAI 9443 158 53 Primus Telecommunications 4786 127 17 NetConnect Communications Pty 7545 125 23 TPG Internet Pty Ltd 9768 123 378 Korea Telecom 4763 122 69 Telstra New Zealand 17557 122 8 Pakistan Telecom 2521 119 170 PSINet Japan 9583 118 60 Satyam Infoway Ltd., 4713 117 885 NTT Communications Corporatio 17561 116 167 Internet service provision to RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv Description 702 890 1988 UUNET Technologies, Inc. 3301 440 937 TeliaNet Sweden 1257 273 512 SWIPnet Swedish IP Network 680 242 2340 DFN-IP service G-WiN 3215 232 515 France Telecom / &Equant 5515 193 687 Sonera Finland Autonomous Sys 3320 188 1942 Deutsche Telekom AG 786 185 1890 The JANET IP Service 8708 155 16 Romania Data Systems S.A. 15870 144 10 Global Center Frankfurt 5400 141 65 Concert European Core Network 719 137 288 LANLINK autonomous system 1270 137 717 UUNET Germany 3303 129 560 Swisscom Ltd 2856 127 776 BTnet UK Regional network 5549 127 67 Nextra Deutschland GmbH + Co. 15878 123 9 Global Center Paris 517 113 253 KPNQwest Germany GmbH 1267 103 1988 Infostrada S.p.A. 12302 101 6 MobiFon S.A. ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv Description 701 2256 9112 UUNET Technologies, Inc. 3908 1143 1545 Supernet, Inc. 7018 1065 7232 AT&T 1 877 8623 BBN Planet 7046 810 1005 UUNET Technologies, Inc. 1239 757 3373 Sprint 3967 616 470 Exodus Communication 209 562 2235 Qwest 690 514 80 Merit Network 2914 496 2287 Verio, Inc. 4293 457 112 Cable & Wireless USA 3561 410 2373 Cable & Wireless USA 705 399 82 UUNET Technologies, Inc. 721 394 4407 DLA Systems Automation Center 2548 389 1007 Business Internet, Inc. 3549 372 835 Global Crossing 2149 361 263 Performance Systems, Inc. 4323 352 355 Time Warner Communications, I 577 351 620 Bell Advanced Communications 3741 347 773 The Internet Solution Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv Description 701 2256 9112 UUNET Technologies, Inc. 1221 1616 1313 Telstra Pty Ltd 3908 1143 1545 Supernet, Inc. 7018 1065 7232 AT&T 702 890 1988 UUNET Technologies, Inc. 1 877 8623 BBN Planet 7046 810 1005 UUNET Technologies, Inc. 1239 757 3373 Sprint 3967 616 470 Exodus Communication 209 562 2235 Qwest 690 514 80 Merit Network 2914 496 2287 Verio, Inc. 4293 457 112 Cable & Wireless USA 3301 440 937 TeliaNet Sweden 2764 412 374 connect.com.au pty ltd 3561 410 2373 Cable & Wireless USA 705 399 82 UUNET Technologies, Inc. 703 398 372 UUNET Technologies, Inc. 721 394 4407 DLA Systems Automation Center 2548 389 1007 Business Internet, Inc. List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 22153 UNALLOCATED 63.167.108.0/24 1239 Sprint 6971 UNALLOCATED 64.42.0.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 64.42.0.0/17 2516 Kokusai Denshin Denw 6971 UNALLOCATED 64.42.16.0/20 2914 Verio, Inc. 6971 UNALLOCATED 64.42.32.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.40.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.48.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.56.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.60.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.64.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.72.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.80.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.104.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.108.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.112.0/20 2914 Verio, Inc. 6971 UNALLOCATED 64.87.64.0/19 2516 Kokusai Denshin Denw 22153 UNALLOCATED 65.161.192.0/24 1239 Sprint 22153 UNALLOCATED 65.165.127.0/24 1239 Sprint 65000 PRIVATE 138.163.4.0/24 665 Department of Navy 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 64512 PRIVATE 161.132.234.0/24 8143 Publicom Corp. 22153 UNALLOCATED 168.215.234.0/23 22026 Time Warner Telecom 22153 UNALLOCATED 168.215.236.0/23 22026 Time Warner Telecom 6971 UNALLOCATED 192.103.229.0/24 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.230.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.232.0/22 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.236.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.237.0/24 2516 Kokusai Denshin Denw 1877 UNALLOCATED 192.108.201.0/24 1880 Stupi, house man's p 5555 UNALLOCATED 192.156.8.0/24 721 DLA Systems Automati 5555 UNALLOCATED 192.156.41.0/24 721 DLA Systems Automati 65460 PRIVATE 192.231.11.0/24 7018 AT&T 22290 UNALLOCATED 198.140.161.0/24 2914 Verio, Inc. 5555 UNALLOCATED 199.10.190.0/24 721 DLA Systems Automati 22290 UNALLOCATED 199.217.152.0/24 2914 Verio, Inc. 22290 UNALLOCATED 199.217.187.0/24 2914 Verio, Inc. 6971 UNALLOCATED 199.249.223.0/24 2516 Kokusai Denshin Denw 22290 UNALLOCATED 205.159.194.0/24 2914 Verio, Inc. 6971 UNALLOCATED 206.58.248.0/22 2516 Kokusai Denshin Denw 6971 UNALLOCATED 206.58.248.0/21 2516 Kokusai Denshin Denw 6971 UNALLOCATED 206.58.252.0/23 2914 Verio, Inc. 6971 UNALLOCATED 206.58.254.0/23 2914 Verio, Inc. 64803 PRIVATE 206.81.213.0/24 6225 US West Communicatio 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, 22290 UNALLOCATED 207.150.139.0/24 2914 Verio, Inc. 22075 UNALLOCATED 209.39.134.0/24 2914 Verio, Inc. 65515 PRIVATE 212.110.142.0/24 5593 CRIS-AS 6971 UNALLOCATED 216.105.192.0/20 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.121.224.0/19 2516 Kokusai Denshin Denw 64803 PRIVATE 216.160.71.0/24 6225 US West Communicatio 6971 UNALLOCATED 216.174.192.0/21 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.192.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.200.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.200.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.174.202.0/24 2914 Verio, Inc. 6971 UNALLOCATED 216.174.208.0/20 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.232.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.174.240.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.128.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.210.128.0/17 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.210.140.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.144.0/20 2914 Verio, Inc. 6971 UNALLOCATED 216.210.160.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.176.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.184.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.200.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.216.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.224.0/20 2914 Verio, Inc. 6971 UNALLOCATED 216.210.240.0/20 2914 Verio, Inc. 6971 UNALLOCATED 216.229.96.0/20 2516 Kokusai Denshin Denw Advertised Unregistered Addresses --------------------------------- Network Origin AS Description 128.65.0.0/16 3463 ACES Research Inc 132.0.0.0/10 568 DISO-UNRRA 134.137.0.0/16 400 Headquarters Standard Systems 135.0.0.0/13 10455 Lucent Technologies 137.0.0.0/13 568 DISO-UNRRA 138.94.0.0/16 1 BBN Planet 144.7.0.0/16 701 UUNET Technologies, Inc. 153.34.0.0/15 701 UUNET Technologies, Inc. 153.36.0.0/14 701 UUNET Technologies, Inc. 154.150.0.0/16 6494 IDCI 158.0.0.0/13 568 DISO-UNRRA 164.233.0.0/16 6020 DISA NETWORK SERVICES 164.235.0.0/16 6025 US DOD NIC Unregistered 201.115.100.0/24 7018 AT&T Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:5 /10:8 /11:12 /12:33 /13:87 /14:226 /15:387 /16:7114 /17:1269 /18:2372 /19:6986 /20:5899 /21:4800 /22:7078 /23:9078 /24:62286 /25:306 /26:326 /27:251 /28:251 /29:150 /30:173 /31:1 /32:57 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 1221 1469 1616 Telstra Pty Ltd 701 1434 2256 UUNET Technologies, Inc. 3908 868 1143 Supernet, Inc. 7046 634 810 UUNET Technologies, Inc. 702 603 890 UUNET Technologies, Inc. 7018 561 1065 AT&T 690 511 514 Merit Network 4293 443 457 Cable & Wireless USA 3967 436 616 Exodus Communication 1 422 877 BBN Planet 1239 421 757 Sprint 209 400 562 Qwest 2764 366 412 connect.com.au pty ltd 705 348 399 UUNET Technologies, Inc. 703 327 398 UUNET Technologies, Inc. 5106 319 338 Ameritech Advanced Data Servi 4151 300 342 USDA 11371 299 310 Rhythms NetConnections 4323 294 352 Time Warner Communications, I 2548 280 389 Business Internet, Inc. Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:6 9:1 12:417 13:10 15:1 17:5 20:1 24:800 25:1 26:1 32:74 38:14 43:4 44:2 53:2 57:15 61:100 62:145 63:1936 64:1306 65:810 66:468 67:32 80:65 128:52 129:111 130:19 131:44 132:39 133:2 134:127 135:12 136:92 137:92 138:153 139:49 140:176 141:195 142:57 143:39 144:152 145:30 146:146 147:129 148:83 149:87 150:38 151:179 152:396 153:48 154:18 155:83 156:96 157:111 158:74 159:69 160:48 161:61 162:71 163:146 164:101 165:98 166:195 167:154 168:129 169:38 170:270 171:2 192:5615 193:1967 194:2060 195:848 196:452 198:4114 199:3892 200:2374 201:1 202:2838 203:4577 204:3386 205:2214 206:2920 207:2623 208:3126 209:3164 210:572 211:137 212:864 213:518 214:9 215:14 216:3084 217:388 218:2 End of report

1 0

Re: Re-homing of RAToolSet to RIPE NCC
by Joao Luis Silva Damas 04 Oct '01

04 Oct '01

The way Cengiz explained USC's copyright to me it was supposed to mean: You can not sell this stuff (the software) without giving us a part of the profit. It was not supposed to mean: if you are a commercial company, you can't use it. After the RA project was about providing infrastructure to support an Internet that had become commercial, right? In any case, no one, other than USC, can remove their copyright from the code but if the real interpretation of the copyright statement happens to be the more restrictive one, then the RIPE NCC would certainly have a problem with this code, because we *HAVE* to make the software we develop available for use by the community. Joao At 05:13 -0700 4/10/01, Bill Manning wrote: >% Like I said, most (techie) people don't give a hoot, but legal >% departments at largish outfits can seriously halt Progress(tm). Although >% RIPE and the RIPE NCC are non-profit organisations, most of the members >% are most definitely out to make a (euro-)buck. It's only proper that if >% these tools are to be hosted/provided/maintained by the RIPE NCC, that >% the restrictive license is removed. Replacing it with a RIPE/RIPE NCC >% copyright may make non-RIPE members nervous, so I still think a GNU-like >% license is the safest and fairest option. > > > I spect that the USC tag still claims that it needs to stay > w/ the code so RIPE would need to do a "clean-room" > reimplementation to expunge the USC tag. > > Of course RIPE could also cut a deal w/ USC on broad > commercial use of the tools. That has often proved to > be the cheapest/easiest course. >% >% Cheers, >% Steven >% > > >-- >--bill --

3 2

Re-homing of RAToolSet to RIPE NCC
by Andrei Robachevsky 04 Oct '01

04 Oct '01

Dear Colleagues, [sorry for duplicate messages] Following Cengiz Alaettinoglu's message on this subject on the ratoolset(a)isi.edu mailing list (please find the original message attached below) it is our pleasure to announce that RAToolSet project has moved from ISI to the RIPE NCC. Starting from now the RIPE NCC will take on support and development of these tools. As a part of this move, RAToolSet will be called IRRToolSet. A new web page http://www.ripe.net/ripencc/pub-services/db/irrtoolset/index.html and a mailing list irrtoolset(a)ripe.net have been established. We have subscribed all of the members of ratoolset(a)isi.edu to this mailing list. The original list will be phased out, but will forward any email to the new address. If you would like to subscribe to the IRRToolSet mailing list, put the line "subscribe irrtoolset" in the body of the message to add your address to the list, and send it to majordomo(a)ripe.net. We rely on your feedback and hope to provide the level of support you received from Cengiz and the ISI team. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

6 9

RE: Re-homing of RAToolSet to RIPE NCC
by Joao Luis Silva Damas 04 Oct '01

04 Oct '01

At 05:56 -0400 4/10/01, Ray Plzak wrote: > > to divide and conquer them :-) RIPE NCC seem to have enough >> mechanisms in place to get feedback from their community >> > >Precisely, "their community" > >> >> see this software as having a global constituency rather than just a >> RIPE one then I'm going to be a happy camper. > >Therefore the need to reach out to the global constituency. I agree with the objective, just not with the proposed method. Joao >Ray --

1 0

nearly too late: minutes of Routing WG RIPE 39(!)
by SchmitzJo＠aol.com 02 Oct '01

02 Oct '01

Dear colleagues, please find below the minutes of our last session during the previous RIPE meeting. Delay in delivering is solely up to myself - I had receive more than enough input from the two scribes Bill Woodcock and Shane Kerr already shortly after the meeting - thanks a lot again to both! Thanks Joachim ----- R I P E 3 9 B O L O G N A Routing Working Group Session 2-May-2001 Draft Minutes Chair: Joachim Schmitz (JS395-RIPE) Scribe: Bill Woodcock, Shane Kerr -- thank you!!! Participants: 111 Prior to the Routing WG two tutorials were given which have a relationship to Routing Monday, 30-Apr, 9:00: Clarence Filsfils, John Evans (Cisco) Full day tutorial on MPLS Tuesday, 1-May, 9:00: Cengiz Allaettinoglu (Packetdesign) Half day tutorial on the RAToolSet The Routing WG session itself was held on Wednesday, 2-May, 14:00. A. Preliminaries (Joachim Schmitz) The chair man welcomed the participants, and distributed the participants' list to sign in. Bill Woodcock volunteered to take the minutes, Shane Kerr also provided them in parallel. Regarding the WG agenda Bernard Tuy asked about the status of the the IPv6 routing registry and whether some presentation would be given. Joachim explained that no action had been taken yet, because the first step is development of RPSLv6. However, this is part of the NCC activity plan. Joachim suggested to initiate a corresponding task force to assist the NCC in that work -> action 39.R1 on Joachim: initiate RPSLv6 task force Following that the WG agenda was accepted without changes. The minutes of the previous meeting at RIPE38 were accepted by the participants, and are thus declared final. Actions from earlier meetings 36.R1 on RIPE NCC RADB coordination for RPSL transition This has been done as part of the RPSL transition at RIPE *close* 37.R1 on C.Panigl, P.Smith, D.Karrenberg, J.Schmitz Updates to RIPE-210 *ongoing* 37.R2 on RIS team, Henk Uijterwall Route flap analysis from RIS data *ongoing* 38.R1 on J.Schmitz, W.Woeber Organize RaToolSet tutorial at RIPE 39 The tutorial has been held this meeting as part of the RPSL transition *close* 38.R2 on J.Schmitz, W.Woeber Collect final community input on database migration dates This had happened according to schedule and recognized for the transition *close* B. Cengiz Allaettinoglu: Observations on IGP Convergence http://www.packetdesign.com/Docs/draft-alaettinoglu-ISIS-convergence-00.ps Towards sub-second IGP convergence: Today, we are typically in the area of tens of seconds or up to several minutes which comes from the process of 1. detect (link up/down or peer reachability) 2. distribute info (flooding) with LSP packets (link state packets) 3. determine new path: shortest path first (SPF) computation Experiments were conducted to analyze this in more detail. Looking closer at the individual steps: 1. Detect Hello packets are sent at a fixed interval of 10secs, with a timeout of 30secs (default value) where the timeout gives a lower bound for cenvergence. In priniple, the hello interval can be reduced. Bandwidth consumption is not necessarily an issue today anymore, and analysis shows that up to 10% of traffic may consist of hello packets if they are treated preferred to data packets. Essentially, allowing sub-second intervals leads to sub-second detection. However, this is hard for "run-to-complete" router OSs which could be mended by employing real time OSs. Still, the hello interval is limited due to physical constraints (bandwidth, error spectrum, propagation delay). Moreover, there are stability issues, if routing follows rapid link transients which would call for some damping mechanism and treating "bad news" differently from "good news". 2. LSP propagation In theory, propagation should not matter (essentially at the speed of light, plus store&forward time per hop) but practice shows difference. In particular, the SPF computation is done before forwarding LSPs, and normally a delay of 5secs is usually set by default, adding to propagation delays. If set to zero, still the SPF computation is done before. 3. SPF calculation Each node must calculate the new SPF topology. For a given number of n nodes and a change in topology the time was measured which is required to calculate SPF. Depending on router vendor, the effort grows by n^2 or n*log(n). For larger network, even on high end routers, the calculation then lasts for seconds. However, new dynamic algorithms exist which scale like log(n) which for large networks improves performance easily 10k times. This is now newly implemented in vendor's codes. Topologies up to 90k edges were tested and no instability was found. There were a few questions on that presentation Q: What happens if an incremental update is lost A: LSPs are already split-horizon Q: What kind of topology had been simulated A: A flat one Q: What if nodes fail which drastically change the shape of the graph A: those have been included, and results are an average of all different kinds of failures Q: Has this been shown and discussed anywhere else A: Yes, at IETF working groups, where the only objection against rapid hello packets was on run-to-completion architectures Q: Topologies can be envisioned where this does not work A: In theory yes, but for practice these would be pathological cases C. Philip Smith: Revision to RIPE-210 (Route Flap Damping) - update Philip first dealt with the question why RIPE-210 should be revised. This is due to several drawbacks: . parameters for /24 damping are virtually unfeasible . "golden networks" are changing . remaining open issues are long solved . restructuring and updating is necessary and discussed these items Parameters for /24 damping specified would never lead to damping as shown by simple discussion of the values. Instead the correct values bgp dampening 30 820 3000 60 with a maximum possible penalty of 3280 leads to suppression of prefixes and the original design intentions are achieved. The "golden networks" according to definition should not be dampened, however the list given in RIPE-210 was outdated, and contrary to the original intention to only list root nameservers, consisted partly of those (incomplete) and some gTLD servers. In the revision "golden networks" are defined to be those which an operator does not want to dampen for whatever reason. It is suggested to move a template list into an appendix, also to reduce the effect that the list is just included unchanged in router configurations by cut&paste. The question is considered solved that updates from a router arrive at a peer at different times through different paths which could be understood as multiple flaps. This has been included in OS codes now. In addition, route refresh is now RFC2918, a proposed standard. Regarding restructuring the following items were changed . moved data to appendices . changed document from Cisco only to general doc (allowing other router vendor implementations), so far received exmaples for Juniper's JunOS Philip also asks for others like gated, Foundry, Redback, Extreme... . show what is not recommended . appendix of study of flap damping operation intended to help for port configs The new draft has been posted to several mailing lists at NANOG, APOPS, AfNOG, and received some input which will be included in a refined version. Joachim thanked Philip for his contribution to the document and the work he put into it. Daniel suggested that the golden networks are excluded from the document itself for the simple reason that they are likely to change more rapidly than the document itself. To have a reference, he suggests to put a reference in which points to a web page on the RIPE NCC web server. This was accepted by the audience. -> action 39.R2 on Daniel Karrenberg: Provide "Golden Network" web page D. Henk Uijterwaal: RIS - Status and Plans There are a few changes to the team, with two people leaving and two new ones joining. In addition, they are looking for a student intern for the 2001-2002 term. Expected total FTE for 2001 is 2.1 FTE with 0.3...0.7 student. Currently, route collectors exist at - RIPE-NCC - LINX and new ones to come up or in the process of being deployed - SFINX - AMS-IX - CIXP If you would want to provide feeds to the route collectors, write e-mail to ris-peerings(a)ripe.net Beyond that additional route collectors are suggested for - JP/Asian region - US - DE, SE in discussion However, before those are considered more closely, investigate what we can do with existing RRCs first, and determine added value of installing more RRCs. The data of all of these can be handled. Already we have results and displays which for the most part come from Thomas Franchetti's thesis: fully automated setup to produce daily updated plots of the RIS data. This is fully documented and currently generates 4 different plots; current plots are - BGP updates/minute - Prefix distribution - BGP distribution of types (announcements, withdrawals) - BGP unique announcements More plots and stats can be easily added, and will be added. Beyond these generic plots, those parties with a peering session can get a personalized view. Before putting this to true production, two more tasks must be done - security review of cgi-code - apply NCC layout Plans for the next months include - transitioning with new people - RIS reports will go online - move to regular service From the audience the question was posed about data volume. This is 14 MB per peer per day, and 4 GB raw data per month. Due to a scaling problem with the database, active data in the database is currently limited to 3 months worth of data. Older data is kept gzipped. [break] After the break, a joint session with the Database WG was held, to wrap up on the transition to the RPSL database. E. Andrei Robachevsky: New Version of the RIPE Database http://www.ripe.net/rpsl The database has migrated and is now running RPSL. There is no other production database anymore, in particular no test or RIPE-181 databases. About one week after the migration (happened on 23-April), already 56k objects have been processed. The query rate with an average of 8.7 queries/sec is the same, and so far 17M objects have been downloaded. Currently, there are 6 active mirrors (there had been 12 before). The new RIPE database software code had been completely rewritten to improve performance and managability. It now supports RPSL, extended syntax and objects (RFC2622), RPSS (RFC2725), and the RAToolSet (v.4.7.0, ftp:/ftp.isi.edu/ra/RAToolSet) There are plans to move development and maintenance of the RAToolSet over to the RIPE NCC. In addition, a new whois client has been developed (ftp://ftp.ripe.net/ripe/dbase/reimp/whoisRIP-1.0.tar.gz) Andrei then gave an overview of features of the new database software with regard to RPSL, in particular - modified objects: mntnr, route, aut-num, inetnum, as-set (was as-macro), route-set (was community), inet-rtr. Non-affected objects: person, role, domain, limerick. - new objects: as-block, rtr-set, peering-set, filter-set - new attributes: member-of, mbrs-by-ref, mnt-routes, referral-by, auth-override - new query flags: -l <ip-range>, -x <ip-range>, -K, -d, -q sources, -q version - new version of the mirroring protocol The team involved in development and transition of the new database software is Daniele Arena Marek Bukowy Joao Damas Engin Gunduz Roman Karpiuk Shane Kerr Ambrose Magee Chris Ottrey Filippo Portera Andrei Robachevsky reachable at dbrip(a)ripe.net. Many thanks go to this team and anybody who has helped to make it happen! This was very much supported by the audience! Prior to the transition (on the test database) and right after, a few issues had been discovered and resolved - PGP updates failed at <auto-rpsl(a)ripe.net> o solved 24 April o use ONLY RPSL path for PGP signed updates - Conversion problems of updates at <auto-dbm(a)ripe.net> o incorrect or misleading replies o solved 26 April o please use RPSL path <auto-rpsl(a)ripe.net> - Acknowledgement problems o sometimes were not sent or were misleading o solved 26 April - Acknowledgement problems(2) o authentication does not give proper responses - Some filaed updates were not processed o might have happened 23-27 April o please re-send them if you didn't receive a reply from DB and the objects are not updated - Indentation difference o will be solved ASAP - DB accepts mirror's requests with protocol #1 o "compatability" mode o deadline: [15.10 | until sorted out with RADB/iRRd] - Routing Policy System Security (RFC2725) o authorisation rules for route creation need mntner authorization for inetnum, (parent) route, aut-num, a route itself problem with MAIL-FROM, because can only have 1 mail-from! problem with CRYPT-PW because you have to share password o need to duplicate objects in the RIPE DB origin or address from non-RIPE space currently have inetnum with NONE auth for mnt-routes as-blocks for RIPE space with NONE auth for mnt-lower o possible better solution perform checks on mirrored sources - which sources contain authoritative data for an IP/ASN space? implement some of RFC2769 (rps-dist) features - integrity attribute? requires good coordination and understanding between RIR's, IRR's To finalize the transition, the mail addresses to send updates to will be changed over time as announced: - 1st (current) <auto-dbm(a)ripe.net> -> <auto-181(a)ripe.net> 23rd April - 2nd (next) <auto-dbm(a)ripe.net> -> <auto-rpsl(a)ripe.net> 14th May - 3rd no <auto-181(a)ripe.net> There was a set of questions on the transition and the presentation Q: the keyword "password" must be written all in lowercase in contrast to RPSL definition? A: this has been fixed Q: after migration import/export attributes often extended over several lines, while one liners with updates were correctly returned which caused problems with scripts processing data A: line continuation is a feature of RPSL and described in the standard; accordingly scripts must be capable of handling them; for the auto conversion during migration it was not the rule to break single lines into multiples, but could also not be excluded Q: when querying an encompassing AS block you get "?" as ARIN number, and ARIN1-RIPE with a wrong address A: this will be fixed Q: a provider asked that they have C&W as upstream which reads their AS-macros and was wondering whether C&W was ready to read AS-sets A: C&W participated explicitely in the transition process, and a representative of C&W confirmed that they have already made the conversion G. Rob Evans: Operational Experience with RtConfig <rhe(a)noc.ten-155.net> <rhe(a)nosc.ja.net> Rob introduced himself as working for the University of London Computer Centre, running JANET (UK education and research network) and TEN-155 (pan-European counterpart). While JANET applies fairly loose filtering, TEN-155 generates filters based on policies in IRR (RIPE). Therefore, all networks routing on TEN-155 must have a corresponding entry in the RIPE Database. They are using RtConfig, a program from the RAToolSet to generate parts of their router configurations, because people make mistakes. Using RtConfig limits their impact. Rob then showed several examples of common user mistakes like - redistributing IGP routes into BGP - unintentionally announcing full routing tables - ordering a filter wrongly - typing errors in filters and continued on how they are employing RtConfig - to generate filters - interprets policies - generates BGP configs - in formats for all our favorite routers accompanied by an example on how to generate filter lists. Gotchas To use RtConfig a few things should be considered - adds latency between a customer being allocated addresses and the route being accepted which can be reduced to a minium if updates are run regularly - filters can be very large (by route), which can be circumvented by just filter on AS path (which unfortunately does not protect against redistribution of IGP) - which db to query? for us in the European, RIPE will usually do Rob also thinks that they have room for improvements, because so far they do not use use many features of RPSL and RtConfig - peering sessions are still configured manually - many options that can be expressed in RPSL are still configured manually (eg route preferences) All of this can be done by a combination of RPSL database entries and RtConfig. F. Cengiz Allaettinoglu: Overview of the RAToolSet This was essentially a small recap from the RAToolSet tutorial from the beginning of the RIPE meeting covering RtConfig router configuration tool peval policy calculator/evaluator roe route object editor prtraceroute traceroute with policy no assumptions - only concerns YOUR part of IRRd CIDRAdvisor safe aggregations (for your routes) prpath paths to different location these two tools assumed that many people would register in IRR this assumption has not been true aoe aut-num editor (no longer available, not RPSL capable) Pointers to this are o http://www.isi.edu/ra/rps/training o http:/www.isis.edu/ra/RAToolSet Mailing lists o <rps(a)isi.edu> o <ratoolset(a)isi.edu> Cengiz Alaettinoglu <cengiz(a)packetdesign.com> Just prior to the RIPE40 meeting, it was announced that maintenance and development of the RAToolSet has moved to the RIPE NCC. As a part of this move, RAToolSet will be called IRRToolSet. A new web page http://www.ripe.net/ripencc/pub-services/db/irrtoolset/index.html and a mailing list irrtoolset(a)ripe.net have been established. Y. Input from other WGs Combining the 2nd slot with the Database WG covered the transition of the RIPE database to RPSL. In addition, reference was made to the IPv6 RR which needs to be taken up for further development. Z. AOB none Summary of Open Action Points from the Routing WG 37.R1 on C.Panigl, P.Smith, D.Karrenberg, J.Schmitz Provide updates to RIPE-210 - ongoing - 37.R2 on RIS team, Henk Uijterwaal Implement route flap analysis from RIS data - ongoing - 39.R1 on J.Schmitz, D.Kessens Initiate IPv6 IRR taskforce - new - 39.R2 on D.Karrenberg Provide "Golden Network" web page - new - Bill Woodcock, Shane Kerr, May 2001 Joachim Schmitz, September 2001 -----

1 0