- routing-wg - mailman.ripe.net

1st draft agenda Routing WG RIPE 38
by SchmitzJo＠aol.com 24 Jan '01

24 Jan '01

Dear colleagues, please find enclosed the first draft of the agenda for the session of the routing working group at RIPE 38, Amsterdam. The session will be held Wednesday, 24-January, 14:00 Routing WG session Due to the importance of the subject and because it is affecting both working groups we are having a joint session of the routing and database groups on the same day in the 2nd afternoon slot. I would also like to direct your attention to an interesting session of the EOF (see http://www.ripe.net/ripe/meetings/current/ripe-38/eof.html) Tuesday, 23-January, 9:00 EOF Routing Panel As usual comments, additions, changes to the agenda of the Routing WG welcome! --- R I P E 3 8 A M S T E R D A M Routing Working Group Session 24-January-2001 Draft Agenda A. Preliminaries (Joachim Schmitz) (5min) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 37 minutes - actions from earlier meetings B. The Hermes Project (Andrea Carmignani, University of Rome) (30min) C. RIS Report (Henk Uijterwaal, RIPE NCC) (15min) D. Routing Registry Consistency Checking (Shane Kerr, RIPE NCC) (30min) Joint Session with the Database WG E. Migration to the new RIPE database (Andrei Robachevsky, RIPE NCC) (20min) F. Report from the DB migration task force (Ulf Kieber, Global Access Telecommunications) (??min) Y. Input from other WGs Z. AOB --- Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

2 1

Weekly Routing Table report
by Philip Smith 22 Jan '01

22 Jan '01

Hi, Following several requests from participants in the European Operators Forum in Amsterdam today, I've decided to merge the reports I send separately to each region. Rather than posting the AP specific report to the APOPS list, the European specific report to the RIPE Routing WG list, and the American specific report to the ARIN RTMA list, I've combined each report into one posting sent to each of the three lists. Apologies in advance if this breaks any automatic mail filters - the new weekly posting will come with a subject line of "Weekly Routing Table Report"... I appreciate any comments or feedback you may have. I hope this change is an improvement, and will give all of you a better view of what is happening in each of the three registry regions of the world. best wishes! philip --

1 0

The Cidr Report
by Tony Bates 19 Jan '01

19 Jan '01

This is an auto-generated mail on Fri Jan 19 12:00:00 PST 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 19Jan01 0) General Status Table History ------------- Date Prefixes 120101 96318 130101 96282 140101 96187 150101 96311 160101 96451 170101 96505 180101 97424 190101 95598 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 AS Summary ---------- Number of ASes in routing system: 9674 Number of ASes announcing only one prefix: 5638 (3180 cidr, 2458 classful) Largest number of cidr routes: 982 announced by AS701 Largest number of classful routes: 1618 announced by AS701 1) Gains by aggregating at the origin AS level --- 19Jan01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Announcement: RIPE Whois Database Version 3.0beta2 released
by RIPE Database Announcements 19 Jan '01

19 Jan '01

Dear All, This mail is to inform you that version 3.0beta2 of the RIPE Whois Database software has been released. This is mainly a bugfix release in respect to the "beta1" version. We remind you that the RIPE Database is about to change its data format, from RIPE181 to RPSL (the Routing Policy Specification Language, see RFC2622). This will affect all object types, including "person", "domain" and "inetnum". We suggest you to start to get used to RPSL and version 3.0 . Please check our RIPE-181 to RPSL Migration page at: http://www.ripe.net/rpsl/ You can test your skills with RPSL and the functionality of the new beta release in the following ways: - Query rpsl.ripe.net at port 43. You will find there exactly the same objects that are in whois.ripe.net, mirrored live and in RPSL format. - If you have any script that runs by querying whois.ripe.net, test it by pointing it to rpsl.ripe.net and make it v3.0-compliant. - Try our CGI interface to the RPSL server: you can find it at http://www.ripe.net/ripencc/pub-services/db/reimp/. - Get to know the new update path: use our "sandbox" database for RPSL updates. Send your updates to <auto-rip(a)ripe.net> and query the corresponding database at rpsl.ripe.net, port 4343 . Remember that in a few months, that's the way the RIPE Database will be running; so the earlier you start working with it, the less likely you are to be unpleasantly surprised later. For those running Near-Real-Time Mirrors of the RIPE Database, please be advised that as soon as the RIPE Database changes its data format, you will not be able to mirror the RIPE Database using the version 2 of the Software, since it is not RPSL-compliant. You will have to upgrade to version 3 to mirror the RIPE Database. Please contact <ripe-dbm(a)ripe.net> for detailed information. Please note that the software is still in a "beta" phase. So we need your feedback! If you happen to find something that looks like a bug when you are testing the RPSL database, don't hesitate... Send us a bug report at <dbrip(a)ripe.net> ! If you want to actively participate to the migration effort, you could join the "RIP migration Task force" and let yourself be heard. Just write to <ripe-dbm(a)ripe.net> and ask to join the Task Force. You can download the latest release of the source code at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0beta2.tar.gz You can also join a discussion list related to version 3.0 beta of the RIPE Database Software. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. It is a moderated mailing list so some delays in subscription are possible. Regards, Daniele Arena ___________________ RIPE Database Group RIPE NCC

2 1

RIPE NCC Region Weekly Routing Report
by Routing Analysis 18 Jan '01

18 Jan '01

