September 1994 - routing-wg - mailman.ripe.net

The Top 20 and some deltas
by Tony Bates 14 Sep '94

14 Sep '94

This is an auto-generated mail on Wed Sep 14 21:10:00 MET DST 1994 As stated above this is auto-generated so it is not checked before it leaves my workstation. This is a list of the "Top 20" players who if CIDRizing at the AS level could make a significant gain in the size of Internet routing tables. This may be an over-estimation but it is hoped that this can act as an incentive for the "Top 20" and others to look at their CIDR capability. This report is available as: ftp://ftp.ripe.net/cidr/stats/Top-20.14Sep94 The current (and of course this one today) report is always accessible as: ftp://ftp.ripe.net/cidr/stats/Top-20 A full summary of all the ASes seen in the Internet can be seen by looking in: ftp://ftp.ripe.net/cidr/stats/AS* Please also find a summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does some indication of ASes participating in CIDR. More information can be found in: ftp://ftp.ripe.net/cidr/stats/Delta.* Also, for a short time this gives details of any possibly interesting aggregates currently seen in the routing. Interesting here means not a aggregate made as a set of classful routes. This a daily snapshot of changes in classfull routes being withdrawn and added. the deltas are calculated over a rolling 7 day period. Please bear in mind this is purely a "snapshot" and a large flucuation could be caused by a connectivity problem for example. However, this does give some indication of service providers that are moving to classless routing. Top 20 Withdrawn Routes from 07Sep94 to 14Sep94 -277 AS174 NYSERNET-AS -75 AS2118 RELCOM-AS -69 AS1717 RENATER -47 AS786 The JANET IP Service -27 AS378 ILAN -25 AS164 DDN-MB-AS -22 AS2044 WORLDNET-AS -20 AS1955 Computer and Automation Institute -11 AS1752 BT main internal data network -8 AS2136 PCC-TECHNO-AS -7 AS1251 ANBR-AS -6 AS813 CANET-ASN -5 AS555 MSCNET-AS -4 AS2607 Slovak technical university -3 AS1901 EUnet Austria -2 AS22 NOSC -1 AS267 CICNET2-AS Top 20 Added Routes from 07Sep94 to 14Sep94 327 AS200 BARRNET-AS 139 AS279 SURANET-AS-2 126 AS86 SURANET-AS 52 AS2149 PSINET-2 37 AS1270 EUnet/DE 27 AS3561 MCI-RESTON 26 AS297 NSN-UMD-AS 25 AS2702 INTERSERVE 23 AS568 SUMNET-AS 18 AS225 VIRGINIA-AS 17 AS2493 FONOROLA-EAST 16 AS542 ARNET 14 AS2018 UNINET-ZA 13 AS97 JVNC-AS 12 AS271 BCNET-AS 11 AS1239 SprintLink 10 AS544 The DataNet IP Service 9 AS2637 GEORGIA-TECH 8 AS1759 The DataNet IP Service 7 AS3113 DOC-ESA-ASN List of possibly interesting aggregates --------------------------------------- aggregate origin-AS AS Description 131.119.9.0/24 AS199 BARRNET-AS 131.119.12.0/24 AS199 BARRNET-AS 131.119.77.0/24 AS199 BARRNET-AS 194.46.1.4/30 AS2873 Genesis Project Internet Servi 194.46.17.4/30 AS2873 Genesis Project Internet Servi Here follows the last weeks "Top 20" list with the corresponding date. --- 14Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1304 646 658 50.5% AlterNet AS174 1112 833 279 25.1% NYSERNET-AS AS1270 526 256 270 51.3% EUnet/DE AS200 662 444 218 32.9% BARRNET-AS AS560 604 432 172 28.5% NEARNET-EXT-AS AS279 587 419 168 28.6% SURANET-AS-2 AS1250 268 123 145 54.1% SINGAPORE-AS AS1275 323 198 125 38.7% DFN-IP AS372 478 359 119 24.9% NSN-AMES-AS AS1221 524 406 118 22.5% AARNET-AS AS97 405 292 113 27.9% JVNC-AS AS681 230 128 102 44.3% KAWAIHIKO-1 AS271 215 115 100 46.5% BCNET-AS AS2150 198 104 94 47.5% CSUNET-SW AS86 398 306 92 23.1% SURANET-AS AS2493 177 96 81 45.8% FONOROLA-EAST AS1239 388 307 81 20.9% SprintLink AS1955 146 75 71 48.6% Computer and Automation Institute AS1225 324 256 68 21.0% CICNET3-AS AS1329 125 58 67 53.6% NSFNETTEST34-AS --- 13Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1300 644 656 50.5% AlterNet AS2149 1333 932 401 30.1% PSINET-2 AS1270 526 256 270 51.3% EUnet/DE AS200 665 442 223 33.5% BARRNET-AS AS560 609 437 172 28.2% NEARNET-EXT-AS AS279 580 414 166 28.6% SURANET-AS-2 AS1250 268 125 143 53.4% SINGAPORE-AS AS1275 323 198 125 38.7% DFN-IP AS1221 522 404 118 22.6% AARNET-AS AS372 487 372 115 23.6% NSN-AMES-AS AS97 402 288 114 28.4% JVNC-AS AS681 228 126 102 44.7% KAWAIHIKO-1 AS271 214 114 100 46.7% BCNET-AS AS2150 201 106 95 47.3% CSUNET-SW AS1239 389 308 81 20.8% SprintLink AS86 358 279 79 22.1% SURANET-AS AS2493 163 87 76 46.6% FONOROLA-EAST AS1955 145 74 71 49.0% Computer and Automation Institute AS1225 326 257 69 21.2% CICNET3-AS AS1329 124 57 67 54.0% NSFNETTEST34-AS --- 12Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1300 647 653 50.2% AlterNet AS2149 1269 913 356 28.1% PSINET-2 AS1270 525 255 270 51.4% EUnet/DE AS200 654 432 222 33.9% BARRNET-AS AS560 609 437 172 28.2% NEARNET-EXT-AS AS279 573 413 160 27.9% SURANET-AS-2 AS1250 269 126 143 53.2% SINGAPORE-AS AS1275 323 198 125 38.7% DFN-IP AS1221 529 406 123 23.3% AARNET-AS AS372 481 367 114 23.7% NSN-AMES-AS AS97 403 290 113 28.0% JVNC-AS AS681 228 126 102 44.7% KAWAIHIKO-1 AS271 214 114 100 46.7% BCNET-AS AS2150 200 105 95 47.5% CSUNET-SW AS2493 170 92 78 45.9% FONOROLA-EAST AS1239 377 301 76 20.2% SprintLink AS1955 144 73 71 49.3% Computer and Automation Institute AS86 330 261 69 20.9% SURANET-AS AS1329 124 57 67 54.0% NSFNETTEST34-AS AS1225 317 250 67 21.1% CICNET3-AS --- 11Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1300 647 653 50.2% AlterNet AS174 1365 974 391 28.6% NYSERNET-AS AS1270 525 255 270 51.4% EUnet/DE AS200 652 435 217 33.3% BARRNET-AS AS560 608 436 172 28.3% NEARNET-EXT-AS AS279 563 412 151 26.8% SURANET-AS-2 AS1250 264 129 135 51.1% SINGAPORE-AS AS1275 323 198 125 38.7% DFN-IP AS97 408 292 116 28.4% JVNC-AS AS1221 507 395 112 22.1% AARNET-AS AS372 459 352 107 23.3% NSN-AMES-AS AS681 226 125 101 44.7% KAWAIHIKO-1 AS271 215 115 100 46.5% BCNET-AS AS2150 200 105 95 47.5% CSUNET-SW AS2493 169 93 76 45.0% FONOROLA-EAST AS1239 378 302 76 20.1% SprintLink AS1955 144 73 71 49.3% Computer and Automation Institute AS1225 318 250 68 21.4% CICNET3-AS AS1329 124 57 67 54.0% NSFNETTEST34-AS AS1849 266 201 65 24.4% PIPEX, Public IP EXchange --- 10Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1300 647 653 50.2% AlterNet AS174 1412 990 422 29.9% NYSERNET-AS AS1270 525 255 270 51.4% EUnet/DE AS560 608 437 171 28.1% NEARNET-EXT-AS AS279 572 414 158 27.6% SURANET-AS-2 AS1250 263 129 134 51.0% SINGAPORE-AS AS1275 323 198 125 38.7% DFN-IP AS1221 521 401 120 23.0% AARNET-AS AS97 409 291 118 28.9% JVNC-AS AS372 473 363 110 23.3% NSN-AMES-AS AS681 228 126 102 44.7% KAWAIHIKO-1 AS271 210 113 97 46.2% BCNET-AS AS2150 200 105 95 47.5% CSUNET-SW AS2493 170 92 78 45.9% FONOROLA-EAST AS1239 378 302 76 20.1% SprintLink AS1955 145 74 71 49.0% Computer and Automation Institute AS1225 320 252 68 21.2% CICNET3-AS AS1329 124 57 67 54.0% NSFNETTEST34-AS AS1849 266 201 65 24.4% PIPEX, Public IP EXchange AS2044 131 70 61 46.6% WORLDNET-AS --- 09Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1293 642 651 50.3% AlterNet AS174 1393 977 416 29.9% NYSERNET-AS AS1270 492 253 239 48.6% EUnet/DE AS560 608 437 171 28.1% NEARNET-EXT-AS AS1250 267 127 140 52.4% SINGAPORE-AS AS279 499 365 134 26.9% SURANET-AS-2 AS1275 323 198 125 38.7% DFN-IP AS1221 524 404 120 22.9% AARNET-AS AS97 405 291 114 28.1% JVNC-AS AS372 483 371 112 23.2% NSN-AMES-AS AS681 228 126 102 44.7% KAWAIHIKO-1 AS271 208 111 97 46.6% BCNET-AS AS2150 197 107 90 45.7% CSUNET-SW AS1955 166 80 86 51.8% Computer and Automation Institute AS1239 376 300 76 20.2% SprintLink AS2493 133 62 71 53.4% FONOROLA-EAST AS1225 320 252 68 21.2% CICNET3-AS AS1329 122 55 67 54.9% NSFNETTEST34-AS AS1849 266 201 65 24.4% PIPEX, Public IP EXchange AS2044 131 70 61 46.6% WORLDNET-AS --- 08Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1293 644 649 50.2% AlterNet AS174 1384 977 407 29.4% NYSERNET-AS AS1270 490 251 239 48.8% EUnet/DE AS560 608 433 175 28.8% NEARNET-EXT-AS AS1250 268 125 143 53.4% SINGAPORE-AS AS1275 323 198 125 38.7% DFN-IP AS1221 519 399 120 23.1% AARNET-AS AS279 449 330 119 26.5% SURANET-AS-2 AS372 483 371 112 23.2% NSN-AMES-AS AS681 228 126 102 44.7% KAWAIHIKO-1 AS97 364 265 99 27.2% JVNC-AS AS271 200 109 91 45.5% BCNET-AS AS2150 197 107 90 45.7% CSUNET-SW AS1955 165 82 83 50.3% Computer and Automation Institute AS786 299 218 81 27.1% The JANET IP Service AS2493 154 81 73 47.4% FONOROLA-EAST AS1329 121 54 67 55.4% NSFNETTEST34-AS AS1225 320 253 67 20.9% CICNET3-AS AS209 339 273 66 19.5% WESTNET-EAST AS1849 264 200 64 24.2% PIPEX, Public IP EXchange --- 07Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1291 642 649 50.3% AlterNet AS174 1389 970 419 30.2% NYSERNET-AS AS1270 489 251 238 48.7% EUnet/DE AS560 607 432 175 28.8% NEARNET-EXT-AS AS1250 252 126 126 50.0% SINGAPORE-AS AS1275 320 197 123 38.4% DFN-IP AS1221 520 400 120 23.1% AARNET-AS AS279 448 329 119 26.6% SURANET-AS-2 AS97 392 279 113 28.8% JVNC-AS AS372 480 368 112 23.3% NSN-AMES-AS AS681 223 124 99 44.4% KAWAIHIKO-1 AS271 203 106 97 47.8% BCNET-AS AS2150 193 103 90 46.6% CSUNET-SW AS1955 166 80 86 51.8% Computer and Automation Institute AS786 299 218 81 27.1% The JANET IP Service AS2493 160 84 76 47.5% FONOROLA-EAST AS1239 377 301 76 20.2% SprintLink AS1329 122 55 67 54.9% NSFNETTEST34-AS AS1225 321 254 67 20.9% CICNET3-AS AS209 321 259 62 19.3% WESTNET-EAST

