- routing-wg - mailman.ripe.net

The Cidr Report
by Tony Bates 18 Feb '01

18 Feb '01

This is an auto-generated mail on Fri Feb 16 23:00:00 PST 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. 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 xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 16Feb01 0) General Status Table History ------------- Date Prefixes 050201 96681 060201 96726 070201 96978 080201 97041 090201 97137 100201 96880 110201 96509 120201 96907 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: 6307 Number of ASes announcing only one prefix: 2489 (0 cidr, 2489 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1648 announced by AS701 1) Gains by aggregating at the origin AS level --- 16Feb01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1623 1207 416 25.6% Telstra Pty Ltd AS701 1648 1453 195 11.8% UUNET Technologies, Inc. AS271 283 130 153 54.1% University of British Columbia AS8006 146 13 133 91.1% Systems & Software Consortium, In AS7545 196 71 125 63.8% ASNBLK-APNIC-AS-2-BLOCK AS9269 168 46 122 72.6% ASNBLK-APNIC-AS-3-BLOCK AS6429 218 110 108 49.5% RdC Internet AS6595 163 62 101 62.0% DoD Education Activity Network As AS8013 435 338 97 22.3% PSINet Ltd. Canada AS13999 107 10 97 90.7% Mega Cable S.A. de C.V. AS4293 375 282 93 24.8% Cable & Wireless USA AS7496 104 23 81 77.9% ASNBLK-APNIC-AS-2-BLOCK AS4151 251 170 81 32.3% USDA AS705 314 235 79 25.2% UUNET Technologies, Inc. AS4755 206 134 72 35.0% ASN-APNIC-AS-BLOCK-ASNBLOCK AS1942 137 65 72 52.6% FR-CICG-GRENOBLE AS7046 325 255 70 21.5% UUNET Technologies, Inc. AS7018 611 541 70 11.5% AT&T AS577 236 167 69 29.2% Bell Advanced Communications Inc. AS174 500 432 68 13.6% PSINet Inc. AS1727 161 93 68 42.2% Commander Naval Surface force US AS9498 88 21 67 76.1% BHARTI BT INTERNET LTD. AS724 219 152 67 30.6% DLA Systems Automation Center AS5106 101 37 64 63.4% Ameritech Advanced Data Services, AS3464 153 92 61 39.9% Alabama SuperComputer Network AS226 155 95 60 38.7% Los Nettos AS7657 184 126 58 31.5% ASNBLK-APNIC-AS-2-BLOCK AS3749 115 57 58 50.4% Tennessee Board of Regents AS16758 63 6 57 90.5% IKON Office Solutions AS6413 67 11 56 83.6% Southern Online Systems, Inc. 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

RIPE: last call for comments RPSL transition
by SchmitzJo＠aol.com 17 Feb '01

17 Feb '01

Hello all, as you are aware, we are preparing the migration of the RIPE database software to support and deploy the new RPSL format. The required steps have been discussed in depth on various occassions (for references, see end of mail). We are now preparing the most important step, really transitioning from old RIPE-181 to new RPSL format: proposed transition date is 23-Apr-2001. This step, once taken, will not be reversed. The majority of the user community takes a neutral role, while some want an earlier, and a few a later date for migration. During the joint session of Routing and DB WG at RIPE38, the chairmen of both WGs were tasked to file a last call for comments on that date, in particular whether there are serious, unresolvable technical or operational problems which would benefit from a slightly longer warning period. According to consensus at the session: If you are convinced that the transition date as proposed would lead to significant operational problems, please explain and justify why within the next 2 weeks: deadline for transition comments: 1-Mar-2001 Only well founded reasoning (including an educated guess about the time and resources required to resolve the issue) shall be accepted by the community in order to consider postponing the transition. With the discussion about the migration going on for quite some time, and information available from various places, we do not expect a delay, but we would want to give everybody a last opportunity to comment. To summarize the dates, we are looking at: o 23-Apr-2001: switching to the RPSL database - All objects are automatically converted to RPSL format - Queries return RPSL only - Mirroring follows new format and rules at whois.ripe.net, port 4444 - RPSL formatted updates can be submitted to auto-rpsl(a)ripe.net - RIPE-181 updates are still accepted at auto-dbm(a)ripe.net, but are autmatically converted to RPSL - RFC2725 (Routing Policy Security System) rules apply throughout o 14-May-2001: exchanging mail addresses for submitting RIPE181 and RPSL- formatted updates - auto-dbm(a)ripe.net only accepts RPSL updates - RIPE-181 updates are still possible but now go to auto-181(a)ripe.net and are automatically converted to RPSL (again, RFC2725 rules apply here as well) o 15-Oct-2001: RIPE-181 updates are no longer accepted For further reading, please refer to the migration web page http://www.ripe.net/rpsl or for the discussion during the joint session of the DB/Routing WGs please review the minutes. For technical specifications of RPSL please refer to - rfc2622: "Routing Policy Specification Language (RPSL)" Status: PROPOSED STANDARD, - rfc2650: "Using RPSL in Practice" Status: INFORMATIONAL - rfc2725: "Routing Policy System Security" Status: PROPOSED STANDARD Thanks a lot - the RIPE NCC and the chairmen of Routing: Joachim Schmitz DB: Wilfried Woeber LIR: Hans Peter Holen