This is an automated weekly mailing sent to the RIPE Routing WG e-mail list describing the state of the Internet Routing Table in Europe, Middle East and North Africa. 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>. Europe, Middle East, North Africa Report 19 Jan, 2001 Analysis Summary ---------------- BGP routing table entries examined: 100161 Origin ASes present in the Internet Routing Table: 9709 Origin ASes announcing only one prefix: 3439 Transit ASes present in the Internet Routing Table: 1290 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 17 Illegal AS announcements present in the Routing Table: 17 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 1 Number of addresses announced to Internet: 1196700186 Equivalent to 71 /8s, 84 /16s and 50 /24s Percentage of available address space announced: 32.3 Percentage of allocated address space announced: 63.3 Percentage of available address space allocated: 51.0 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 15313 Prefixes being announced from the RIPE address blocks: 12075 RIPE Region origin ASes present in the Internet Routing Table: 2671 RIPE Region origin ASes announcing only one prefix: 1323 RIPE Region transit ASes present in the Internet Routing Table: 490 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 16 Number of RIPE addresses announced to Internet: 88695932 Equivalent to 5 /8s, 73 /16s and 100 /24s Percentage of available RIPE address space announced: 75.5 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 RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 3301 390 306 TeliaNet Sweden 702 348 469 UUNET Technologies, Inc. 1270 338 433 UUNET Germany 1257 316 256 Swipnet AB 3215 200 181 RAIN 719 192 154 LANLINK 5515 190 343 Sonera Finland 786 183 959 JANET IP Service 1849 172 290 PIPEX 3320 167 462 Deutsche Telekom AG 680 164 846 Deutschef Forschurgsnetz 517 140 140 Xlink 1942 140 53 INRIA-Rocquencourt 2856 136 394 BTnet UK Regional network 3303 126 277 Swisscom 5400 109 32 Concert Internet Plus Europea 1901 103 77 EUnet Austria 1267 96 986 IUnet S.p.A 3269 89 242 TELECOM ITALIA 3259 85 87 UUNET, a MCI Worldc Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2608 3548 UUNET Technologies, Inc. 1221 2367 1189 Telstra 1 1022 4628 BBN Planet 7018 902 3023 AT&T 1239 694 1636 Sprint ICM-Inria 7046 694 521 UUNET Technologies, Inc. 2914 637 1289 Verio, Inc. 174 618 2823 PSINet Inc. 2548 611 551 Digital Express Group, Inc. 705 561 36 UUNET Technologies, Inc. 3561 560 1283 Cable & Wireless USA 2551 552 345 NETCOM On-Line Communication 3549 512 436 Frontier GlobalCenter 8013 506 64 PSINet Ltd. Canada 3908 447 281 Supernet, Inc. 2764 435 123 connect.com.au pty ltd 209 431 569 Qwest 3602 430 79 Sprint Canada 4293 427 55 Cable & Wireless USA 271 424 271 BCnet Backbone 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, 65160 PRIVATE 193.150.192.0/18 6830 chello broadband 65010 PRIVATE 195.98.237.0/24 2200 INRIA-Rocquencourt 65500 PRIVATE 203.166.86.0/24 10084 Western Australian I 65103 PRIVATE 204.29.186.0/23 6992 Netscape Communicati 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, 65160 PRIVATE 213.200.128.0/18 6830 chello broadband Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 91.16.23.0/24 11770 Net56 Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:4 /10:5 /11:10 /12:31 /13:59 /14:194 /15:305 /16:6777 /17:1010 /18:2027 /19:6263 /20:4434 /21:4318 /22:6450 /23:8419 /24:58056 /25:291 /26:411 /27:244 /28:182 /29:154 /30:275 /31:1 /32:220 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:2 12:306 15:1 24:640 26:1 32:29 38:8 44:2 53:2 55:1 57:9 61:61 62:102 63:1559 64:1177 65:24 66:78 91:1 128:28 129:190 130:20 131:31 132:9 133:4 134:94 135:7 136:121 137:78 138:190 139:68 140:289 141:19 142:61 143:36 144:123 145:11 146:135 147:89 148:119 149:109 150:22 151:330 152:963 153:118 154:58 155:71 156:14 157:102 158:57 159:52 160:18 161:57 162:63 163:122 164:112 165:98 166:175 167:77 168:71 169:31 170:193 171:2 192:5403 193:1808 194:1982 195:818 196:394 198:3757 199:3396 200:1737 202:2469 203:5216 204:3538 205:2488 206:2825 207:3003 208:2846 209:3438 210:378 211:131 212:760 213:293 214:8 215:11 216:2629 217:88 End of report

1 0

1. draft minutes of RIPE 37 Routing WG session
by SchmitzJo＠aol.com 18 Jan '01

18 Jan '01