1 0

Re: The Top 20 and some deltas
by Geoff Huston 14 Sep '94

14 Sep '94

> * Top 20 Added Routes from 31Aug94 to 07Sep94 > * 516 AS1221 AARNET-AS > * 75 AS1717 RENATER > * 26 AS1237 EUNSOL-AS > >My read on this is that AARNET routes have basically finally moved >into their own AS out of the NASA AS at AMES. How soon before AARNET >can fully aggregrate and also pull the more specifics of their exisiting >aggregrates. Nice one. Just need to aggregate the other nets and pull >the more specifics. yep - your reading is correct... > >ASnum NetsNow NetsCIDR NetGain % Gain Description > >AS1221 520 400 120 23.1% AARNET-AS This is where we are heading - although the bulk of the net growth will sit within the 203.0/10 block for the next few months. >Current aggregates coming from AARNET > >SR Aggregate Originator Start-Classful End-Classful P N >-------------------------------------------------------------------------- > Y 192.232.128.0/19 AS1221 192.232.128.0 192.232.159.0 32 1 > Y 202.6.32.0/19 AS1221 202.6.32.0 202.6.63.0 32 1 > Y 202.12.32.0/19 AS1221 202.12.32.0 202.12.63.0 32 16 > Y 202.20.16.0/20 AS1221 202.20.16.0 202.20.31.0 16 16 > Y 203.0.0.0/10 AS1221 203.0.0.0 203.63.255.0 16384 160 > >It should be noted I am not highlighting AARNET as a problem, totally the >opposite in fact as I know AARNET are CIDR capable and >their topology is perhaps the best example we have of seeing full >aggregation for a complete continent ;-). we are working on a fully CIDRized announcement set over the next few weeks thanks, Geoff