1 1

Weekly Routing Table Report
by Routing Analysis 15 Feb '01

15 Feb '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 16 Feb, 2001 Analysis Summary ---------------- BGP routing table entries examined: 101368 Origin ASes present in the Internet Routing Table: 9972 Origin ASes announcing only one prefix: 3547 Transit ASes present in the Internet Routing Table: 1315 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 18 Illegal AS announcements present in the Routing Table: 18 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 3 Number of addresses announced to Internet: 1226430539 Equivalent to 73 /8s, 25 /16s and 216 /24s Percentage of available address space announced: 33.1 Percentage of allocated address space announced: 64.9 Percentage of available address space allocated: 51.0 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 15764 Prefixes being announced from the APNIC address blocks: 14074 APNIC Region origin ASes present in the Internet Routing Table: 1151 APNIC Region origin ASes announcing only one prefix: 416 APNIC Region transit ASes present in the Internet Routing Table: 189 Average APNIC Region AS path length visible: 5.0 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 70018996 Equivalent to 4 /8s, 44 /16s and 103 /24s Percentage of available APNIC address space announced: 68.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: 70049 Prefixes being announced from the ARIN address blocks: 47710 ARIN Region origin ASes present in the Internet Routing Table: 6078 ARIN Region origin ASes announcing only one prefix: 1760 ARIN Region transit ASes present in the Internet Routing Table: 626 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 13 Number of ARIN addresses announced to Internet: 177616408 Equivalent to 10 /8s, 150 /16s and 54 /24s Percentage of available ARIN address space announced: 81.4 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 ARIN Address Blocks 63/8, 64/7, 66/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 15537 Prefixes being announced from the RIPE address blocks: 12279 RIPE Region origin ASes present in the Internet Routing Table: 2739 RIPE Region origin ASes announcing only one prefix: 1367 RIPE Region transit ASes present in the Internet Routing Table: 498 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 106915490 Equivalent to 6 /8s, 95 /16s and 102 /24s Percentage of available RIPE address space announced: 91.0 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 RIPE Address Blocks 62/8, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 1221 2423 1190 Telstra 2764 422 139 connect.com.au pty ltd 2907 376 909 SINET Japan 703 370 244 UUNET Technologies, Inc. 4755 303 108 VSNL India 4740 255 16 Ozemail 4618 211 56 Internet Thailand 9269 209 24 Hong Kong CTI 7545 204 7 TPG Internet Pty Ltd 4538 203 973 China Education and Research 7657 203 12 The Internet Group Limited 7474 194 87 Optus Communications 4763 187 43 Telstra New Zealand 4134 173 547 Data Communications Bureau 4766 171 619 KORnet Powered BY Korea Telec 3462 137 205 Data Communications Institute 4786 134 8 NetConnect Communications Pty 7586 132 10 Paradox Digital Pty. Ltd 7539 129 86 Delegated to TWNIC for subseq 7496 128 9 Power Up RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 702 417 606 UUNET Technologies, Inc. 3301 401 322 TeliaNet Sweden 1257 317 240 Swipnet AB 1270 270 433 UUNET Germany 3215 268 183 RAIN 680 200 888 Deutschef Forschurgsnetz 719 191 146 LANLINK 786 184 960 JANET IP Service 5515 168 318 Sonera Finland 3320 167 462 Deutsche Telekom AG 1849 152 271 UUNET UK (formerly PIPEX) 1942 140 53 GIP Renater 517 135 137 Xlink 2856 133 390 BTnet UK Regional network 3303 129 277 Swisscom 5400 111 31 Concert Internet Plus Europea 1901 104 77 EUnet Austria 1267 99 986 IUnet S.p.A 2830 87 30 UUNET UK (formerly PIPEX) 3269 86 275 TELECOM ITALIA ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 701 2691 3652 UUNET Technologies, Inc. 1 1020 4583 BBN Planet 7018 924 3025 AT&T 7046 742 551 UUNET Technologies, Inc. 705 692 40 UUNET Technologies, Inc. 1239 685 1580 Sprint ICM-Inria 8013 618 71 PSINet Ltd. Canada 2914 613 1272 Verio, Inc. 174 603 2810 PSINet Inc. 3561 570 1299 Cable & Wireless USA 3549 542 506 Frontier GlobalCenter 2551 500 345 NETCOM On-Line Communication 4293 475 58 Cable & Wireless USA 209 463 656 Qwest 271 437 273 BCnet Backbone 2548 395 523 Digital Express Group, Inc. 3908 393 280 Supernet, Inc. 8151 361 193 UniNet S.A. de C.V. 6082 359 63 Management Analysis, Incorpor 11371 324 49 Rhythms NetConnections Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2691 3652 UUNET Technologies, Inc. 1221 2423 1190 Telstra 1 1020 4583 BBN Planet 7018 924 3025 AT&T 7046 742 551 UUNET Technologies, Inc. 705 692 40 UUNET Technologies, Inc. 1239 685 1580 Sprint ICM-Inria 8013 618 71 PSINet Ltd. Canada 2914 613 1272 Verio, Inc. 174 603 2810 PSINet Inc. 3561 570 1299 Cable & Wireless USA 3549 542 506 Frontier GlobalCenter 2551 500 345 NETCOM On-Line Communication 4293 475 58 Cable & Wireless USA 209 463 656 Qwest 271 437 273 BCnet Backbone 2764 422 139 connect.com.au pty ltd 702 417 606 UUNET Technologies, Inc. 3301 401 322 TeliaNet Sweden 2548 395 523 Digital Express Group, Inc. List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 2027 UNALLOCATED 150.185.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 2027 UNALLOCATED 150.186.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.187.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.188.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.189.0.0/16 10530 Interpacket Group, I 1877 UNALLOCATED 192.108.196.0/24 1800 SPRINT 1877 UNALLOCATED 192.108.209.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.210.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.214.0/24 1800 SPRINT 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 5429 UNALLOCATED 195.178.208.0/21 12690 MKS Autonomous Syste 17408 UNALLOCATED 202.133.224.0/19 3462 Data Communications 17411 UNALLOCATED 202.137.32.0/21 703 UUNET Technologies, 17408 UNALLOCATED 203.163.192.0/19 3462 Data Communications 65500 PRIVATE 203.166.86.0/24 10084 Western Australian I 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, 65400 PRIVATE 213.161.78.0/24 6461 AboveNet Communicati Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 39.96.40.224/30 14408 iCAIR 91.16.23.0/24 11770 Net56 103.22.7.0/24 9768 PubNet (Korea Telecom) Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:22 /9:4 /10:5 /11:10 /12:32 /13:62 /14:196 /15:308 /16:6865 /17:1047 /18:2047 /19:6352 /20:4667 /21:4339 /22:6531 /23:8537 /24:59027 /25:273 /26:346 /27:149 /28:108 /29:103 /30:203 /31:0 /32:135 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:3 12:313 13:10 15:1 17:1 24:661 26:1 32:7 38:8 44:3 53:2 55:1 57:9 61:44 62:121 63:1749 64:1307 65:84 66:118 91:1 103:1 128:42 129:173 130:20 131:31 132:10 133:3 134:104 135:8 136:117 137:144 138:189 139:55 140:110 141:44 142:55 143:39 144:189 145:9 146:133 147:55 148:121 149:117 150:25 151:333 152:973 153:35 154:77 155:73 156:15 157:109 158:56 159:61 160:16 161:56 162:60 163:130 164:131 165:107 166:174 167:87 168:72 169:31 170:203 171:2 192:5403 193:1831 194:2016 195:779 196:391 198:3750 199:3432 200:1817 202:2402 203:5236 204:3728 205:2496 206:2765 207:3071 208:2948 209:3395 210:395 211:141 212:829 213:300 214:7 215:11 216:2731 217:114 End of report