Dear colleagues, please find below the first draft of the minutes of our working group session at RIPE 37 in Amsterdam. My thanks go to Marek Bukowy who prepared the minutes, which took me then just too long to review them and send them out... As usual: comments, corrections, additions are very much appreciated. Thanks Joachim --- JS395-RIPE -- standard disclaimer --- R I P E 3 7 A M S T E R D A M Routing Working Group Session 14-Sep-2000 Draft Minutes Chair: Joachim Schmitz (JS395-RIPE) Minutes: Mark Bukowy Participants: 97 A. Preliminaries Joachim chaired the meeting, gave a brief introduction, and passed around the participants' list. Asking for a scribe to take the minutes of the session lead to the usual panic in the audience that one of them may be chosen deliberately by the chair, but to general relief Marek Bukowy volunteered, and took the minutes you are reading now. The agenda for the session was accepted without changes. The minutes of last RIPE meeting (RIPE36) distributed earlier on the mailing list were accepted by the audience, and thus are declared final. Remaining actions from earlier meetings were: 31.R1 on RIPE NCC, D.Kessens, J.Schmitz Basic design for an IPv6 IRR -done- This has become part of the RIPE NCC activity plan for 2001, allocating resources for this project; also a part on multicast has been added. From the point of view of that this has been initiated, the action is considered closed. Both the IPv6 and the Routing WG will continue to follow the development. 32.R1 on RIPE NCC, JLS.Damas Prepare draft document on issues of RIPE-181 to RPSL transition -done- The draft document has been prepared and is available at the URL http://www.ripe.net/ripencc/pub-services/db/reimp/new-transition-v3.ps 34.R1 on C.Panigl Provide updates to RIPE-178 -done- Christian has provided the updates which are available as RIPE document RIPE-210. However, the contents has triggered additional dicussion; accordingly, we will have some short presentations and input from the audience later during the session 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 This action is still ongoing Multicast Workshop Report As part of the introduction, Joachim reported on the Multicast Application Workshop which had been held on Tuesday. It had been fully organized and prepared by Patrick de Muynck (BELNET). He himself gave some presentations and got additional contributions from Steve Simlo (Cisco), and Andreas Bogk (integrated media). Both BELNET and Cisco provided the hardware, making the practical presentations possible. Together with the RIPE NCC they built the demonstration network. Joachim thanked all people who worked to make the workshop a success, in particular Patrick who spent most of the time on that. The audience of 70 participants was definitely very pleased with the workshop which is considered to be a great success. C. RADB Update (Gerald Winters, Frontier Global Crossing) presentation available at http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/gerard_wint… / Gerald summarized status, development, and future projects around RADB. In particular * recent developments were - conversion to RPSL complete - Merit's maintainer fee program receives broad community support - additional features around interface like autoformatting and atomic transaction support - PGP key-cert object support - work is ongoing regarding "RPS Dist" * Relational DB backend Instead of using flat files, RADB now employs a relational database backend (TimesTen), allowing relational queries when using IRRd. For several features this has already proven its usefulness, but there are also concerns whether the software will meet the performance requirements. This is being tested. An important note is that the IRRd integration with the TimesTen backend will become available as open source code. * Scaling issues Due to the growth of the community, RADB is faced with various scaling issues. Work has been done to improve the situation but not all of it is easily tackled. * Future projects Gerald mentioned the following projects which will be dealt with in the future - RPS auth implementation - GPG support - IRRd v2.0 release - introducing software for bug tracking which will be open to the community The presentation was particularly interesting because it did not only show the status of RADB as one of the main registries in the world, but also the different development and focus due to differing boundary conditions and requests from the community compared to the RIPE database. E. RIS, Status and Plans (Henk Uijterwaal, RIPE NCC) presentation available at: http://www.ripe.net/ripencc/pub-services/np/Talks/0009_RIPE37/ Henk gave a brief overview of several items, glancing first at administrative stuff like more staff becoming available for the project, and announcing the PAM2001 workshop dealing with measuring data on the Internet. Details are available at the URL http://www.ripe.net/pam2001 The highlights of the past months were - upgrades of the database server to handle the increased load - introduction of a 2nd router collector, installed at the LINX - development of the new tool showing ASs in use, which can be tried at http://abcoude.ripe.net/ris/asinuse.cgi - generation of daily reports In the upcoming months, RIS development will be contined, in particular improving performance, and increasing data input. The intent is to move this to production during the course of 2001. In a question from the audience, it was referred to an observation of RIS during the previous RIPE meeting: RIS sees more prefixes in the union of all peers than what is generally known as the defaultless routing table. The question was whether this is now understood? Henk reported that no definite answer has yet been found. Discussions were held at SitCom, IETF, and some ideas on how to attack this problem have come up. However, this is still work in progress. F. The Routing Registry Consistency Project (Shane Kerr, RIPE NCC) presentation available at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/rrc/ Shane gave an introduction to this new project initiated in the Routing WG. Essentially, it builds on - RIS, the Routing Information Service, where life data from the Internet is collected - and the RIPE IRR comparing both sets of data. The main goal of the project is to make the database more accurate, and thus more useful. Suggestions of user interfaces were presented, and what the current status of the project is: As this presentation was a introduction to new work, the project is still in the initial research phase, but they also start to build comparison tools. G. Study of BGP Convergence (Abha Ahuja, Internet Network Services) presentation available at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/RIPE-37-con… gence/ The title of the presentation had been changed to "Delayed Internet Routing Convergence", focussing on a very interesting facet of BGP convergence. Essentially, the question is how well the Internet infrastructure does tolerate faults. According to conventional wisdom fault toleration seems to be high and problems are resolved fast. This has been put to the test with a simple failure analysis: To this end, a route is inserted or withdrawn at one point on the Internet, and its visibility is measured at other places on the Internet. There were quite some surprises found in the analysis of the results. In particular, the idea that "bad information travels fast" is actually wrong. It was shown that in 60% of the cases, complete withdrawal of an invalid route takes more than 2 minutes. The reason for that lies in the fact that all possible paths must be explored and then individually invalidated. This becomes a problem which grows as the factorial of the number of BGP speakers, and results from avoidance of loops. Essentially, this means that in the extreme, BGP may not converge at all. So far, we are saved by BGP policies, and several BGP timers which put a bound on some of the behaviour. However, with an ever growing Internet, this becomes more and more of a problem. The presentation caused a vivid discussion, in detail: Q: What was the path length between the point of injection of the withdrawal and the measuring point ? A: variable (different ISPs were used in the measurement). Conclusion is that it has no influence. Q: Does route flap dampening help achieve better convergence ? A: Yes, it would bound some of the announcements. However, the worst case scenarios don't really occur in real life. Q: The effectiveness of dampening is though determined by its settings? A: Definitely. Some people in the room have been affected by wrongly set dampening parameters. Injected announcements alternated with withdrawals will be dampened if they are "oscillating" faster than the flap dampening timers allow. Q: This was also the reason for ripe-178. Have you been able to reproduce this effect in the following situation: 2 AS's connected in 4 places, a withdrawal would travel 4 times between the AS's. In effect, one route flap would appear 4 times, and consequently the BGP neighbours would damp the route immediately. A: There was no real conclusion on that question; however, it is obvious that complex situations are generated easily. Christian Panigl who described this example, will discuss this in detail with Abha for further real life studies. Q: On internet exchange points all peers are directly connected to each other. Would that be a potential for similar effects? A: Ideally, these peers are not exchanging full routing tables, but only their internal and their customers' routes. The theoretical worst case scenario shown here can happen if you provide mutual transit. Q: Does it also apply to IGP meshes as they are growing bigger ? A: There is obviously some impact, but details are not known, because Abha and her colleagues have not yet looked at it. However, it will be taken up H. Routing Table Analysis (Philip Smith, Cisco) presentation available at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/RIPE37-sept… 0-Smith.pdf The studies of Abha were nicely complemented by the routing table analysis, Philip does and has recently started sending to the Routing WG mailing list. He described the work he is doing there in his presentation, thanking APNIC for their support, also showing some interesting findings and developments. Essentially, Philip analyzes the full defaultless Internet routing table, taken in daily snapshots. An important part is the correlation to the three regional registries and IANA definitions. Important findings are in the global summary - routing tables again growing exponentially, in particular 100k prefixes will be reached by end Dec 2000 (6 months ago predicted to be Sep 2001) same applies to ASs (10k will be reached Dec 2000) - origin AS rising very significantly - average AS path length more or less stable somewhere 5...6 - max path length 15 also quite stable (removing prepends) - worried in particular about exploding /24 announcements - and longer prefixes (why should they be announced?) An interesting observation is that - only 62% of address space allocated is actually announced - less than half of 17000 assigned ASs are actually announced This presentation also triggered some discussion: Q: Do you strip out duplicate ASN's (to compensate for providers with funny routing policies) A: I think I do. I am certainly stripping out any ASpath pre-paths. Q: Assigned and not announced ASN's: some might not wish to exchange traffic. A: Looking at the ASN's < 10000 there are clusters of not announced ASN's, most notably US military, but also others. Q: Is there an effect of prefix filtering and who is doing it? A: This would most likely become real apparent only when looking at several sources of routing information because it is difficult to determine where more specifics disappear I. RIPE-210 - Updates with contributions from the audience (Philip Smith, Cisco, & Christian Panigl, Vienna IX) presentation available at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/dampening.p… First, Philip gave a presentation discussing issues he has seen in the RIPE-210 document. He found that RIPE-210 and RIPE-178 have different network lists which leads to confusion. Moreover, the damping parameters as described do not work. However, the discussion showed that the effect of the parameters depend on the Cisco IOS version, which seems to indicate a Cisco implementation bug, which would need further study. There was no information available about other implementations. Philip then showed some pages from Cisco teaching materials explaining route flap damping, especially the definition of the parameters involved, and how to properly combine them. There was general consensus that it makes sense to incorporate something like this in the document, but also try to get input about how to configure flap damping for other platforms. Philip also found some open questions like whether we would want to suppress slowly oscillating prefixes, or whether we may want to make damping dependent on prefixes, AS paths, or communities. From the audience, the question arose whether any data exists on route oscillations on the Internet, and whether any studies were done. Philip was not aware of any research effort. He had started gathering some flap statistics in Australia, but thinks that doing this at a more central place on the Internet would be much more useful. Abha reported that Merit did a study on announcements/withdrawals a couple of years ago at some US exchange points, measuring oscillations rates etc (for reports about this experiment please contact Abha Ahuja). However, currently no measurements are done. Abha indicated that she is interested to take it up again in her measurements, and data is collected at the RIPE RIS project anyway - it just needs to be analyzed (which is an additional input for RIS development). Nonetheless, in a whole it is interesting to see that damping methods exist but no studies on their effect or efficiency on route flaps on the Internet. Finally, Christian had a few more comments. He explained that he had come up with a list of "golden networks" to exclude from route flap damping due to an incident on a network: routes to the TLD/root nameservers became dampened and those unreachable for more than two hours. The reason for that was insufficient connection to the global Internet, so flapping on the upstream backbone (single connection to the global Internet) can cause exactly this problem. However, keeping the list of networks uptodate is difficult, and we want to avoid having different versions of the same document around. One suggestion was to explicitely flag it as an example which should not be implemented as is. However, experience shows that exactly those examples are most often just copied without crosschecking. Therefore, the idea was to remove the explicite list in its entirety from the document. Instead, Daniel Karrenberg offered to write a script and make it available, which generates a list of the "golden networks", essentially the networks of the TLD/root nameservers (using "dig" on one of the root nameservers). J. Promoting IP Multicast deployment in Europe (Tony Ballardie <ballardie(a)ngn-ltd.co.uk>) presentation available at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/RIPE37-sept… 0-Ballardie/ Tony is anticipating a large demand for multicast, and thus introduced the European IP Multicast Initiative (EuMI). He wants to assess sources of problems with multicast deployment, and pro-actively promote it by proposing a "one-stop shop" with - free consulting (limited in time to about a day) - free forum for exchanging ideas - gather input and (re)write documents, explain RFC's, etc to provide for clear, easy to use, documentation. Both sponsors and input is needed for this project. Details can be found at http://www.eumi.net. With those presentations the session had significantly run overtime into the coffee break but thanks to meeting management, there was still enough coffee available for the participants who then came to visit the joint session of the routing and database working groups. The joint session was introduced because of the overlap on the topic of transitioning from the old RIPE-181 database to the RPSL style database. B. Status of the transition to the RPSL database (Andrei Robachevsky, RIPE NCC) presentation available at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/r37-reimp/ The biggest question was discussed first: what is different in the new implementation. This was illustrated by a whole set of examples, where many of them are based on RPSL itself, and its impact on the various objects and attributes in the RIPE database. Moreover, Andrei pointed out that there will also be other differences, around working with the database (querying with a bunch of new options, submissions to the database now with MIME support extended PGP support), near realtime mirroring, and accounting and access control. Andrei then gave an overview about the status the project was in, regarding functionality and availability of test servers. The software is still in beta status and is still tested. Certain features are missing, in particular the overall server infrastructure (backup, cleanup, logging, etc). Others need further development, most notably MIME support, server configuration and administration, and portability of the code has room for improvements. The essential pointers for test usage and information are - near real time mirror of the RIPE database (contains current data in RPSL format): "whois -h rpsl.ripe.net" - test server for submissions: mail <auto-rip(a)ripe.net> for submissions and "whois -h rpsl.ripe.net -p 4343" for queries - mailing list db-beta(a)ripe.net - RIPE NCC development team reachable at dbrip(a)ripe.net - web page http://www.ripe.net/ripencc/pub-services/db/reimp/ Then, Andrei described the transition plan again briefly with its various phases, which had been agreed upon quite some time ago. The initial phases I and II have passed, and we are moving to phase III, which moves the authoritative source of the RIPE database to the new server, with RPSL format. All output would then be RPSL, submissions will be possible with RPSL style to an RPSL input, and with RIPE-181 style to the old existing standard address (mail <auto-dbm(a)ripe.net>). This move will only be done depending on confidence and consensus in the community. Only after a certain transition time, phase IV will start, still allowing RIPE-181 submissions, but to another mail address, while the standard mail interface at auto-dbm(a)ripe.net will only accept RPSL style. This will allow to slowly phase out RIPE-181, which in phase V will then no longer be accepted. Finally, Andrei listed a set of obvious transition issues. The list of issues is definitely not yet final, and any input from the community is welcome. To present a focus of concerns and to drive the transition, the Database Migration Task Force has been initiated. Y. Creation of the Database Migration Task Force. For the Database Migration Task Force, Ulf Kieber (UK41-RIPE) has agreed to be its chairman. For communication of the task force, the RIPE NCC will set up the mailing list reimp-mig-tf(a)ripe.net Everybody is encouraged to participate. Participation of people involved in: - mirroring the database (format and software will change) - parsing the routing registry output (format will change) is particularly welcome. Topics will also include the portability of the new db software. Summary of Open Action Points 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 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 37.R2 on RIS team, Henk Uijterwaal Implement route flap analysis from RIS data Marek Bukowy, Joachim Schmitz, January 2001 -----