1 0

The Top 20 and some deltas
by Tony Bates 10 Sep '94

10 Sep '94

This is an auto-generated mail on Wed Sep 7 21:10:00 MET DST 1994 As stated above this is auto-generated so it is not checked before it leaves my workstation. This is a list of the "Top 20" players who if CIDRizing at the AS level could make a significant gain in the size of Internet routing tables. This may be an over-estimation but it is hoped that this can act as an incentive for the "Top 20" and others to look at their CIDR capability. This report is available as: ftp://ftp.ripe.net/cidr/stats/Top-20.07Sep94 The current (and of course this one today) report is always accessible as: ftp://ftp.ripe.net/cidr/stats/Top-20 A full summary of all the ASes seen in the Internet can be seen by looking in: ftp://ftp.ripe.net/cidr/stats/AS* Please also find a summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does some indication of ASes participating in CIDR. More information can be found in: ftp://ftp.ripe.net/cidr/stats/Delta.* Also, for a short time this gives details of any possibly interesting aggregates currently seen in the routing. Interesting here means not a aggregate made as a chuck of classful routes. This a daily snaphost of changes in classfull routes being withdrawn and added. the deltas are calculated over a rolling 7 day period. Please bear in mind this is purely a "snapshot" and a large flucuation could be caused by a connectivity problem for example. However, this does give some indication of service providers that are moving to classless routing. Top 20 Withdrawn Routes from 31Aug94 to 07Sep94 -654 AS372 NSN-AMES-AS -108 AS3559 KORNET -91 AS1899 Fnet, EUnet-France -78 AS86 SURANET-AS -64 AS297 NSN-UMD-AS -52 AS2119 TelePost IP net -49 AS279 SURANET-AS-2 -40 AS1740 CERFNET -23 AS568 SUMNET-AS -20 AS2702 INTERSERVE -19 AS2134 EUnet-SPAIN AS -16 AS2018 UNINET-ZA -14 AS1251 ANBR-AS -12 AS2895 FREEnet -10 AS2125 EUNET-WIN -8 AS517 XLINK-UKA -7 AS3113 DOC-ESA-ASN -6 AS1849 PIPEX, Public IP EXchange -5 AS555 MSCNET-AS -4 AS1206 PSCNET-HS-AS Top 20 Added Routes from 31Aug94 to 07Sep94 516 AS1221 AARNET-AS 75 AS1717 RENATER 26 AS1237 EUNSOL-AS 23 AS164 DDN-MB-AS 22 AS1955 Computer and Automation Institute 17 AS97 JVNC-AS 16 AS701 AlterNet 12 AS560 NEARNET-EXT-AS 11 AS1270 EUnet/DE 9 AS2150 CSUNET-SW 8 AS544 The DataNet IP Service 7 AS813 CANET-ASN 6 AS1902 CESNET backbone A - EBONE 5 AS55 UPENN-CIS 4 AS771 NSN-RICE-AS 3 AS2111 AS for BELNET sites connected to 2 AS2277 ECUANET 1 AS2706 HKSUPER List of possibly interesting aggregates --------------------------------------- aggregate origin-AS AS Description 157.166.2.0/24 AS1685 ANS-BLK1 157.166.102.0/24 AS1685 ANS-BLK1 157.166.134.0/24 AS1685 ANS-BLK1 157.166.144.0/24 AS1686 ANS-BLK1 157.166.152.0/24 AS1686 ANS-BLK1 157.166.208.0/24 AS1686 ANS-BLK1 193.195.1.4/30 AS786 The JANET IP Service 194.46.1.4/30 AS2873 Genesis Project Internet Servi 194.46.17.4/30 AS2873 Genesis Project Internet Servi Here follows the last weeks "Top 20" list with the corresponding date. --- 07Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1291 642 649 50.3% AlterNet AS174 1389 970 419 30.2% NYSERNET-AS AS1270 489 251 238 48.7% EUnet/DE AS560 607 432 175 28.8% NEARNET-EXT-AS AS1250 252 126 126 50.0% SINGAPORE-AS AS1275 320 197 123 38.4% DFN-IP AS1221 520 400 120 23.1% AARNET-AS AS279 448 329 119 26.6% SURANET-AS-2 AS97 392 279 113 28.8% JVNC-AS AS372 480 368 112 23.3% NSN-AMES-AS AS681 223 124 99 44.4% KAWAIHIKO-1 AS271 203 106 97 47.8% BCNET-AS AS2150 193 103 90 46.6% CSUNET-SW AS1955 166 80 86 51.8% Computer and Automation Institute AS786 299 218 81 27.1% The JANET IP Service AS2493 160 84 76 47.5% FONOROLA-EAST AS1239 377 301 76 20.2% SprintLink AS1329 122 55 67 54.9% NSFNETTEST34-AS AS1225 321 254 67 20.9% CICNET3-AS AS209 321 259 62 19.3% WESTNET-EAST --- 06Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1288 641 647 50.2% AlterNet AS174 1333 954 379 28.4% NYSERNET-AS AS1270 486 250 236 48.6% EUnet/DE AS560 603 433 170 28.2% NEARNET-EXT-AS AS2907 358 193 165 46.1% SINET-AS AS1250 259 119 140 54.1% SINGAPORE-AS AS1275 323 198 125 38.7% DFN-IP AS1221 522 400 122 23.4% AARNET-AS AS97 400 286 114 28.5% JVNC-AS AS1717 565 452 113 20.0% RENATER AS372 484 372 112 23.1% NSN-AMES-AS AS279 432 325 107 24.8% SURANET-AS-2 AS681 225 124 101 44.9% KAWAIHIKO-1 AS271 208 111 97 46.6% BCNET-AS AS2150 192 103 89 46.4% CSUNET-SW AS1239 384 301 83 21.6% SprintLink AS786 301 220 81 26.9% The JANET IP Service AS2493 160 84 76 47.5% FONOROLA-EAST AS1955 147 75 72 49.0% Computer and Automation Institute AS1329 121 54 67 55.4% NSFNETTEST34-AS --- 05Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1287 640 647 50.3% AlterNet AS174 1319 941 378 28.7% NYSERNET-AS AS372 1204 863 341 28.3% NSN-AMES-AS AS1270 487 249 238 48.9% EUnet/DE AS560 603 433 170 28.2% NEARNET-EXT-AS AS1275 323 198 125 38.7% DFN-IP AS97 403 287 116 28.8% JVNC-AS AS1717 558 445 113 20.3% RENATER AS279 433 326 107 24.7% SURANET-AS-2 AS271 208 111 97 46.6% BCNET-AS AS2150 192 103 89 46.4% CSUNET-SW AS1239 384 301 83 21.6% SprintLink AS786 301 220 81 26.9% The JANET IP Service AS2493 161 85 76 47.2% FONOROLA-EAST AS1955 146 74 72 49.3% Computer and Automation Institute AS1329 121 54 67 55.4% NSFNETTEST34-AS AS1849 261 197 64 24.5% PIPEX, Public IP EXchange AS209 319 257 62 19.4% WESTNET-EAST AS2044 129 69 60 46.5% WORLDNET-AS AS137 175 115 60 34.3% GARR --- 04Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1287 640 647 50.3% AlterNet AS174 1278 923 355 27.8% NYSERNET-AS AS372 1063 776 287 27.0% NSN-AMES-AS AS1270 487 249 238 48.9% EUnet/DE AS560 603 433 170 28.2% NEARNET-EXT-AS AS1275 323 198 125 38.7% DFN-IP AS1250 241 123 118 49.0% SINGAPORE-AS AS97 402 288 114 28.4% JVNC-AS AS1717 561 447 114 20.3% RENATER AS279 433 326 107 24.7% SURANET-AS-2 AS271 208 111 97 46.6% BCNET-AS AS2150 193 104 89 46.1% CSUNET-SW AS1239 380 297 83 21.8% SprintLink AS786 299 218 81 27.1% The JANET IP Service AS2493 161 85 76 47.2% FONOROLA-EAST AS1955 146 74 72 49.3% Computer and Automation Institute AS1329 121 54 67 55.4% NSFNETTEST34-AS AS1849 260 197 63 24.2% PIPEX, Public IP EXchange AS209 320 258 62 19.4% WESTNET-EAST AS2044 128 68 60 46.9% WORLDNET-AS --- 03Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1288 641 647 50.2% AlterNet AS174 1346 962 384 28.5% NYSERNET-AS AS372 1206 860 346 28.7% NSN-AMES-AS AS1270 487 249 238 48.9% EUnet/DE AS560 603 433 170 28.2% NEARNET-EXT-AS AS1275 323 198 125 38.7% DFN-IP AS1250 244 119 125 51.2% SINGAPORE-AS AS97 406 289 117 28.8% JVNC-AS AS1717 562 448 114 20.3% RENATER AS279 433 326 107 24.7% SURANET-AS-2 AS271 208 111 97 46.6% BCNET-AS AS2150 186 98 88 47.3% CSUNET-SW AS1239 365 283 82 22.5% SprintLink AS786 301 220 81 26.9% The JANET IP Service AS2493 162 86 76 46.9% FONOROLA-EAST AS1955 146 74 72 49.3% Computer and Automation Institute AS1329 121 54 67 55.4% NSFNETTEST34-AS AS1849 261 197 64 24.5% PIPEX, Public IP EXchange AS209 318 258 60 18.9% WESTNET-EAST AS2044 130 70 60 46.2% WORLDNET-AS --- 02Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 920 372 548 59.6% AlterNet AS372 828 533 295 35.6% NSN-AMES-AS AS1270 485 248 237 48.9% EUnet/DE AS2149 585 384 201 34.4% PSINET-2 AS1717 592 456 136 23.0% RENATER AS1275 323 198 125 38.7% DFN-IP AS2150 166 81 85 51.2% CSUNET-SW AS786 300 219 81 27.0% The JANET IP Service AS1239 337 260 77 22.8% SprintLink AS271 144 69 75 52.1% BCNET-AS AS1955 146 74 72 49.3% Computer and Automation Institute AS2493 142 74 68 47.9% FONOROLA-EAST AS1329 104 41 63 60.6% NSFNETTEST34-AS AS560 290 228 62 21.4% NEARNET-EXT-AS AS2044 130 70 60 46.2% WORLDNET-AS AS137 179 119 60 33.5% GARR AS1849 250 191 59 23.6% PIPEX, Public IP EXchange AS86 207 155 52 25.1% SURANET-AS AS1225 209 157 52 24.9% CICNET3-AS AS97 193 145 48 24.9% JVNC-AS --- 01Sep94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 920 372 548 59.6% AlterNet AS372 828 533 295 35.6% NSN-AMES-AS AS1270 485 248 237 48.9% EUnet/DE AS2149 585 384 201 34.4% PSINET-2 AS1717 592 456 136 23.0% RENATER AS1275 323 198 125 38.7% DFN-IP AS2150 166 81 85 51.2% CSUNET-SW AS786 300 219 81 27.0% The JANET IP Service AS1239 337 260 77 22.8% SprintLink AS271 144 69 75 52.1% BCNET-AS AS1955 146 74 72 49.3% Computer and Automation Institute AS2493 142 74 68 47.9% FONOROLA-EAST AS1329 104 41 63 60.6% NSFNETTEST34-AS AS560 290 228 62 21.4% NEARNET-EXT-AS AS2044 130 70 60 46.2% WORLDNET-AS AS137 179 119 60 33.5% GARR AS1849 250 191 59 23.6% PIPEX, Public IP EXchange AS86 207 155 52 25.1% SURANET-AS AS1225 209 157 52 24.9% CICNET3-AS AS97 193 145 48 24.9% JVNC-AS --- 31Aug94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1275 643 632 49.6% AlterNet AS174 1363 971 392 28.8% NYSERNET-AS AS372 1134 819 315 27.8% NSN-AMES-AS AS1270 478 247 231 48.3% EUnet/DE AS560 595 427 168 28.2% NEARNET-EXT-AS AS1250 255 117 138 54.1% SINGAPORE-AS AS279 497 364 133 26.8% SURANET-AS-2 AS1275 323 198 125 38.7% DFN-IP AS97 375 275 100 26.7% JVNC-AS AS271 205 111 94 45.9% BCNET-AS AS2150 184 96 88 47.8% CSUNET-SW AS786 299 218 81 27.1% The JANET IP Service AS1239 379 300 79 20.8% SprintLink AS2493 158 86 72 45.6% FONOROLA-EAST AS1955 144 73 71 49.3% Computer and Automation Institute AS86 350 282 68 19.4% SURANET-AS AS297 238 170 68 28.6% NSN-UMD-AS AS1329 122 55 67 54.9% NSFNETTEST34-AS AS1225 312 246 66 21.2% CICNET3-AS AS1849 262 198 64 24.4% PIPEX, Public IP EXchange