1 0

RE: Migration issues: route creation
by Lu, Ping 15 Feb '01

15 Feb '01

Comment followed. > > You can configure the software to resolve these references internally > (by creating "dummy" objects). However, you cannot request "selective > mirroring" for a particular types of objects. > What happen if you don't want to share some of the person objects ? At least, I believe APNIC has a policy to guard private information so they may not want to mirror the maintainer and person objects. > Referential integrity needs to be satisfied only within a > single source. > That is TEST1-MNT with RADB source and TEST1-MNT with the RIPE one are > in fact different objects. > How about AS3561 in RIPE, ARIN and APNIC ? In reality this is the same AS ( assigned by ARIN but need to be present in RIPE and APNIC as well ) And this will be a route creation problem, we will need to register some route objects in RIPE that originates from AS3561 very soon. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

2 1

PAM2001 registration opens (reminder)
by Henk Uijterwaal (RIPE-NCC) 14 Feb '01

14 Feb '01

---------- Forwarded message ---------- Date: Wed, 3 Jan 2001 14:53:19 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" <henk(a)ripe.net> To: Undisclosed recipients: ; Subject: PAM2001 registration opens Passive & Active Measurement: PAM-2001 Registration Opens A workshop on passive and active measurement techniques for high speed computer networks and the Internet Amsterdam, the Netherlands, April 23-24, 2001 As the Internet has grown over the last decade the need for precise measurement of network traffic has become steadily more apparent; most of today's Internet Service Providers and many of their large network customers are collecting and analysing traffic data for the purposes of performance monitoring, network engineering and cost recovery, but the engineering quality of these measurements vary. A steadily growing number of research groups have been working in the areas of: - Active Measurements, i.e. sending test packets and observing their progress through the Internet, - Passive Measurements, i.e. observing actual traffic on 'live' networks, - Performance Metrics, i.e. developing measures or indicators which can be used to characterise traffic behavior, - Traffic Statistics, i.e. attempting to understand and develop models of 'real' Internet traffic, and - Visualisation, i.e. finding effective ways to display what's happening in a network. After the successful workshop PAM2000 in Hamilton, New Zealand, in April 2000, the RIPE NCC will be organising another workshop on this topic in Amsterdam in April 2001. Registration for this workshop has now been opened. To register online, go to: http://www.ripe.net/cgi-bin/pamreg Also available on the web-site are the preliminary program: http://www.ripe.net/pam2001/program.html as well as general information on the workshop: http://www.ripe.net/pam2001/ and hotel information: http://www.ripe.net/pam2001/hotels.html Rooms are available at the conference hotel. The rate is 285 Euro/night (including taxes, approximately 255 US$). To reserve a room, call, fax or email the hotel. Contact details can be found on the web page. If you prefer to stay in another hotel, then there are rooms available in all price classes between 35 Euro/night and 1500 Euro/night within a 5 km radius of the conference site. A selection of hotels and links to reservation sites can be found on the webpage. There are still opportunities for participants to present measurement equipment and software. Proposals for demonstrations (about 500 words, plain ASCII) should be sent by email to the conference chair at pam2001(a)ripe.net by 5 March 2001. Contact information: * PAM 2001 c/o RIPE-NCC Singel 258 1016 AB Amsterdam The Netherlands * Phone: +31.20.5354444 * Fax: +31.20.5354445 * Email: pam2001(a)ripe.net * Webpage: http://www.ripe.net/pam2001 ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous)