1 0

The Cidr Report
by Tony Bates 16 Jan '01

16 Jan '01

This is an auto-generated mail on Fri Jan 12 12:00:00 PST 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 12Jan01 0) General Status Table History ------------- Date Prefixes 050101 95475 060101 95482 070101 95512 080101 95490 090101 95422 100101 95551 110101 99200 120101 96318 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 7237 Number of ASes announcing only one prefix: 3821 (1389 cidr, 2432 classful) Largest number of cidr routes: 637 announced by AS701 Largest number of classful routes: 1652 announced by AS1221 1) Gains by aggregating at the origin AS level --- 12Jan01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS10501 2 1 1 50.0% PacLink AS10390 2 1 1 50.0% TELECHECK AS10240 2 1 1 50.0% MOTLEYFOOL AS10173 2 1 1 50.0% KSNET.Inc AS9995 1 1 0 0.0% Japan Network Information Center AS9991 1 1 0 0.0% Japan Network Information Center AS9983 1 1 0 0.0% Australian Bureau of Statistics. AS9982 1 1 0 0.0% PAICHAI UNIVERSITY AS9979 1 1 0 0.0% KOREA EXCHANGE BANK AS9978 1 1 0 0.0% The University of Seoul AS9974 1 1 0 0.0% KOREA SECURITIES COMPUTER CORP. B AS9973 1 1 0 0.0% KEB Futures Co. AS9968 1 1 0 0.0% Kyobo Life Insurance AS9962 1 1 0 0.0% Sunchon National University AS9960 1 1 0 0.0% NEW C&C CO.,LTD. AS9954 1 1 0 0.0% Kunsan National University AS9953 1 1 0 0.0% Hyundai Eng. & Const. Co., Ltd. AS9951 1 1 0 0.0% D3C Net AS9950 1 1 0 0.0% INT Co.,Ltd. AS9935 1 1 0 0.0% AGNS-Customer-KW AS9928 1 1 0 0.0% Crystal Internet AS9927 1 1 0 0.0% A Multihomed ISP Company AS9912 1 1 0 0.0% Quality Internet Services AS9879 1 1 0 0.0% OGILVY ASIA/PACIFIC AS9877 1 1 0 0.0% Ngee Ann Polytechnic Computer Cen AS9875 1 1 0 0.0% PT. Pasifik Satelit Nusantara AS9871 1 1 0 0.0% JC Entertainment Co. AS9868 1 1 0 0.0% Catholic University of TAEGU HYOS AS9866 1 1 0 0.0% LGCAPITAL AS9862 1 1 0 0.0% YES24 CO. LTD For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

