- routing-wg - mailman.ripe.net

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

16 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 12 Feb '01

12 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 12 Feb '01

12 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

1. draft minutes from the RIPE38 Routing WG session
by SchmitzJo＠aol.com 12 Feb '01

12 Feb '01

R I P E 3 8 A M S T E R D A M Routing Working Group Session 24-Jan-2001 Draft Minutes Chair: Joachim Schmitz (JS395-RIPE) Scribe: Engin Gunduz Participants: 97 A. Preliminaries (Joachim Schmitz) The chair man welcomed the participants, and distributed the participants' list to sign in. Engin Gunduz volunteered to take the minutes. The WG agenda was accepted without changes. The minutes of the previous meeting at RIPE37 were accepted by the participants, and are thus declared final. B. The Hermes Project (Giuseppe di Battista, University of Rome) [ The presentation will become available shortly at the RIPE web server ] URL: http://www.dia.uniroma3.it/~hermes The idea of the Hermes project is the integration and visualisation of Routing Registries Information and BGP Routing Data. Consequently, major targets are to o explore the Internet interactions at AS level o visualise interactive maps o show inconsistencies Hermes is based upon a o 3-tier architecture o repository of routing information o mediator for the information integrity. o graph drawing module After presenting the general outline and functionality, Guiseppe showed a demo prerecorded with a screencam from a life example around AS137. This demo included - peering activities (neighbor ASs, and routes) supplemented with more info from the IRR database - in/out routing policies - paths to another AS with routes from that AS and description from the IRR supplemented by AS macros involvede, plus which ASs are part of them Another demo showed more details around routing policies, where the AS was initially selected by its name in the IRR - showing inconsistencies of registered policies of connected ASs The results can be viewed as text and in a graphical map. Guiseppe continued with more details on the internal structure of how Hermes works. In particular he described - three tier architecture - data integration - mediator for data processing - graph drawing around the difficulties introduced by locally sparse and extremely dense parts requiring complex algorithms Eventually, current and future work was summarized: - moving from RIPE-181 to RPSL format (March 2001) - adding new sources of information (RIS project?) - distinguishing between different sources of information (June 2001) - visualisation and animation of route flaps (June 2001) - looking inside an AS: traceoute (June 2001) - looking inside an AS: OSPF (June 2001) Finally, a brief distinction compared to other similar projects was given: o skitter (Caida) [global view of Internet] o ASExplorer (IPMA) [specific view of one single AS] o Hermes [in between] In the brief following discussion, the impression was that Hermes is a useful tool, comprising information from different sources. Q (chair): It is not entirely obvious which data comes from which source. Is this shown in the tool? A: It should be relatively easy, and is actually planned. Q (Ping Lu): What are the means of output? A: So far, the data can only be printed. Since this is a Java applet, it is difficult to produce output in many formats and save them to local disk As final summary, Guiseppe stressed that he welcomes suggestions like this, and asked for any additional input to be sent to him and his group (contact details on the web page http://www.dia.uniroma3.it/~hermes) C. RIS Report (Henk Uijterwaal, Thomas Franchetti, Antony Antony, RIPE NCC) [ Presentation is online at: http://www.ripe.net/ripencc/pub-services/np/Talks/0101_RIPE38_HU/ http://www.ripe.net/ripencc/pub-services/np/Talks/0101_RIPE38_AA/ http://www.ripe.net/ripencc/pub-services/np/Talks/0101_RIPE38_TF/ ] The RIS group gave three presentations 1. Henk Uijterwaal In the introduction, Henk listed a few administrative items - RIS has progressed that for that it will be turned into a regular operational service very soon - To support this move, they are now hiring a 2nd network engineer which will bring the headcount to 2.5 FTE's plus 1 student (from 1-Apr on) - Henk again announced the PAM-2001 workshop Then, a sumamry of the highlights in the past months was given - a new database was introduced to keep up with performance requirements - more powerful hardware was installed, and a scaling analysis will be done with it - currently there are 4 Remote Route Collectors (RRC) at RIPE NCC, LINX, AMS-IX, SFINX; anybody interested in peering to put data into RIS is welcome to contact Antony Antony - two more RRCs are planned, investigating where to place them - work has been done on the user interface, with output on: web, email - vanilla, strawberry, chocolate: which view of the routes do we have in the RIS? The flavors distinguish different amounts of routing info, ranging from filtered and restricted output (vanilla) to the full set of routes (chocolate); RIS prefers to see more - following several requests from different sources (ISMA project, Hermes, ASExplorer,...), the raw data is now available (announced yesterday), check out URL http://abcoude.ripe.net/ris/rawdata During the next months the RIS team plans to - move to production during 2001 - proceed with route collection and expand it - improve and extend the user interface - proceed with network research Henk stressed again that he very much welcomes welcomes input from the community on this project. Joachim reminded Henk of the action, the Routing WG has put on the RIS team, to also implement route flap statistics. Henk confirmed that this is on the list of topics to analyse. 2. Thomas Franchetti In the second part, Thomas presented some results from data collected by RIS - statistics of numbers of prefixes by length show a noticable increase of /24, and /32 - origin ASs announcing only one prefix - distribution of prefix lengths again shows the increase of /24, and /32 - statistics of how many ASs announce certain number of prefixes most ASs announce only very few prefixes, number of announcements per AS is on average decreasing The graphs shown will be made available on the web before RIPE39. Conclusion: - it is necessary to view larger periods to see trends more clearly. - there is a lot of data in RIS, and lots of potential ways to analyze it, but not easy to find ways of presentation; this definitely needs to be explored Joachim finds the parallels interesting between the RIS project results, and other analysis like the one by Philip Smith (distributed on the Routing WG mailing list), or the "standard" CIDR report by Tony Bates. Joachim is eager to see more results at RIPE39, and also welcomes any input from the community; after all these stats are just a glimpse at the wealth of data collected at RIS. 3. Antony Antony In the third part of the presentations on RIS, Antony presented some peculiar RIS observations: - regarding negligence in aggregation, it is amazing how big a number of more specifics is announced from small prefixes (up to several 1000s in a /8) - looking at AS path length, a path with 123 ASs was found, which is very peculiar; this causes several problems, e.g. Cisco actually resets because of missing buffer space; there is also a known Cisco bug where an empty AS path may appear, and thus care must be taken if filtering on AS path length - if AS numbers are considered as such, roughly 82% of RIPE NCC assigned AS numbers are visible by RIS, and the question arises: where are the others? Actually, the RIPE region is still in pretty good shape because the global average is 50%. Following up on this, Daniel Karrenberg added some observations and comments. He noted that the full feed they get from a neighbor consists of 81,272 prefixes, but the maximum number of prefixes from a peer is 100,461. In the beginning, the difference between the extremes was just a couple of thousands, but obviously has expanded tremendously. As Randy Bush has pointed out during the EOF session, it is possible to go down to around 80k prefixes without loosing connectivity. Possibly, people announce redundant data. RIS may be used to catch the source of those redundant data. Daniel was musing whether the NCC should suggest filter lists but would want more discussion on that. D. Routing Registry Consistency Checking (Shane Kerr, RIPE NCC) [ The presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations/rrcc-ripe38… dex.html ] Shane reports that the RIPE IRR currently holds around 24k route objects and 4k AS objects. The quality of the contents varies widely, because there are people who really update their objects, and others who don't. To improve data quality, the data in the IRR is compared to what is found on the Internet. However, the goal is not just reporting, but help to improve the IRR and make it more useful. This is the idea behind the Routing Registry Consistency Checking (R2C2). The following slides gave an overview of the approach, the status, progress, and the plans of the project. Besides route objects and AS objects (routing policies), there are also supporting objects like AS macros which form a set of data to be compared to RIS data. Several reports and tools are in the make, like - summary report - specific report - router configuration checker - IRR correction wizard The project has reached a status where comparisons are possible, and mismatches may be identified. Prototype interfaces and a prototype correction wizard are available. A web page for the project exists with a practical example of the prototype interface. The next steps include polishing and finishing current software, publishing a summary of the project as RIPE-201 document, and seeking community input. Potential possible directions include - a view from specific route collector on request - checking aut-num policy with AS paths - a router configuration verification Additional suggestions include working together with other IRRs and on request from the community develop further applications. This was the last topic in the Routing WG session itself. The second slot was dedicated to a joint session of the Routing and Database WGs dealing with RPSL transition issues. Y. Input from other WGs There was no input from other WGs. Z. AOB There was no other business. Summary of Open Action Points from the Routing WG 36.R1 on RIPE NCC During the transition phase to the RPSL software - verify with RADB on their test suites for RPSL implementations - coordinate with RADB on consistent mirroring of databases (NRTM) - coordinate with RADB on consistent whois interface of databases including irrd status: ongoing 37.R1 on C.Panigl, P.Smith, D.Karrenberg, J.Schmitz Provide updates to RIPE-210 - general editing, review - explanation of damping parameters - examples by implementation - script to determine TLD/root nameservers for "golden network" list status: ongoing 37.R2 on RIS team, Henk Uijterwaal Implement route flap analysis from RIS data status: ongoing Engin Gunduz, Joachim Schmitz, February 2001

1 0