1 0

RE: Migration issues: route creation
by Lu, Ping 14 Feb '01

14 Feb '01

Further into the subject. About the new RIPE-DB software V3.X, is that a requirement when mirroring we have to import ALL the objects in order to satisfy the database referencial integerity ? For example, when we mirror with RIPE, if the route object point to a mntner object (thru mnt-by ) do we have to have that mntner object imported also ? If the answer is YES then does a mirroring agreement mean we have to share all the objects ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Lu, Ping [mailto:plu@cw.net] > Sent: Monday, February 12, 2001 10:27 PM > To: 'SchmitzJo(a)aol.com'; andrei(a)ripe.net; reimp-mig-tf(a)ripe.net; > db-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: RE: Migration issues: route creation > > > I think that's me :) Let's talk about the GLOBAL issues and > the practical > use of RR. > > For all RIRs like RIPE, ARIN, APNIC and so on. They are in a > regulartory > position so they OWN all the objects (AN, PN, MT) and they > seldom need to > CROSS-REFERENCE with other RIRs. So the self-contained assumption (all > references should be resloved locally ) is fine with RIR. > > But for the LIRs (especially the ISPs) RR has a more > practical use, like > auto-generated access-lists and as-path filters. Almost all > the major ISPs > have their own tools or use the public tool like RAToolSet to > pull data from > RR then auto-generate the configiuration for their routers. > > Now here is the fun part. > > As a global player we have to create a list of objects ( AN, > RT ) from all > the RIRs and with any public peer (registered in one of the > RIRs ) we have > to create a list of rather private objects ( MT, PN, RO ). > But it becomes > too difficult to duplicate those private objects with up-to-date > information, so the best way is to REFERENCE their LEGAL > objects in any one > of the RIRs ( of course if the AS itself agree us to do so ). > This is where > the GLOBALLY UNIQUE nic-hdl comes in and in a more generic > sense, how about > GLOBALLY UNIQUE maintainer name ? > > Does this sound like domain name system ? Sooner or later RR > has to face the > GLOBAL issue like DNS, IP address and E-MAIL did. > > We have already seen some of the global issues showed up in > the RR domain ( > referral, globally unique nic-hdl ) and there will be more and more > name-collision in the future. > > So why not adopt a naming system like DNS or E-MAIL ? > > Here is my favorite quote from RFC2622 > ----------------------------------------------------- > <nic-handle> is a uniquely assigned identifier word used > by routing, > address allocation, and other registries to > unambiguously refer to > contact information. Person and role classes map NIC handles to > actual person names, and contact information. > ----------------------------------------------------- > > Hmmm! So RPSL already specify the need to use information from OTHER > REGISTRIES. > > I rest my case. > > Ping Lu > Cable & Wireless USA > Network Tools and Analysis Group > W: +1-703-292-2359 > E: plu(a)cw.net > > > > -----Original Message----- > > From: SchmitzJo(a)aol.com [mailto:SchmitzJo@aol.com] > > Sent: Monday, February 12, 2001 7:32 PM > > To: andrei(a)ripe.net; reimp-mig-tf(a)ripe.net; db-wg(a)ripe.net; > > routing-wg(a)ripe.net > > Subject: Re: Migration issues: route creation > > > > > > Dear Andrei, > > > > you wrote that there will be problems creating duplicates of > > aut-nums and > > routes in other registries if they do not formally belong > > there due to the > > authorization rules introduced with the RPSL transition at > RIPE. You > > suggested two solutions: > > > > > Possible solutions to this problem are: > > > > > > 1. Send such registration requests to the Database Administration > > > (ripe-dbm) who will perform registration by overriding > > security (and > > > performing necessary checks before). This puts additional load on > > > ripe-dbm and creates duplicate objects in the RIPE database and > > > "foreign" IRR. > > > > > > 2. Do not allow such registrations. In this case some ISPs > > will need to > > > change their peering policy and accept routing information from a > > > "foreign" IRR. > > > > > > Your comments and suggestions are highly appreciated. > > > > > I did not yet see an answer to your question. However, I > > believe that your > > first suggestion should *not* be followed. I definitely would > > want to avoid > > opening "side" paths to enter data into the RIPE database. > > Using ripe-dbm > > should be the exception for special requirements. For > > everything else, the > > robots should be used. > > > > Regarding duplication: this had originally been introduced to > > help people > > along while mirroring was not working. With RIPE having > > transitioned to RPSL, > > we will have compatible formats again, and do not need > > duplication anymore - > > under the prerequisite that you are properly coordinating > > with RADB and any > > other major IRR. I am inclined to say, that avoiding > > duplication is the > > purpose of the effort! > > > > Looking at your second proposal, I believe that you are > > saying the right > > thing, but phrased it a little different. Peering policy is > > probably a term > > which may be confused with routing policy - and nobody needs > > to change its > > routing policy by looking at several IRRs now. Actually, I > > believe that there > > is not much of an issue: Smaller ISPs have always registered > > in only one IRR; > > only bigger providers with international reach have entered > > their information > > into several IRRs and duplicated data, but then also using > > data from all IRRs > > they registered into. It should not be too much of a pain > to use this > > information to continue with this practice after the RPSL > transition. > > > > Those parties who do not agree, speak up loudly now! > > Thanks > > Joachim > > > > --- JS395-RIPE -- standard disclaimer --- > > >