2 2

RIPE NCC Region Weekly Routing Report
by Routing Analysis 11 Jan '01

11 Jan '01

This is an automated weekly mailing sent to the RIPE Routing WG e-mail list describing the state of the Internet Routing Table in Europe, Middle East and North Africa. 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>. Europe, Middle East, North Africa Report 12 Jan, 2001 Analysis Summary ---------------- BGP routing table entries examined: 99712 Origin ASes present in the Internet Routing Table: 9621 Origin ASes announcing only one prefix: 3385 Transit ASes present in the Internet Routing Table: 1264 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: 19 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 1 Number of addresses announced to Internet: 1227454848 Equivalent to 73 /8s, 41 /16s and 121 /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 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 15293 Prefixes being announced from the RIPE address blocks: 11979 RIPE Region origin ASes present in the Internet Routing Table: 2648 RIPE Region origin ASes announcing only one prefix: 1313 RIPE Region transit ASes present in the Internet Routing Table: 486 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 88288514 Equivalent to 5 /8s, 67 /16s and 45 /24s Percentage of available RIPE address space announced: 75.2 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 RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 3301 403 308 TeliaNet Sweden 702 352 462 UUNET Technologies, Inc. 1270 337 433 UUNET Germany 1257 318 256 Swipnet AB 3215 201 181 RAIN 719 192 154 LANLINK 5515 188 342 Sonera Finland 786 181 959 JANET IP Service 1849 179 290 PIPEX 3320 167 462 Deutsche Telekom AG 680 157 806 Deutschef Forschurgsnetz 1942 141 53 INRIA-Rocquencourt 517 136 137 Xlink 2856 135 392 BTnet UK Regional network 3303 126 277 Swisscom 3259 112 88 UUNET, a MCI Worldc 5400 107 31 Concert Internet Plus Europea 1901 105 77 EUnet Austria 1267 96 986 IUnet S.p.A 3269 88 242 TELECOM ITALIA Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2610 3547 UUNET Technologies, Inc. 1221 2302 1189 Telstra 1 1017 4595 BBN Planet 7018 897 3029 AT&T 1239 699 1645 Sprint ICM-Inria 8013 699 70 PSINet Ltd. Canada 7046 691 521 UUNET Technologies, Inc. 2914 640 1291 Verio, Inc. 174 616 2807 PSINet Inc. 2548 615 566 Digital Express Group, Inc. 705 576 36 UUNET Technologies, Inc. 3561 573 1293 Cable & Wireless USA 2551 555 347 NETCOM On-Line Communication 6082 543 66 Management Analysis, Incorpor 3549 511 435 Frontier GlobalCenter 3908 452 281 Supernet, Inc. 2764 439 128 connect.com.au pty ltd 3602 434 79 Sprint Canada 209 431 569 Qwest 4293 430 55 Cable & Wireless USA 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, 65500 PRIVATE 203.166.86.0/24 10084 Western Australian I 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, 65003 PRIVATE 207.167.70.0/24 7837 zNET 65003 PRIVATE 207.167.76.0/24 7837 zNET 65003 PRIVATE 207.167.96.0/23 7837 zNET 65003 PRIVATE 216.9.32.0/21 7837 zNET 65003 PRIVATE 216.9.33.0/24 7837 zNET 65003 PRIVATE 216.9.36.0/24 7837 zNET Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 91.16.23.0/24 11770 Net56 Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:23 /9:4 /10:5 /11:10 /12:31 /13:59 /14:192 /15:302 /16:6758 /17:1015 /18:2002 /19:6251 /20:4392 /21:4294 /22:6423 /23:8368 /24:57983 /25:298 /26:471 /27:155 /28:121 /29:123 /30:280 /31:0 /32:152 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:2 12:307 15:1 20:1 24:641 26:1 32:7 38:9 44:2 53:2 55:1 57:9 61:62 62:104 63:1532 64:1123 65:20 66:54 91:1 128:32 129:189 130:19 131:31 132:9 133:3 134:94 135:7 136:122 137:78 138:189 139:55 140:292 141:19 142:51 143:35 144:95 145:14 146:129 147:89 148:118 149:105 150:22 151:333 152:995 153:120 154:237 155:61 156:14 157:103 158:55 159:46 160:18 161:54 162:63 163:124 164:111 165:97 166:175 167:74 168:72 169:30 170:187 171:2 192:5366 193:1817 194:1993 195:817 196:354 198:3758 199:3429 200:1749 202:2481 203:5172 204:3536 205:2515 206:2849 207:2955 208:2839 209:3407 210:372 211:121 212:763 213:319 214:8 215:11 216:2622 217:83 End of report