4 8

Routing WG agenda, Lisboa
by jimi＠dxcoms.cern.ch 09 Sep '94

09 Sep '94

Sorry to be late. Here is the agenda of the coming Routing-WG. Documents to read beforehand: - ftp://ftp.ripe.net/ripe/drafts/ripe-81++.{txt,ps} - ftp://ftp.ripe.net/ripe/drafts/ripe-81++.changes.{txt,ps} I whish this Working group as short as possible (we only need consensus:-) so that we can agree on the final version of Ripe-81++. If the a 3 hours time slot is not enough, then .... See you all in Lisboa, -- Jean-Michel ------------------------------- RIPE Routing-WG Draft Agenda (3 hours, may be less...) 0. Previous minutes; action list Minutes taker 1. Ripe-81 ++ and compagnion documents 1.1 Summary of Changes since last version (Tony) 1.2 Outstanding Issues: - Possible integration of Interas-in/out in as-in/out, if not: + Interas-in/out syntax + What should as-in be if Interas-in present ? 2. Router Object (short discussion, details to be discussed in the DB-WG) 2. Closing, AOB -- Jean-Michel

1 0

Draft Transition document
by Tony Bates 08 Sep '94

08 Sep '94

Find below the draft of the promised transtition document to incorporate all the proposed features of the new database. This is also available as ftp://ftp.ripe.net/ripe/drafts/db-trans.{txt,ps} We will bring copies of this document to the RIPE as we are so late in getting it out (we will not be doing this for other documents so please take note). Regards and see you in Lisbon, --Tony. RIPE Database Transition Plan DRAFT DRAFT DRAFT Tony Bates Daniel Karrenberg Marten Terpstra Document-ID: ripe-1nn August, 1994 ABSTRACT This paper details a transition plan of the changes needed to move from the current RIPE Database to a RIPE Database that supports classless IP network numbers, authorisation of updates and changes to Routing Registry information. 1. Introduction The RIPE database is about to undergo some major changes. These changes come from a set of documents produced by various RIPE work- ing groups and the RIPE NCC. There are three major changes to the RIPE database that will affect the database in such a way, that a description of the changes and a clear transition plan is needed. These three changes are: o Support for Classless Internet Addresses [1]. o Authorisation and Notification of Changes [2]. o Representation of IP Routing Policies in a Routing Registry [3]. All these three new features of the RIPE database will affect the working of the RIPE Database, from simple things like altered out- put, to more complex things like guarded attributes and objects [4]. The three changes will be dealt with in turn in this document. If you wish to get a quick overview of how this affects you please refer to Section 5. ripe-1nn.txt August, 1994 - 2 - Each of the sections will have points in time attached to them, at which time a certain change will take effect. These points in time are labeled T1 and T2. For some changes that need to be made, a cer- tain "flag day" is needed. On these days some changes will take place that are not backward compatible and must be performed in a "big bang" type of change. These dates are labeled B1 and B2. All changes will be labeled with a Tn and/or a Bn. Table 1 shows the current time estimates for each of these changes. +---------+----------+------+ | Date | Big Bang | Time | +---------+----------+------+ | Now | | T0 | |15-10-94 | B1 | T1 | | 1-12-94 | B2 | T2 | +---------+----------+------+ Table 1: Timescales for transition changes In the sections describing a change, there will be a small section shortly describing the effect this will have on users of the RIPE database. For this document the users have been categorised in four groups: users querying the database, AS and community guardians, maintainers of "inetnum" objects and maintainers of other database information. 2. Support for Classless Internet Addresses There are several aspects pertaining to the introduction of class- less Internet addresses in the RIPE Database as document in [2]. 2.1. Querying the RIPE database To support classless addresses in the RIPE database, one different representation of Internet addresses will be supported for queries to the database. This notation is the prefix/length notation as explained in [1]. Correct queries to the database will be for exam- ple: 192.87.45.0/24 192.87.228.0/23 128.141.0.0/16 193.0.0.132/32 For backward compatibility, "old" style queries will still be sup- ported. They are however internally to the database server trans- formed to a prefix/length notation, after which they are handled as above. This transformation could change the expected output. For example: ripe-1nn.txt August, 1994 - 3 - 192.87.45 will be rewritten internally to 192.87.45.0/32 128.141 will be rewritten to 128.141.0.0/32 193.0.0.0 will be rewritten to 193.0.0.0/32 Other type queries that are supported, but not encouraged are pre- fix/length queries, for which the prefix is not a full dotted quad: 128.141/16 will be rewritten to 128.141.0.0/16 192.87.45/24 will be rewritten to 192.87.45.0/24 For queries where the prefix and the length are incompatible (like 192.87.45.0/8), the length will be used to mask off all extra bits from the prefix. This example will be rewritten to 192.0.0.0/8. % whois -r 193.1.209.0/24 inetnum: 193.1.209.0 netname: NCIR-LAN descr: Local Ethernet descr: National College of Industrial Relations descr: Sandford Road descr: Dublin 6 descr: Ireland country: IE admin-c: Neil Armstrong tech-c: Neil Armstrong connect: RIPE NSF aut-sys: AS1213 changed: mnorris(a)hea.ie 940823 source: RIPE % whois -r 193.1.209.0/8 inetnum: 193.0.0.0 - 193.255.255.255 netname: RIPE-CBLK descr: European Address Block #1 country: EU admin-c: DK58 tech-c: TB230 tech-c: MT2 remarks: delegated changed: testdb(a)ripe.net 940707 source: RIPE The default behavior for the RIPE database will be to respond to the query with an exact match if possible, or otherwise the first less specific match it can find. In most cases this will mean that when queries for host addresses (193.0.0.132/32) one will receive the network block this host is part of as registered in the database (in this case probably 193.0.0.0/24). ripe-1nn.txt August, 1994 - 4 - % whois -r 193.0.0.132/32 inetnum: 193.0.0.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra tech-c: Tony Bates aut-sys: AS3333 ias-int: 193.0.0.221 AS1104 ias-int: 193.0.0.157 AS1104 rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops(a)ripe.net changed: tony(a)ripe.net 940708 source: RIPE The RIPE NCC will also insert objects that describe a block delega- tion to an Internet Registry into the database. For example the block 193.1.0.0 - 193.1.255.255 delegated to HEANET, will have an associated entry in the database. When one would query a network number from this block that has not been allocated by HEANET yet, the server will respond with the object for the complete block. This means that less queries will result in a "No entries found" answer, but will give some indication of where that specific piece of address space currently resides. The same is true for address blocks 193.0.0.0 - 193.255.255.255 and 194.0.0.0 - 194.255.255.255 dele- gated to the RIPE NCC. % whois -r 193.1.141.0/24 inetnum: 193.1.0.0 - 193.1.255.255 netname: EU-BLOCK-193-1 descr: HEAnet country: IE admin-c: Mike Norris tech-c: Mike Norris remarks: delegated changed: marten(a)ripe.net 930901 source: RIPE The database server will also support some extra features to display the complete list of less specific matches, a list of direct more specific matches, and a list of more specific matches including more specifics of more specifics. The flags to enable these features can be found in the RIPE whois client manual page. All of these changes will take place at once when enabling the soft- ware that supports classless internet addresses at B1. Changes to tools that make use of the database server have to be made before ripe-1nn.txt August, 1994 - 5 - that time. 2.2. Changes to the guardian files Currently all guardians of guarded attributes maintain files on the RIPE NCC database machine. These files are examined once per day and the associated guarded attribute added to all network objects listed in these files. When a network block is found in the database , and not all of the networks in this block are mentioned in a guardian file, this block is split so that only the mentioned networks get the associated guarded attribute. This procedure can no longer work in a classless database for two reasons: o from a block of network numbers it is no longer clear where one network ends and the next one starts. The class A, B and C boundaries no longer apply, so the software cannot make deci- sions any longer on where to split a block if necessary; o a certain network number can appear more than once in the database in different block entries. In normal cases, any net- work number assigned through the NCC will appear at least three times in the database: once in the entry describing the alloca- tion to an end-side or user, once as a block delegation from the NCC to a local registry, and once as a block delegation from IANA to the RIPE NCC. It is therefore impossible for the software to find out which of these blocks should be split and where this guarded attribute should be added. The way this will be solved is to only add guarded attributes to objects if the entry in the guardian file exactly matches the "inet- num" value of an object in the database. Assume we have a guardian file that contains two lines: 192.87.45.0 193.0.0.0 - 193.0.0.5 In this case, the guarded attribute associated with this file will NOT be added to entry "192.87.45.0 - 192.87.46.0", "193.0.0.0 - 193.255.255.0" or any other non-exact match in the database. Since blocks are no longer split, any line in the guardian file that does not correspond to an exact match in the database, will cause a notification mail message to be sent to the guardian with the expla- nation that no match could be found in the database. Because this is a direct effect of the enabling of the classless ripe-1nn.txt August, 1994 - 6 - software, this change will have to be made at B1. This means that all guardians will have to check their files for non-matching entries and correct them. The NCC will assist all guardians that have an account on the NCC database machine by generating a problem file for them. This file will list all entries in their guardian file that are either not present in the database, or entries that are appear in a bigger block in the database. Any non-exact match can therefore easily be spotted. The program producing these files will run every night up till B1. The file generated will be called "problems" and will be put in the home directory of each of the guardians. Guardians are strongly requested to change their guardian files to eliminate any non-exact match before B1. At point B1, non-exact matches can cause a loss of guarded attributes. It should be noted that this transition is an interim measure to be used between T1 and T2. A completely new procedure to guard attributes and objects is outlined in [2] and a transition for that proposal is outlined in the next section. 3. Authorisation and Notification of Changes The RIPE NCC has produced a paper that describes a mechanism to authorise and notify any changes to objects in the RIPE database [2]. Although these changes apply to all objects in the database, there are some transition issues when these mechanisms are used to replace the current guarded attribute and guarded object procedure. The general use of the authentication and notification will be available from T1. 3.1. Guarded Attributes As explained in [4] the current procedure for guarded attributes is that guardians maintain files on the NCC database machine, from which guarded attributes are added to objects to the database. Although this has worked reasonably well for over a year, it can be solved with a more general authentication and notification scheme. This scheme is explained in [2]. The introduction of "route" objects in the RIPE database (see below) removes the necessity of guarded attributes in their current form. The primary reason for having guarded attributes (authenticity guar- antees because of their operational impact) can be solved by the general authentication scheme. The transition issues involved are of a bootstrap nature. This tran- sition plan foresees the generation of routes from existing network numbers. This will be explained in more detail in the next section. When these newly generated routes are to be used they should be properly maintained using the proposed mechanism. To bootstrap this procedure and to ensure that all routes are properly maintained, the NCC will generate an example "mntner" object [2] for all guardians ripe-1nn.txt August, 1994 - 7 - that have an account on the NCC database machine. The information for this object will be placed in a file in each guardian's home directory. The file name will be "mntner". The information in this object will be derived as best as possible from the current guardian information. These objects will be gener- ated once only. The guardian can then change this object in whatever way he/she wishes. The guardian can even decide to already submit the modified "mntner" object generated for them to the database. At B2, all routes that will be generated from the current network numbers will be maintained by the maintainer mentioned in the file generated in the associated guardian accounts. To ensure that all generated routes are properly maintained, only the "mntner" file in each of the guardian's accounts will be used to tag the newly gener- ated routes. The "mntner" object found in this file will also be automatically entered into the database. Guardians that currently maintain multiple files on multiple accounts can decide to only reg- ister with a single "mntner" object. They will have to ensure that the "mntner" objects in all their accounts are equal. For more details see below. The current guardian procedure will be turned off at B2. At that time, the newly generated route objects should all be maintained, and the need for guardians in the current meaning will have disappeared. All guardian accounts and files will be removed shortly after B2. 3.2. Guarded Objects The RIPE database currently has support for guarded objects. These are objects that cannot be updated using the automatic procedure, but need to be manually checked by NCC staff and are then forwarded to the database. Currently the only guarded objects are "community" and "aut-num". This mechanism was put in place to avoid mistakes when updating operationally critical objects like autonomous system objects. It is fairly obvious that this procedure can be replaced using the authentication mechanism described in [2]. At T1, the maintainer mechanism will be enabled and current guarded attributes can start using this mechanism to replace the manual intervention by the NCC currently needed. For a certain time, guarded objects will still be accepted using the old mechanism (mailed to ripe-dbm(a)ripe.net for checking), but whenever a "mnt-by" attribute is present in any guarded object, these objects can be updated automatically. This does however mean it will have to pass the authorisation as specified by the maintainer. 4. Transition to RIPE-81++ There are several important aspects pertaining to the transition of the objects documented in RIPE-81++ [3]. This also includes the related "inet-rtr" object [5]. ripe-1nn.txt August, 1994 - 8 - 4.1. Separation of routing from allocation information This represents a significant change to both the database objects and to actual data in the database. The two database objects affected will be the existing "inetnum" [8] object and the "route" object as detailed in [3]. This will result in some information being moved from the "inetnum" [6] object to "route" object and some information being deleted from the "inetnum" object. If we look at an existing "inetnum" object: inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra connect: RIPE NSF WCW aut-sys: AS3333 comm-list: SURFNET ias-int: 192.87.45.80 AS1104 ias-int: 192.87.45.6 AS2122 ias-int: 192.87.45.254 AS2600 rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops(a)ripe.net changed: tony(a)ripe.net 940110 source: RIPE The routing information contained in the "inetnum" object will now be distributed over two objects like so: ripe-1nn.txt August, 1994 - 9 - inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops(a)ripe.net changed: tony(a)ripe.net 940110 source: RIPE route: 192.87.45.0/24 descr: RIPE Network Coordination Centre origin: AS3333 comm-list: SURFNET remarks: ias-int: 192.87.45.80 AS1104 remarks: ias-int: 192.87.45.6 AS2122 remarks: ias-int: 192.87.45.254 AS2600 changed: dfk(a)ripe.net 940427 source: RIPE The general idea is all routing based information is moved from attributes within the "inetnum" object to the "route" object (1). It is important to note the direct effect this have on the "inetnum" object data. Table 2 below gives a full list of the transitioned attributes. It should also be noted that in an effort to clean up the "inetnum" object at the same time certain attributes will be obsoleted. The effect column has an T for transitioned and an O for obsoleted. +------------------+--------+-----------------+ |inetnum attribute | effect | route attribute | +------------------+--------+-----------------+ |aut-sys | T | origin | |comm-list | T | comm-list | |ias-int | T | remark | |connect | O | | |gateway | O | | |routpr-l | O | | |bdrygw-l | O | | +------------------+--------+-----------------+ Table 2: Affected attributes As can be seen a simple translation can be made and this will be the _________________________ (1) The "ias-int" attributes are preserved as re- marks. See details of "inet-rtr" object for reasoning behind this. ripe-1nn.txt August, 1994 - 10 - last major transition step at time T2. 4.2. Auto-Generation of "Route" and New "Inetnum" objects Clearly, the transitioning of data will require a major flag day where the translation of attributes detailed in Table 2 takes place. This is expected to occur at big bang B2. At point B2 the RIPE NCC will automatically generate both new "route" and "inetnum" objects in line with Table 2 and load them into the RIPE database. It should be noted that these changes will only take place to "inetnum" objects with have an associated "aut- sys" attribute. All "inetnum" objects not containing the aut-sys attribute will have both T and O attributes removed. This may mean the potential loss of comm-list information if there is no corre- sponding aut-sys attribute for the existing "inetnum" object. Between time T1 and T2 the NCC will generate for each guardian account both the translated "inetnum" and "route" objects in the form of files known as: new.inetnum This file will contain a full list of "to be generated" "inet- num" objects. new.route This file will contain a full list of "to be generate" "route" objects. These files will be re-written every night and are purely given to give each guardian of what will happen to any associated object ref- erencing a guarded attribute after B2. The new "route" objects will be automatically split into CIDR [7] compliant aggregates. Below is a simple example of an automatic object split from the current "inetnum" to a new "inetnum" and "route" object. The original "inetnum" is as follows: inetnum: 193.12.128.0 - 193.12.132.0 netname: SE-COMVIS-NET descr: ComputerVision Sweden AB country: SE admin-c: Anders Andersson tech-c: Anders Andersson connect: SWIP aut-sys: AS1257 changed: uffe(a)swip.net 930707 source: RIPE ripe-1nn.txt August, 1994 - 11 - The will be translated to an new "inetnum" object as follows: inetnum: 193.12.128.0 - 193.12.132.0 netname: SE-COMVIS-NET descr: ComputerVision Sweden AB country: SE admin-c: Anders Andersson tech-c: Anders Andersson changed: uffe(a)swip.net 930707 source: RIPE Notice all attributes noted in Table 2 are now removed. The follow- ing two (yes two, because this entry was not CIDR [7] aligned) "route" objects are also generated: route: 193.12.128.0/22 descr: SE-COMVIS-NET origin: AS1257 mnt-by: AS1257-MNT changed: ripe-dbm(a)ripe.net 940829 source: RIPE route: 193.12.132.0/24 descr: SE-COMVIS-NET origin: AS1257 mnt-by: AS1257-MNT changed: ripe-dbm(a)ripe.net 940829 source: RIPE You also see that mnt-by attributes have been added to the "route" objects. This information has been derived from the "maintainer" files in each guardian account (see above for details of this). In this case the guardian of AS1257 named his maintainer object "AS1257-MNT". All other administrative attributes are preserved in both the "inetnum" and "route" objects which exception of the changed field which in the "route" object will just represent the At the time B2, you will also see both the new "inetnum" and "route" objects in the database. If "inetnum" entries are sent into the database with obsoleted attributes the entries will be accepted with the obsoleted attributes removed and a warning sent back indicating the obsoleted attributes have been removed. The auto-generation will happen at a set time at B2. This is a one- time operation and all users of the RIPE database should be aware of this major change. ripe-1nn.txt August, 1994 - 12 - 4.3. The "inet-rtr" object The "inet-rtr" object is an object which can be used to describe any router within an autonomous system [5]. This object can be used as of time T1. One important piece of the "inet-rtr" object is that it will replace the "ias-int" attribute used in the old "inetnum" object. We encourage all users of the "ias-int" attribute to regis- ter new "inet-rtr" object from time T1 onwards. In an effort to pre- serve any loss of "ias-int" information when the auto-generation of "route"'s and "inetnum"'s takes place the ias-int information will be included as a "remarks" attribute in the generated "route" object. Here is a simple example: route: 192.87.4.0/24 descr: EUR-IP origin: AS1755 remarks: ias-int: 192.87.4.17 AS1755 remarks: ias-int: 192.87.4.18 AS1103 remarks: ias-int: 192.87.4.19 AS2121 remarks: ias-int: 192.87.4.20 AS286 remarks: ias-int: 192.87.4.21 AS1104 remarks: ias-int: 192.87.4.22 AS1755 remarks: ias-int: 192.87.4.24 AS1103 remarks: ias-int: 192.87.4.35 AS1128 remarks: ias-int: 192.87.4.27 AS1890 remarks: ias-int: 192.87.4.28 AS3333 changed: ripe-dbm(a)ripe.net 940829 source: RIPE We realise this is non optimal and encourage the use of the "inet- rtr" object from time T1 onwards. 4.4. New "RIPE-81++" Syntax All proposed "ripe-81++" syntax will be accepted after B1 at time T1, with the exception of the changes to "inetnum" and "route" objects which will not be accepted until B2 at time T2 (see section "Auto-Generation of "Route" and New "Inetnum" objects" above for reasoning behind this). The direct effect of this is you will see different whois output. The most important aspect will be the addi- tion of syntactic sugar to the existing "as-in" and "as-out" attributes as well as the ability to use the attributes as well. To highlight this change if we look at a current "aut-num" object a whois query would produce the following: ripe-1nn.txt August, 1994 - 13 - aut-num: AS1104 descr: NIKHEF-H descr: Science Park Watergraafsmeer descr: Amsterdam, The Netherlands as-in: AS1103 100 AS1103 as-in: AS1890 100 AS1890 AS2004 AS288 as-in: AS1888 100 AS1888 as-in: AS2122 200 AS2122 AS2600 as-in: AS2600 100 AS2600 as-in: AS3333 100 AS3333 as-out: AS1103 AS1104 as-out: AS1890 AS1104 as-out: AS1888 AS1104 as-out: AS2122 AS1104 as-out: AS2600 AS1104 as-out: AS3333 AS1104 default: AS1103 100 guardian: ripe-op(a)nikhef.nl admin-c: Rob Blokzijl tech-c: Marten Terpstra remarks: peers with AS2122 and AS2600 are RR test peers notify: tony(a)ripe.net notify: marten(a)ripe.net changed: tony(a)ripe.net 940426 source: RIPE As of B1 the same query will produce: ripe-1nn.txt August, 1994 - 14 - aut-num: AS1104 descr: NIKHEF-H descr: Science Park Watergraafsmeer descr: Amsterdam, The Netherlands as-in: from AS1103 100 accept AS1103 as-in: from AS1890 100 accept AS1890 AS2004 AS288 as-in: from AS1888 100 accept AS1888 as-in: from AS2122 200 accept AS2122 AS2600 as-in: from AS2600 100 accept AS2600 as-in: from AS3333 100 accept AS3333 as-out: to AS1103 announce AS1104 as-out: to AS1890 announce AS1104 as-out: to AS1888 announce AS1104 as-out: to AS2122 announce AS1104 as-out: to AS2600 announce AS1104 as-out: to AS3333 announce AS1104 default: AS1103 100 guardian: ripe-op(a)nikhef.nl admin-c: Rob Blokzijl tech-c: Marten Terpstra remarks: peers with AS2122 and AS2600 are RR test peers notify: tony(a)ripe.net notify: marten(a)ripe.net changed: tony(a)ripe.net 940426 source: RIPE This is an important subtle change and anyone using tools should be aware of this change. To provide some backward compatibility it is possible to use the "-S" flag to the whois server to produce output without the added syntax information. A whois client supporting this flag will also be made available at B1. ripe-1nn.txt August, 1994 - 15 - 5. Visible Changes and Actions Required by User Group The effects of the B1/B2 changes and the actions needed by the dif- ferent groups of RIPE database users are summarised below. This is intended as a check list for members of those user groups. It should be noted most readers of this document will belong to more than one group. 5.1. Routing Registry Guardians This group comprises those who maintain the information in the Rout- ing Registry part of the database: "aut-num" and "community" guardians and guardian file maintainers. This group will see the most changes and need to take some actions. 5.1.1. Between now and B1 Action Change entries in guardian files to exactly match single database objects. 5.1.2. After B1 and before B2 Action Check and update the "mntner" objects generated in the guardian accounts, thus establishing a mapping between guardian files and "mntner" objects. Action Check the file of generated "route" objects and modified "inet- num" objects in the guardian account for errors and report those to the NCC. 5.1.3. After B2 Change Guardian file mechanism is no longer needed and disabled. Change Route objects created. Action Clean up guardian accounts. Action Align any locally stored objects with the split objects. Action Check "route" objects for remarks containing "ias-int" attributes and create "inet-rtr" objects where necessary. ripe-1nn.txt August, 1994 - 16 - 5.2. Local Registries This is the group who maintains "inetnum" objects. They will see the consequences of the "inetnum"/"route" split and will be able to use the new authorisation scheme. 5.2.1. Between now and B1 No changes or actions before B1. 5.2.2. After B1 and before B2 Change Now possible to store multiple "inetnum" objects covering the same address space at different levels. Change All representations decribed in [1] can be used for object sub- mission. Change New authorisation now available. Action Coordinate authorisation on objects maintained by more than one party. Action Prepare for "inetnum"/"route" split especially when storing data locally. Action Check "inetnum" objects for "ias-int" attributes and create "inet-rtr" objects where necessary. 5.2.3. After B2 Change Some attributes obsoleted and some moved to "route" object. Action Align any locally stored objects with the split objects. Action Stop submitting obsolete/moved attributes. 5.3. Maintainers of other Objects This group will basically only see added authorisation features and the need for coordination of this when multiple parties maintain an object. ripe-1nn.txt August, 1994 - 17 - 5.3.1. Between now and B1 No changes or actions before B1. 5.3.2. Change New authorisation now available. Action Coordinate authorisation on objects maintained by more than one party. 5.3.3. After B2 No changes or actions after B2. 5.4. Users of RIPE DB Information This is the group who queries the RIPE whois server and/or uses the database files. 5.4.1. Between now and B1 Action Check and adapt tools for the effects of B1: queries will return less specific matches if no exact match can be found. 5.4.2. After B1 and before B2 Change Network number queries can be classless and return less spe- cific matches if no exact match is found. Change Ability to obtain less and more specific matches on network number queries. Action Check and prepare tools for the effects of B2: "route"/"inetnum" split, obsoleted attributes, new attributes, syntactic sugar returned by default in "aut-num". 5.4.3. After B2 Change Effects of "route"/"inetnum" split will be visible. 6. Results The results from this three phase transition will the following ripe-1nn.txt August, 1994 - 18 - achievements. 1) A fully supported classless database (as of B1). 2) A new and improved authorisation and maintenance mechanism (as of B2). 3) Full support of ripe-81++ features (completed by B2 and most available from B1). As with any transition of this type some change of data is unavoid- able and a number of "big bang" days need to be factored in. How- ever, the end result is a clear improvement to both the RIPE alloca- tion and routing registry. Throughout the whole transition period the RIPE NCC will be available to make emergency changes to data if needed and deemed to be critical. All queries should be directed towards ncc(a)ripe.net. 7. References [1] Bates, T., Karrenberg, D., Terpstra, M., "Support for Classless Internet Addresses in the RIPE Database", DRAFT, May 1994. [2] Karrenberg, D., Terpstra, M., "Authorisation and Notification of Changes in the RIPE Database", DRAFT, Aug 1994. [3] Bates et al, "Representation of IP Routing Policies in a Rout- ing Registry (ripe-81++), DRAFT, August 1994. [4] Bates, T., "Support of Guarded fields within the RIPE Database", ripe-117, July 1994. [5] Bates, T., "Specifying an `Internet Router' in the Routing Reg- istry", DRAFT, July 1994. [6] Lord, A., Terpstra, M., "RIPE Database Template for Networks and Persons", DRAFT, May 1994. [7] Fuller, V et al, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC1519, Septem- ber 1993. [8] Karrenberg, D., "RIPE Database Template for Networks", ripe-050, April 1992. ripe-1nn.txt August, 1994

1 0

ripe-60 phased out
by Marten Terpstra 06 Sep '94

06 Sep '94

Folks, I have the pleasure to announce that as of tomorrow morning all occurences of boundary gateways and routing privileges will be removed from the RIPE database. This means that ripe-60 has finally been phased out completely. -Marten

1 0