2 1

Re: Migration issues: route creation
by Andrew Hilborne 13 Feb '01

13 Feb '01

"Lu, Ping" <plu(a)cw.net> writes: > ... > We have already seen some of the global issues showed up in the RR domain ( > referral, globally unique nic-hdl ) and there will be more and more > name-collision in the future. > > So why not adopt a naming system like DNS or E-MAIL ? Or SNMP? Andrew Hilborne

1 0

1. draft minutes of joint Routing/DB wg session RIPE38
by SchmitzJo＠aol.com 13 Feb '01

13 Feb '01

R I P E 3 8 A M S T E R D A M Joint Session DB and Routing 24-Jan-2001 Draft Minutes Chairs: Joachim Schmitz, Wilfried Woeber Scribe: Engin Gunduz Participants: 97 Joint Session of Routing and Database Working Groups Due to the importance of the subject, and the overlap in topic, the chairmen of Routing and Database WG (Wilfried Woeber) decided to have a joint session of both WGs. Joachim introduced the audience to the session, and chaired it together with Wilfried. E. Migration to the new RIPE database (Andrei Robachevsky, RIPE NCC) (20min) [ The presentatino is available at http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations/r38-reimp-a… ei/index.html ] Andrei gave an overview of what to expect for the migration to the new RIPE database. He began with asking who would be affected by the migration, and the answer is: everybody. Reasons are - RPSL format - new access control - new database format - new version mirroring protocol He supported this by a set of examples, and made suggestions on how to prepare for the migration, depending on which usage group a database user belongs to - query users - update users - adaptation of scripts - near real time mirroring Following that a schedule was presented which summarized the proposed final transition dates - 23-Apr-2001: switching to the RPSL database Queries return RPSL only Mirroring follows new format and rules at whois.ripe.net, port 4444 RPSL updates go to auto-rpsl(a)ripe.net RIPE-181 updates are still possible and still go to auto-dbm(a)ripe.net, but are autmatically converted to RPSL - 14-May-2001: exchanging mail addresses auto-dbm(a)ripe.net only accepts RPSL updates RIPE-181 updates are still possible but now go to auto-181(a)ripe.net and are automatically converted to RPSL - 15-Oct-2001: RIPE-181 updates are no longer possible The crucial date is the first one. It will not be possible to go back after that date. The RIPE NCC has prepared a vast set of aides to assist in the transition, and to get used to RPSL format. All details are available at the RIPE-181 to RPSL transition web page http://www.ripe.net/rpsl The presentation led to a vivid discussion, in particular whether the first transition date is too early or too late. Ping Lu was suggesting to move the dates further into the future because - they are using a lot of off-line tools - the downstreams need to be educated He later explains that he himself would transition rather earlier than later but he is worried about their vast customer base. Joachim pointed out that the transition should not be delayed because RADB is already running RPSL since quite some time, making it more complicated for people using both RADB and RIPE. Moreover, he thought that someone had written some tool to perform at least in part some back conversion from RPSL to RIPE-181, which as Wilfried Woeber pointed out would only be possible for a limited number of objects. However, such tool never was available. Christan Panigl reminded the audience that the idea had come up to supply a RAToolSet tutorial at the next RIPE meeting. He suggested to run it before the transition to the RPSL database, essentially before 23-Apr. The audience wants to have this tutorial parallel to the next RIPE meeting. However, this would delay the first transition date into May. A quick poll showed that 10 people in the audience knew RAToolSet, and that actually 2 were using it in conjunction with RADB. It obviously makes sense to have a tutorial -> action 38.R1 on Wilfried Woeber and Joachim Schmitz to organize a RAToolSet tutorial at the RIPE39 meeting Ruediger Volk points out that a transition very shortly after the tutorial does not make much sense. He also stresses that he objects against postponing the transition, because other transition projects within his company have already been delayed due to the not yet factual transition with RIPE. Jake Khuon agrees with Ruediger. He also points out that many of the objects are doubly registered both in RADB and RIPE. Joachim asked the audience who of them are actually using any kind of automated tools in conjunction with the database, and it turned out that these were more or less the same people who also knew RAToolSet. Accordingly, most of the people requesting a tutorial on RAToolSet do not need it right now and are thus also not affected for automation. This decouples the dates of when the tutorial will be held, and the transition to RPSL. Consequently, even though these are only proposed dates, Wilfried suggests to stick to these dates, and people who think that they have real technical problems must speak up to the community to have those reviewed. -> action 38.R2 on Wilfried Woeber and Joachim Schmitz to send around the transition dates, get input from the community, with a following decision on the dates Ping Lu thinking of interaction of databases then brings up the topic of global NIC handles. Wilfried explains that globally unique NIC handles are not related to RPSL, or the transition to RPSL. He has it on his agenda for the Database WG session tomorrow (25-Jan). F. Report from the DB migration task force (Wilfried Woeber, Andrei Robachevsky) Wilfried reported that the DB migration task force did a review and besides a set of questions identified by some active members of the user community, the following open issues were identified - Outreach The RIPE NCC has taken every effort to notify all parties repeatedly who will be affected by the transition. Disappointingly, the feedback on these efforts has been small. - Other items are * broken PGP keys * unprotected aut-num objects * object names not compliant with RPSL which were discussed in a short presentation by Andrei Andrei gave a few statistics on those items, first on their efforts to contact parties which need to be involved, and then on the open issues where Joao Damas explained the proposed solutions. - Broken PGP keys The old PGP programs generated non-compliant PGP keys. Those keys will be refused by version 3 software. It turns out that 7 out of 409 PGP keys are broken. The proposed solution is to delete the key certificates. This does not affect security for a simple reason: If someone wants to apply a change to objects protected that way, the software does not find the corresponding key certificate, and thus rejects the update. The party who wants to submit the change will then be required to contact the RIPE NCC. It was general consensus in the audience to follow that approach. - Unprotected aut-num objects In the past, it had become mandatory to have aut-num objects protected by a maintainer. However, 119 out of 4008 aut-num objects still today do not have a mnt-by attribute. So far, they enjoy a "special" protection: Only ripe-dbm can modify them. Surprisingly, none of them was ever touched in all the time since the original change of requirements. It is still mandatory to have a maintainer with each aut-num object in RPSL. The question is of how to proceed. The proposed solution is to add a special RIPE NCC maintainer. By that way, no security breach is opened, and no change compared to the situation today is introduced. If anybody ever wants to touch that aut-num object again, they still need to contact ripe-dbm. It was general consensus in the audience to follow that approach. - Reserved RPSL names Quite a lot of objects in the database have names which do not comply with RPSL rules. An example are 108 aut-num objects using the reserved prefix "AS-" in the AS-name attribute, or 7 maintainer objects with other reserved prefixes. The proposed solution is to change the names prior to transition in a way which still needs to be agreed upon. A suggestion is to contact all parties who own those objects, and also publish them on appropriate RIPE mailing lists. It was general consensus in the audience to follow that approach. Those results were taken to the Database WG. Ping Lu raised the question whether there was the intention to implement global maintainers. Andrei explained that so far all references must be resolved locally. Andrei also showed which OSs are currently supported for the database software o Solaris 2.8 (Intel & Sparc) o Linux (RedHat, SuSe). o FreeBSD The inquiry from Wilfried showed that this list is accepted by everybody, and no other OSs seem to be used by any company of registry, meaning from that side no problems are expected. Wilfried asked the NCC to release the database software for all platforms without putting too much effort into performance tweaking for each individual OS, just assuring its overall functionality. Anybody who wants to participate in the transition discussion is free to join the migration task force mailing list reimp-mig-tf(a)ripe.net Summary of Open Action Points from the Joint Session of DB and Routing 38.R1 on J.Schmitz, W.Woeber Organize RaToolSet tutorial at RIPE 39 status: new 38.R2 on J.Schmitz, W.Woeber Collect final community input on DB migration dates status: new Engin Gunduz, Joachim Schmitz, February 2001