1 0

RE: Loop in AS macro
by Lu, Ping 11 Jan '01

11 Jan '01

Hi, I am new to this list and would like to ask a (maybe stupid) question to the dicussion: If we want to write a script to expand the AS MACRO, how can we avoid to go into a loop if multiple AS-MACROs reference each other ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: 703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Cengiz Alaettinoglu [mailto:cengiz@packetdesign.com] > Sent: Wednesday, January 10, 2001 12:14 PM > To: Shane Kerr > Cc: Wilfried Woeber, UniVie/ACOnet; farrache(a)cc.in2p3.fr; > db-wg(a)ripe.net; routing-wg(a)ripe.net; Henk.Uijterwaal(a)ripe.net > Subject: RE: Loop in AS macro > > > > Shane Kerr (shane(a)ripe.net) on January 10: > > Gilles, Wilfried, and all, > > > > This is not a bug, or even an inconsistency. Consider the following > > as-macro objects: > > > > as-macro: AS-X > > members: AS-Y, AS123 > > > > as-macro: AS-Y > > members: AS-X, AS456, AS789 > > > > In this case, AS-X and AS-Y both expand to the same aut-num objects: > > AS123, AS456, and AS789. However, they may have different > maintainers, > > contacts, descriptions, and so on. In RPSL, many more > kinds of loops are > > possible as well, in as-set, route-set, and filter-set objects. > > RPSL defines semantics when loops exist. However, it does not promote > them, or prohibit additional restrictions by the registry operators > not to have loops. > > > > > External software that deals with the set objects needs to do loop > > detection in order to prevent infinite loops. For as-set > objects (which > > are as-macro objects in RIPE-181), this is fairly easy: > keep a list or > > hash of the AS sets expanded, and don't expand them again. > For route-set > > and filter-set objects it is not quite so easy. If you > need help with > > these, you can send me and e-mail and I can explain the > techniques that > > I've used for these objects. > > > > Shane Kerr <shane(a)ripe.net> > > Database Software Engineer > > RIPE NCC > > +31 20 535 4427 > > > > p.s. This is actually a feature, not an bug. :) > > > > p.p.s. It has been argued (by me) that RPSL allows objects that are > > logically impossible, but the RFC authors don't seem to think so! > > > > On Wed, 10 Jan 2001, Wilfried Woeber, UniVie/ACOnet wrote: > > > > > Hi Gilles, > > > > > > I guess we wouldn't be able to check against those > accidents at the time > > > of a DB _update_... > > > > > > But checking the RR internal _data_ consistency could > maybe become part > > > of the RIS (or similar) project? > > > > > > Henk, any comments? > > > > > > An interesting aside: I guess similar problems could occur with > > > RPSL-based RRs? > > > > > > -WW > > > > _________________________________:____________________________ > _________ > > > Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at > > > UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 > > > Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 > > > A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP > keyID 0xF0ACB369 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~ > > > > > > To: staff(a)ip.tele.dk, peering(a)tli.de, ip-oper(a)tli.de, > admin-c(a)tli.de > > > CC: farrache(a)cc.in2p3.fr, db-wg(a)ripe.net, routing-wg(a)ripe.net > > > Subject: Loop in AS macro > > > Date: Wed, 10 Jan 2001 10:28:15 +0100 > > > From: Gilles Farrache <farrache(a)cc.in2p3.fr> > > > > > > Dear database managers, > > > > > > I notice a loop in the followings AS-MACRO, in fact > AS-TELEDANMARKINTERNATIONAL > > > is calling AS-TLI which is calling AS-TELEDK which is > calling AS-TELEDANMARKINTERNATIONAL. > > > (and all that make that our automatic filter generation > tool fails) > > > > > > Could you correct those macro and will the Ripe database > management provide any > > > control on that kind of loop ? > > > > > > Gilles > > > > > > as-macro: AS-TELEDANMARKINTERNATIONAL > > > descr: Tele Danmark customers outside Denmark > > > as-list: AS1902 AS12461 > > > as-list: AS8881 AS-KOMTEL > > > as-list: AS13194 AS-BITE > > > as-list: AS6709 > > > as-list: AS8650 AS-TLI > > > as-list: AS8542 > > > as-list: AS12294 AS-TSUA AS6807 AS8349 AS12788 > AS12837 AS12872 AS13249 AS15386 AS15497 AS15929 AS16007 > > > as-list: AS12546 > > > as-list: AS15389 > > > tech-c: AS5071-RIPE > > > admin-c: AS5071-RIPE > > > notify: staff(a)ip.tele.dk > > > notify: peering(a)tli.de > > > mnt-by: AS3292-MNT > > > changed: jesper(a)skriver.dk 20001103 > > > changed: toba(a)tdk.dk 20001117 > > > changed: tee(a)tdk.dk 20001123 > > > changed: jesper(a)skriver.dk 20001228 > > > changed: jesper(a)skriver.dk 20010109 > > > source: RIPE > > > > > > as-macro: AS-TLI > > > descr: Talkline GmbH, Internet Division > > > descr: List of ASes according to Talkline Internet (AS8650) > > > descr: and customers > > > as-list: AS5605 > > > as-list: AS6783 > > > as-list: AS8650 > > > as-list: AS8881 > > > as-list: AS12461 > > > as-list: AS12546 > > > as-list: AS-TELEDK > > > as-list: AS-GLOBAL > > > tech-c: TLIP1-RIPE > > > admin-c: TLIP1-RIPE > > > notify: peering(a)tli.de > > > mnt-by: TALKLINE-MNT > > > changed: thomas(a)tli.de 19990923 > > > changed: thomas(a)tli.de 19991020 > > > changed: thomas(a)tli.de 19991025 > > > changed: thomas(a)tli.de 20001023 > > > changed: thomas(a)tli.de 20001025 > > > source: RIPE > > > > > > as-macro: AS-TELEDK > > > descr: Tele Danmark and Tele Danmark customers > > > as-list: AS-TELEDANMARKDANISH > > > as-list: AS-TELEDANMARKINTERNATIONAL > > > as-list: AS-BELBONEMEMBERS > > > as-list: AS-GLOBAL > > > tech-c: AS5071-RIPE > > > admin-c: AS5071-RIPE > > > notify: staff(a)ip.tele.dk > > > notify: peering(a)tli.de > > > mnt-by: AS3292-MNT > > > changed: jesper(a)skriver.dk 19990922 > > > changed: jesper(a)skriver.dk 19991019 > > > changed: jesper(a)skriver.dk 19991025 > > > changed: jesper(a)skriver.dk 19991210 > > > changed: toba(a)tdk.dk 20000903 > > > source: RIPE > > > > -------------------------------------------------------------- > ------------------ > > > > > > > > > > Cengiz > > -- > Cengiz Alaettinoglu Packet Design Inc. > >