3 3

RE: Migration issues: route creation
by Lu, Ping 13 Feb '01

13 Feb '01

I think that's me :) Let's talk about the GLOBAL issues and the practical use of RR. For all RIRs like RIPE, ARIN, APNIC and so on. They are in a regulartory position so they OWN all the objects (AN, PN, MT) and they seldom need to CROSS-REFERENCE with other RIRs. So the self-contained assumption (all references should be resloved locally ) is fine with RIR. But for the LIRs (especially the ISPs) RR has a more practical use, like auto-generated access-lists and as-path filters. Almost all the major ISPs have their own tools or use the public tool like RAToolSet to pull data from RR then auto-generate the configiuration for their routers. Now here is the fun part. As a global player we have to create a list of objects ( AN, RT ) from all the RIRs and with any public peer (registered in one of the RIRs ) we have to create a list of rather private objects ( MT, PN, RO ). But it becomes too difficult to duplicate those private objects with up-to-date information, so the best way is to REFERENCE their LEGAL objects in any one of the RIRs ( of course if the AS itself agree us to do so ). This is where the GLOBALLY UNIQUE nic-hdl comes in and in a more generic sense, how about GLOBALLY UNIQUE maintainer name ? Does this sound like domain name system ? Sooner or later RR has to face the GLOBAL issue like DNS, IP address and E-MAIL did. We have already seen some of the global issues showed up in the RR domain ( referral, globally unique nic-hdl ) and there will be more and more name-collision in the future. So why not adopt a naming system like DNS or E-MAIL ? Here is my favorite quote from RFC2622 ----------------------------------------------------- <nic-handle> is a uniquely assigned identifier word used by routing, address allocation, and other registries to unambiguously refer to contact information. Person and role classes map NIC handles to actual person names, and contact information. ----------------------------------------------------- Hmmm! So RPSL already specify the need to use information from OTHER REGISTRIES. I rest my case. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: SchmitzJo(a)aol.com [mailto:SchmitzJo@aol.com] > Sent: Monday, February 12, 2001 7:32 PM > To: andrei(a)ripe.net; reimp-mig-tf(a)ripe.net; db-wg(a)ripe.net; > routing-wg(a)ripe.net > Subject: Re: Migration issues: route creation > > > Dear Andrei, > > you wrote that there will be problems creating duplicates of > aut-nums and > routes in other registries if they do not formally belong > there due to the > authorization rules introduced with the RPSL transition at RIPE. You > suggested two solutions: > > > Possible solutions to this problem are: > > > > 1. Send such registration requests to the Database Administration > > (ripe-dbm) who will perform registration by overriding > security (and > > performing necessary checks before). This puts additional load on > > ripe-dbm and creates duplicate objects in the RIPE database and > > "foreign" IRR. > > > > 2. Do not allow such registrations. In this case some ISPs > will need to > > change their peering policy and accept routing information from a > > "foreign" IRR. > > > > Your comments and suggestions are highly appreciated. > > > I did not yet see an answer to your question. However, I > believe that your > first suggestion should *not* be followed. I definitely would > want to avoid > opening "side" paths to enter data into the RIPE database. > Using ripe-dbm > should be the exception for special requirements. For > everything else, the > robots should be used. > > Regarding duplication: this had originally been introduced to > help people > along while mirroring was not working. With RIPE having > transitioned to RPSL, > we will have compatible formats again, and do not need > duplication anymore - > under the prerequisite that you are properly coordinating > with RADB and any > other major IRR. I am inclined to say, that avoiding > duplication is the > purpose of the effort! > > Looking at your second proposal, I believe that you are > saying the right > thing, but phrased it a little different. Peering policy is > probably a term > which may be confused with routing policy - and nobody needs > to change its > routing policy by looking at several IRRs now. Actually, I > believe that there > is not much of an issue: Smaller ISPs have always registered > in only one IRR; > only bigger providers with international reach have entered > their information > into several IRRs and duplicated data, but then also using > data from all IRRs > they registered into. It should not be too much of a pain to use this > information to continue with this practice after the RPSL transition. > > Those parties who do not agree, speak up loudly now! > Thanks > Joachim > > --- JS395-RIPE -- standard disclaimer --- >