4 3

RE: Loop in AS macro
by Wilfried Woeber, UniVie/ACOnet 10 Jan '01

10 Jan '01

Hi Gilles, I guess we wouldn't be able to check against those accidents at the time of a DB _update_... But checking the RR internal _data_ consistency could maybe become part of the RIS (or similar) project? Henk, any comments? An interesting aside: I guess similar problems could occur with RPSL-based RRs? -WW _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To: staff(a)ip.tele.dk, peering(a)tli.de, ip-oper(a)tli.de, admin-c(a)tli.de CC: farrache(a)cc.in2p3.fr, db-wg(a)ripe.net, routing-wg(a)ripe.net Subject: Loop in AS macro Date: Wed, 10 Jan 2001 10:28:15 +0100 From: Gilles Farrache <farrache(a)cc.in2p3.fr> Dear database managers, I notice a loop in the followings AS-MACRO, in fact AS-TELEDANMARKINTERNATIONAL is calling AS-TLI which is calling AS-TELEDK which is calling AS-TELEDANMARKINTERNATIONAL. (and all that make that our automatic filter generation tool fails) Could you correct those macro and will the Ripe database management provide any control on that kind of loop ? Gilles as-macro: AS-TELEDANMARKINTERNATIONAL descr: Tele Danmark customers outside Denmark as-list: AS1902 AS12461 as-list: AS8881 AS-KOMTEL as-list: AS13194 AS-BITE as-list: AS6709 as-list: AS8650 AS-TLI as-list: AS8542 as-list: AS12294 AS-TSUA AS6807 AS8349 AS12788 AS12837 AS12872 AS13249 AS15386 AS15497 AS15929 AS16007 as-list: AS12546 as-list: AS15389 tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff(a)ip.tele.dk notify: peering(a)tli.de mnt-by: AS3292-MNT changed: jesper(a)skriver.dk 20001103 changed: toba(a)tdk.dk 20001117 changed: tee(a)tdk.dk 20001123 changed: jesper(a)skriver.dk 20001228 changed: jesper(a)skriver.dk 20010109 source: RIPE as-macro: AS-TLI descr: Talkline GmbH, Internet Division descr: List of ASes according to Talkline Internet (AS8650) descr: and customers as-list: AS5605 as-list: AS6783 as-list: AS8650 as-list: AS8881 as-list: AS12461 as-list: AS12546 as-list: AS-TELEDK as-list: AS-GLOBAL tech-c: TLIP1-RIPE admin-c: TLIP1-RIPE notify: peering(a)tli.de mnt-by: TALKLINE-MNT changed: thomas(a)tli.de 19990923 changed: thomas(a)tli.de 19991020 changed: thomas(a)tli.de 19991025 changed: thomas(a)tli.de 20001023 changed: thomas(a)tli.de 20001025 source: RIPE as-macro: AS-TELEDK descr: Tele Danmark and Tele Danmark customers as-list: AS-TELEDANMARKDANISH as-list: AS-TELEDANMARKINTERNATIONAL as-list: AS-BELBONEMEMBERS as-list: AS-GLOBAL tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff(a)ip.tele.dk notify: peering(a)tli.de mnt-by: AS3292-MNT changed: jesper(a)skriver.dk 19990922 changed: jesper(a)skriver.dk 19991019 changed: jesper(a)skriver.dk 19991025 changed: jesper(a)skriver.dk 19991210 changed: toba(a)tdk.dk 20000903 source: RIPE --------------------------------------------------------------------------------

6 6