1 0

Re: Migration issues: route creation
by SchmitzJo＠aol.com 13 Feb '01

13 Feb '01

Dear Andrei, you wrote that there will be problems creating duplicates of aut-nums and routes in other registries if they do not formally belong there due to the authorization rules introduced with the RPSL transition at RIPE. You suggested two solutions: > Possible solutions to this problem are: > > 1. Send such registration requests to the Database Administration > (ripe-dbm) who will perform registration by overriding security (and > performing necessary checks before). This puts additional load on > ripe-dbm and creates duplicate objects in the RIPE database and > "foreign" IRR. > > 2. Do not allow such registrations. In this case some ISPs will need to > change their peering policy and accept routing information from a > "foreign" IRR. > > Your comments and suggestions are highly appreciated. > I did not yet see an answer to your question. However, I believe that your first suggestion should *not* be followed. I definitely would want to avoid opening "side" paths to enter data into the RIPE database. Using ripe-dbm should be the exception for special requirements. For everything else, the robots should be used. Regarding duplication: this had originally been introduced to help people along while mirroring was not working. With RIPE having transitioned to RPSL, we will have compatible formats again, and do not need duplication anymore - under the prerequisite that you are properly coordinating with RADB and any other major IRR. I am inclined to say, that avoiding duplication is the purpose of the effort! Looking at your second proposal, I believe that you are saying the right thing, but phrased it a little different. Peering policy is probably a term which may be confused with routing policy - and nobody needs to change its routing policy by looking at several IRRs now. Actually, I believe that there is not much of an issue: Smaller ISPs have always registered in only one IRR; only bigger providers with international reach have entered their information into several IRRs and duplicated data, but then also using data from all IRRs they registered into. It should not be too much of a pain to use this information to continue with this practice after the RPSL transition. Those parties who do not agree, speak up loudly now! Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0