May 2000 - routing-wg - mailman.ripe.net

RIS
by Jacques Caron 06 Jun '00

06 Jun '00

Hi again, I guess another view might be interesting: have one column per peer (with the ability to select a subset of peers, of course), a line per update, and then in each "cell" the AS path received from that peer (if any). This enables to see which path is adopted by several peers for a multihomed network. Another option would be to be able to give an AS to "grep" into the AS paths, and show which cells contain it or not (or the same thing with several ASes and colored cells). Not sure this is very clear, so I'll give an example. Let's say network N is multihomed to two transit providers AS1 and AS2. Now, I want to see which path is taken from multiple locations to this network. I would input network N, peers A, B, C, D, the two ASes AS1 and AS2 and start/end times. Then it woud output a table with columns A, B C and D, a line per update, and on each line, a different color depending on whether the route received from that peer contains AS1 or AS2 (or both, or none, maybe). Optionally, an additional column giving the proportion of peers using AS1 or AS2 could be interesting. Sounds like a good idea? Jacques. --- Jacques Caron PSINetworks Europe Network Engineer PSINet Europe Regional Peering Coordinator Planete.net IT Manager Mail: 8/10 rue Nieuport - 78140 Velizy - France Phone: +33 (0)1 34 63 19 71 - Fax: +33 (0)1 34 63 19 51

2 1

The Cidr Report
by Tony Bates 26 May '00

26 May '00

This is an auto-generated mail on Fri May 26 12:00:00 PDT 2000 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 26May00 0) General Status Table History ------------- Date Prefixes 080400 75151 090400 75137 100400 75215 110400 75403 120400 75730 130400 75919 010500 76182 020500 76265 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: 5027 Number of ASes announcing only one prefix: 1865 (0 cidr, 1865 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1002 announced by AS701 1) Gains by aggregating at the origin AS level --- 26May00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 437 152 285 65.2% BCnet Backbone AS7046 500 336 164 32.8% COQUI-NET PRTC Internet AS9269 167 29 138 82.6% Hong Kong CTI AS9706 153 26 127 83.0% Pusan Metropolitan City Office of AS1221 529 408 121 22.9% TELSTRA-AS AS2609 123 18 105 85.4% EUnet-TN AS7545 164 66 98 59.8% TPG Internet Pty Ltd AS7657 264 168 96 36.4% The Internet Group Limited AS174 552 464 88 15.9% Performance Systems International AS7496 126 39 87 69.0% Power Up AS9304 109 24 85 78.0% Hutchcity AS9557 100 17 83 83.0% Pakistan Telecommunication Compan AS6429 204 121 83 40.7% RDC-INTERNET AS577 248 172 76 30.6% Bell Backbone AS7029 146 71 75 51.4% ALLTELNET AS209 463 392 71 15.3% Qwest Communications AS7018 529 463 66 12.5% AT&T WorldNet Service Backbone AS1727 162 98 64 39.5% MRMS-WEST AS4293 253 190 63 24.9% Internal ASN for C&W AS724 205 143 62 30.2% DLA-ASNBLOCK-AS AS7260 111 50 61 55.0% NORLIGHT AS705 270 209 61 22.6% ALTERNET-AS AS3749 121 61 60 49.6% TECNET AS3602 307 249 58 18.9% Sprint Canada Inc. AS6595 107 50 57 53.3% DODDSEUR AS4740 336 279 57 17.0% Ozemail Pty Ltd (ASN-OZEMAIL) AS5106 81 29 52 64.2% AADS-COLUMBUS AS7568 63 18 45 71.4% C.S. Communications Co., Ltd. AS816 308 266 42 13.6% UUNET Canada (ASN-UUNETCA-AS4) AS6528 48 6 42 87.5% WORLD-LYNX 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

RIPE NCC Region Weekly Routing Report
by Routing Analysis 25 May '00

25 May '00

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 26 May, 2000 Analysis Summary ---------------- BGP routing table entries examined: 79625 Origin ASes present in the Internet Routing Table: 7527 Origin ASes announcing only one prefix: 2454 Transit ASes present in the Internet Routing Table: 1065 Average AS path length visible in the Internet Routing Table: 5.2 Max AS path length visible: 15 Illegal AS announcements present in the Routing Table: 15 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 5 Number of addresses announced to Internet: 1168086933 Equivalent to 69 /8s, 159 /16s and 151 /24s Percentage of available address space announced: 31.5 Percentage of allocated address space announced: 63.5 Percentage of available address space allocated: 49.6 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 12646 Prefixes being announced from the RIPE address blocks: 9847 RIPE Region origin ASes present in the Internet Routing Table: 2017 RIPE Region origin ASes announcing only one prefix: 952 RIPE Region transit ASes present in the Internet Routing Table: 399 Average RIPE Region AS path length visible: 5.8 Max RIPE Region AS path length visible: 15 Number of RIPE addresses announced to Internet: 70521327 Equivalent to 4 /8s, 52 /16s and 17 /24s Percentage of available RIPE address space announced: 70.1 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 and 212/7 RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 3301 373 272 TeliaNet Sweden 1257 330 267 Swipnet AB 1270 253 410 UUNET Germany 1849 238 492 PIPEX 1275 235 1132 DFN IP Service 786 181 959 JANET IP Service 719 179 145 LANLINK 517 163 201 Xlink 5515 159 338 Sonera Finland 3320 147 277 Deutsche Telekom AG 2609 127 4 EUnet-TN 2856 125 271 BTnet UK Regional network 3303 123 295 Swisscom 2874 122 85 Global One Services 1267 109 819 IUnet S.p.A 3215 97 124 RAIN 9057 93 29 Level 3 public IP n 1901 89 74 EUnet Austria 1290 85 195 PSINet UK Ltd. Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 1969 3240 UUNET Technologies, Inc. 7018 1039 3010 AT&T 1221 884 986 Telstra 1 879 4616 BBN Planet 7046 826 472 UUNET Technologies, Inc. 2914 732 1232 Verio, Inc. 1239 724 1631 Sprint ICM-Inria 3561 710 1630 Cable & Wireless USA 209 655 704 Qwest 174 651 2850 PSINet Inc. 705 580 35 UUNET Technologies, Inc. 271 469 411 BCnet Backbone 2764 459 113 connect.com.au pty ltd 3549 437 341 Frontier GlobalCenter 3602 434 77 Sprint Canada 1740 404 626 CERFnet 4740 398 83 Ozemail 3301 373 272 TeliaNet Sweden 4293 373 68 Cable & Wireless USA List of Illegal AS's (Global) ----------------------------- Bad AS Designation Network Transit AS Description 65530 PRIVATE 63.179.128.0/24 4999 Sprint 65530 PRIVATE 63.179.134.0/24 4999 Sprint 65530 PRIVATE 63.179.142.0/24 4999 Sprint 65530 PRIVATE 63.179.146.0/24 4999 Sprint 65530 PRIVATE 63.179.148.0/24 4999 Sprint 65530 PRIVATE 63.179.149.0/24 4999 Sprint 65530 PRIVATE 63.179.154.0/24 4999 Sprint 65530 PRIVATE 63.179.158.0/24 4999 Sprint 65530 PRIVATE 63.179.190.0/24 4999 Sprint 65530 PRIVATE 63.179.191.0/24 4999 Sprint 65530 PRIVATE 63.179.249.0/24 4999 Sprint 64602 PRIVATE 63.236.57.0/24 209 Qwest 64601 PRIVATE 63.236.90.0/24 209 Qwest 64605 PRIVATE 208.47.206.0/24 209 Qwest 65014 PRIVATE 208.185.113.0/24 6461 AboveNet Communicati Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 39.96.40.224/30 14408 iCAIR 65.56.64.0/21 2941 Community News Service 109.177.9.0/24 1785 Sprint ICM 219.91.160.0/22 7742 InternetNow, Inc. 219.91.164.0/23 7742 InternetNow, Inc. Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:24 /9:4 /10:5 /11:9 /12:26 /13:48 /14:163 /15:275 /16:6458 /17:831 /18:1644 /19:5290 /20:3119 /21:3364 /22:5036 /23:6838 /24:45871 /25:131 /26:178 /27:71 /28:44 /29:42 /30:89 /31:0 /32:65 End of report

1 0

Top 100 Maintainers List 20000524
by RIPE Database Administration 24 May '00

24 May '00

1 0

Re: About address allocating (IPv6, variable length SLA/prefixes?)
by Ole Troan 22 May '00

22 May '00

> Architecturally, IPv6 has the equivalent of variable length subnet masks > built in. There are really only two boundaries that are not flexible- > the boundary between the format prefix and the rest of the address, and the > /64 boundary. (The format prefix is in fact variable length, but it is > architecturally defined.) So any IGP or EGP design needs to be fully flexible > to the left of /64. Subnetting to the right of /64 would be tricky. all IGP's and EGP's have to support all prefix-lengths. e.g you want to announce host routes, /96 for NAT-PT, etc. for that matter, the implementation(s) I know will let you create subnets of whatever size you like. /ot

3 3

Re: About address allocating (IPv6, variable length SLA/prefixes?)
by Wilfried Woeber, UniVie/ACOnet 22 May '00

22 May '00

Hi Francis et.al., as I said a couple of days ago in Budapest, I would like to see an explanation and/or review from the routing point of view. Judging from my (limited) knowledge about IPv6, going for a variable length SLA field would either leave us with "wasted" address space (as the network next door would be a different site and thus should have a different NLA field anyway), or we would end up with a variable length network prefix length (much like in the v4 environment), effectively extending the NLA field into the SLA field. Doing so would probably require a cross-check against existing IPv6-aware IGPs. That is where I would like to see input from the routing camp(s). Regards, Wilfried. ______________________________________________________________________ From: Francis Dupont <Francis.Dupont(a)enst-bretagne.fr> To: itojun(a)iijlab.net CC: Haisang Wu <hswu(a)ns.6test.edu.cn>, 6bone(a)ISI.EDU Subject: Re: About address allocating Date: Sat, 20 May 2000 15:17:57 +0200 In your previous mail you wrote: > hi, I have the following questions about address allocating: > I know SLA is /48, and interface ID should be 64 bits, > does it mean that the smallest unit when allocating address is /48? > In other words, if I allocate a /48 to a large university, could I > allocate a /48 to four middle schools, thus each middle school gets > an block less than /48, which is /50. Is this plan reasonable? > >=> we'd like to get a /48, ISPs would like to give a /64 to us: > - /48 seems a bit too large for a default allocation size > - /64 is unusable when you need subneting >then the current idea, as presented yesterday here in Budapest >at the RIPE meeting, is to introduce "small site" which get >/56 (on byte boundary, large enough for up to 256 subnetworks or >a few levels of hierarchy). >Then /56 will become the default allocation size in RIR >allocation & assignment document. I'm not sure if introducing "small sites" is a good thing... when we switch ISP and they force me to switch from /48 to /56, renumber becomes very hard. => the idea is that it is easier for someone which needs a /48 to deal with its ISP than for a common customer to fight in order to get a /48 because /64 is not enough: this is a compromise for common customers (ie you at home, IIJlab is strong enough to get a /x with x <= 48). I believe it is a good compromise... Regards Francis.Dupont(a)enst-bretagne.fr -------------------------------------------------------------------------------- _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 2

The Cidr Report
by Tony Bates 19 May '00

19 May '00

This is an auto-generated mail on Fri May 19 12:00:00 PDT 2000 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 19May00 0) General Status Table History ------------- Date Prefixes 080400 75151 090400 75137 100400 75215 110400 75403 120400 75730 130400 75919 010500 76182 020500 76265 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: 5027 Number of ASes announcing only one prefix: 1865 (0 cidr, 1865 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1002 announced by AS701 1) Gains by aggregating at the origin AS level --- 19May00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 437 152 285 65.2% BCnet Backbone AS7046 500 336 164 32.8% COQUI-NET PRTC Internet AS9269 167 29 138 82.6% Hong Kong CTI AS9706 153 26 127 83.0% Pusan Metropolitan City Office of AS1221 529 408 121 22.9% TELSTRA-AS AS2609 123 18 105 85.4% EUnet-TN AS7545 164 66 98 59.8% TPG Internet Pty Ltd AS7657 264 168 96 36.4% The Internet Group Limited AS174 552 464 88 15.9% Performance Systems International AS7496 126 39 87 69.0% Power Up AS9304 109 24 85 78.0% Hutchcity AS9557 100 17 83 83.0% Pakistan Telecommunication Compan AS6429 204 121 83 40.7% RDC-INTERNET AS577 248 172 76 30.6% Bell Backbone AS7029 146 71 75 51.4% UNKNOWN AS209 463 392 71 15.3% Qwest Communications AS7018 529 463 66 12.5% AT&T WorldNet Service Backbone AS1727 162 98 64 39.5% MRMS-WEST AS4293 253 190 63 24.9% Internal ASN for C&W AS724 205 143 62 30.2% UNKNOWN AS7260 111 50 61 55.0% NORLIGHT AS705 270 209 61 22.6% UNKNOWN AS3749 121 61 60 49.6% TECNET AS3602 307 249 58 18.9% Sprint Canada Inc. AS6595 107 50 57 53.3% UNKNOWN AS4740 336 279 57 17.0% Ozemail Pty Ltd (ASN-OZEMAIL) AS5106 81 29 52 64.2% UNKNOWN AS7568 63 18 45 71.4% C.S. Communications Co., Ltd. AS816 308 266 42 13.6% UUNET Canada (ASN-UUNETCA-AS4) AS6528 48 6 42 87.5% WORLD-LYNX 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

RIPE NCC Region Weekly Routing Report
by Routing Analysis 18 May '00

18 May '00

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 May, 2000 Analysis Summary ---------------- BGP routing table entries examined: 79251 Origin ASes present in the Internet Routing Table: 7499 Origin ASes announcing only one prefix: 2440 Transit ASes present in the Internet Routing Table: 1055 Average AS path length visible in the Internet Routing Table: 5.2 Max AS path length visible: 15 Illegal AS announcements present in the Routing Table: 13 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 5 Number of addresses announced to Internet: 1158544884 Equivalent to 69 /8s, 13 /16s and 253 /24s Percentage of available address space announced: 31.3 Percentage of allocated address space announced: 63.0 Percentage of available address space allocated: 49.6 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 12587 Prefixes being announced from the RIPE address blocks: 9767 RIPE Region origin ASes present in the Internet Routing Table: 2010 RIPE Region origin ASes announcing only one prefix: 948 RIPE Region transit ASes present in the Internet Routing Table: 389 Average RIPE Region AS path length visible: 5.8 Max RIPE Region AS path length visible: 15 Number of RIPE addresses announced to Internet: 70101705 Equivalent to 4 /8s, 45 /16s and 170 /24s Percentage of available RIPE address space announced: 69.6 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 and 212/7 RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 3301 380 272 TeliaNet Sweden 1257 330 267 Swipnet AB 1270 257 410 UUNET Germany 1849 239 492 PIPEX 1275 234 1148 DFN IP Service 786 181 959 JANET IP Service 719 179 145 LANLINK 517 163 201 Xlink 5515 162 331 Sonera Finland 3320 155 277 Deutsche Telekom AG 2609 126 4 EUnet-TN 3303 125 295 Swisscom 2856 123 270 BTnet UK Regional network 1267 109 819 IUnet S.p.A 3215 95 120 RAIN 9057 91 26 Level 3 public IP n 1901 88 74 EUnet Austria 1290 84 195 PSINet UK Ltd. 8895 80 28 Saudi Arabia AS Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 1907 3278 UUNET Technologies, Inc. 7018 1033 3028 AT&T 1221 881 978 Telstra 1 876 4624 BBN Planet 7046 817 472 UUNET Technologies, Inc. 2914 732 1240 Verio, Inc. 1239 712 1631 Sprint ICM-Inria 3561 692 1601 Cable & Wireless USA 209 642 702 Qwest 174 617 2809 PSINet Inc. 705 491 25 UUNET Technologies, Inc. 271 469 411 BCnet Backbone 2764 457 113 connect.com.au pty ltd 3549 437 341 Frontier GlobalCenter 3602 432 77 Sprint Canada 1785 403 840 Sprint ICM 1740 401 625 CERFnet 4740 399 83 Ozemail 2907 380 917 SINET Japan List of Illegal AS's (Global) ----------------------------- Bad AS Designation Network Transit AS Description 65530 PRIVATE 63.179.128.0/24 4999 Sprint 65530 PRIVATE 63.179.134.0/24 4999 Sprint 65530 PRIVATE 63.179.142.0/24 4999 Sprint 65530 PRIVATE 63.179.146.0/24 4999 Sprint 65530 PRIVATE 63.179.148.0/24 4999 Sprint 65530 PRIVATE 63.179.149.0/24 4999 Sprint 65530 PRIVATE 63.179.154.0/24 4999 Sprint 65530 PRIVATE 63.179.190.0/24 4999 Sprint 65530 PRIVATE 63.179.191.0/24 4999 Sprint 65530 PRIVATE 63.179.230.0/24 4999 Sprint 65530 PRIVATE 63.179.249.0/24 4999 Sprint 64602 PRIVATE 63.236.57.0/24 209 Qwest 64601 PRIVATE 63.236.90.0/24 209 Qwest Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 39.96.40.224/30 14408 iCAIR 67.167.108.0/24 1239 Sprint ICM-Inria 109.177.9.0/24 1785 Sprint ICM 219.91.160.0/22 7742 InternetNow, Inc. 219.91.164.0/23 7742 InternetNow, Inc. 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:5 /10:5 /11:9 /12:26 /13:49 /14:162 /15:279 /16:6447 /17:819 /18:1630 /19:5255 /20:3070 /21:3365 /22:5003 /23:6766 /24:45714 /25:130 /26:178 /27:68 /28:43 /29:52 /30:89 /31:0 /32:64 End of report

1 0

Routing WG session starts at 4:00pm
by SchmitzJo＠aol.com 17 May '00

17 May '00

Dear colleagues, due to cancellations of a few presentations, we will only need one slot for the Routing WG session this time. In order to avoid overlap with the IPv6 WG session, we will drop the first slot (2pm - 3:30pm), and will start only after the coffee break at 4pm, meaning this time we will only use the second late slot (4pm - 5:30pm). Apologies for the late notice. Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

draft minutes RIPE 35 Routing WG session
by SchmitzJo＠aol.com 17 May '00

17 May '00

Minutes Routing-wg @ RIPE 35 Chair : Joachim Schmitz (JS395-RIPE) Scribe : Emil Gorter (EMIL-RIPE) Attenders: 92 A. Preliminaries (Joachim Schmitz) Joachim welcomed the participants, passed around the participants' list, and asked for a volunteer scribe. Emil Gorter volunteered to take the minutes. The working group agreed upon the minutes of the previous meeting, and accepted the agenda circulated earlier on the mailing list. Review of previous actions: o 31.R1 RIPE NCC, D.Kessens, J.Schmitz Basic design for an IPv6 IRR -postponed- Even though this topic is still considered important, there had been not enough input to continue o 32.R1 RIPE NCC, JLS.Damas Prepare draft document on RIPE-181 -> RPSL transition issues -in progress- The draft document is prepared, but not yet publicly available o 34.R1 C.Panigl Provide updates to RIPE-178 -to be closed- Needs to be published B. Report from the RIPE NCC (JLS Damas) The report consisted of two parts: - transition to RPSL - consistency checking of the IRR which were discussed in a combined presentation - Transition to RPSL RPSL will be implemented in the RIPE database software v3.0 which is nearly complete and beta code is available for downloading. The new db can be tested at reimp.ripe.net:43 It will accept no updates, only queries on an almost real time mirror of the current database. It will be tested for 2 months (already started), so testers are welcome to try. Any RPSL object stored in the test database will not be mirrored back into the RIPE-181 production database. Thus, we are still in step one of a three step process: 1. Mirror current db in RPSL 2. Accept updates in RPSL and RIPE-181, RIPE-181 will be converted to RPSL 3. Only accept updates in RPSL For details more information may be found at www.ripe.net/ripencc/pub-services/db/reimp/index.html If there are concerns about the procedures, RIPE NCC would appreciate input to be incorporated in the reimplementation document (action 32.R1). The question arose what happens with any RPSL update done today. They are definitely not visible on the current database. However, it is obvious that during the transition process any test objects in the RPSL part must not be moved into the new RPSL production database. - Consistency Checking of the IRR The goal of the project is to compare BGP data from life Internet to routing information stored in the RIPE IRR, and analyze the results. The input gathered so far will be incorporated in a draft document. This document is expected to become available around RIPE 36. However, it is important to note that the reimplementation effort and the transition to RPSL is run at a higher priority, and this project will only be worked on fully after the reimplementation has been finished. C. RADB/IRRd Update (Gerald Winters) http://www.ripe.net/ripe/meetings/archive/ripe-35/presentations/ripe35-radb… /index.html Gerald gave an overview of the topics presented - recent developments - IRRj - scaling issues - on the horizon which were then discussed in detail. * Recent developments Probably the most important item with regard to the database was that Merit/RADB converted to RPSL which was completed in Nov-99. For two months, in parallel any RIPE-181 updates would overwrite existing RPSL objects. On 1-Jan-2000, RIPE-181 was discontinued, meaning that RADB is now fully and only accepting RPSL. The experience with RPSL is that most users are satisfied, but only very few users actually make use of advanced RPSL features. In a whole it seems that the community still becomes used to RPSL. The second very important topic relates to the organizational structure of RADB. In the past it has been fully subsidized by Merit. Now, Merit is completing the transition to a commercial funding model, which charges a yearly fee to all maintainers registered in RADB. The consequence is that maintainers who do not pay the yearly fee, in the end may be removed from RADB, including all their objects. However, RADB is important, and nobody shall be excluded. People, who do not want to pay fees are therefore encouraged by Merit to open and run their own registries, which is supported by Merit to publish the code of the db software. There is already some interest for this, and Merit will then mirror those who request it. Actually, Merit expects to reduce its role as a database administrator. This statement caused a lot of discussion. Concerns uttered covered - do ISPs need to register in all databases? the answer is no - "private" registries will be mirrored at RADB - how to avoid duplicates then, or correct references (Christian Panigl) this is likely to be a problem; there are some measures taken or under consideration. Merit will definitely start removing old duplicates themselves. It is strongly recommended that when a company starts its own mirrored registry, they should remove their object from RADB. - the existence of duplicates actually is not a new problem, but it will be more difficult to handle if the number of registries explodes? in principle this could be solved by prioritizing registries, which may be difficult thinking of which criteria to use. Therefore, clear criteria must be defined for the "private" registries where to query, and what to store - while prioritization probably solves the question of retrieving data, it does not solve the question of consistency; does the IRR consistency project help here? probably yes, at least as a supportive action; however, getting registry data is also a matter of completeness - who is allowed to open a registry, and who is then allowed to insert, delete, manipulate copies of objects in which registry? in principle, any body may open a registry; however, ownership of objects should not change in this process (AS, route objects). Actually, nobody should be allowed to delete or work on these objects. This may really become a problem if upstream providers decide to set up their own registries, even more for multihomed services. This would require multiple registrations, not necessarily transparent for downstreams. The general feeling was that this development should be very closely observed. - is Merit acting here a bit early with RPS Dist not yet in place? actually, we are currently on the move, starting to develop procedures. It is quite obvious, that someone running a registry being disjoint from the others, the data may not be used for configurations on the Internet, meaning that the corresponding networks will not or will only be reachable partly. This will generate peer pressure to at least mirror each other properly. Nonetheless, at least for small registries, there is a definite need for central support, and most likely also for a resolution authority in cases of dispute. As a general bottom line, it became very much obvious that the Internet is very much differently organized in the US compared to Europe. Much of the problem for Merit is posed by introducing its new funding model, where for RIPE it already exists and is accepted in the community. In the US, the community is much more heterogeneous than in Europe. * Scaling issues Funding is not the only issue, Merit has been working on. The demand of users of the database has risen that much, that scaling has become an issue. The load on the production server has increased that much, that a second one had been introduced, where requests are distributed applying a DNS round robin mechanism. Updates are only done on one machine, requests are handled by both. To handle slow connections, small pipes, or large queries, parts of the software have been adapted to speed up processing. * IRRj A new development is the routing registry tool IRRj, opening another interface to the database. It is programmed in Java, and connection based, in contrast to the usual e-mail interface. It allows fast updates and features a graphical interface, which works more efficiently than updates by e-mail. It is obvious that IRRj can not make use of the "mail from" authentication method, which should be eliminated anyway because it does not supply real authentication (easily forged). The idea is to move to PGP in general. * On the horizon With the projects running and new developments, a list of action items results. Most pressing is an implementation of RPS Dist, allowing distributed databases. Merit is working to get an RPS Dist prototype built which also depends on progress of the corresponding Internet draft. However, it have already been decided that for authentication between the distributed databases, PGP certificates will be used. Another demand from the community is strong authentication/authorization in the database. Accordingly, Merit is considering implementation of the RPS Auth draft. Depending on resources work may commence around mid-summer. Finally, there is some new development on the database software itself. With the help of Global Crossing, a relational database backend is developed, where the TimesTen relational database is used. The work will integrate IRRd in the backend. Resulting code from this project will be open source. The expected advantage of the project consists in higher performance (due to structures intrinsic to the relational database software), allowing relational queries, and better support for the allocation registry functions. D. Routing Information Service Status and Plans (Ripe NCC) Henk Uijterwaal http://www.ripe.net/ripe/meetings/archive/ripe-35/presentations/ripe35-ris-… k/ Details of this report are available at the url specified above. In addition the RIS project has its own web pages at http://www.ripe.net/ripencc/pub-services/np/ris-index.html The goal of RIS is to collect default-free BGP data with timestamps, to give a current and historical view of the Internet routing table. The user interface will have the feel of a looking-glass "with memory". Once deployed, RIS will also be used for consistency checking of the routing registry. The setup consists of major data collectors at major exchange points, which transmit the data to a central collector and database at the RIPE NCC. Since Oct-99 the first test version is in use. However, there are still a few items which need to be taken care of like - open questions in the draft RIS document (RIPE-200) - the hardware for the final setup must still be ordered - consider process of data collection and storage, especially with regard to the high data volume The prototype currently implemented is available at http://abcoude.ripe.net/ris/risalpha.cgi A demonstration was available in the terminal room. The current setup consists of one collector at AMSIX, and one machine for storage and running the database. At AMSIX, currently 12 peering relationships are active. Data volume collected is around 40 MBytes per peer and per day. The total peering relationships are probably going to be increased to around 70. Collected are BGP IPv4 announcements and withdrawals with all BGP attributes. The collector sends updates to the central collector daily - this frequency may be increased in the future. Some results derived so far show - there is a very high number of updates per day, which seems to indicate a high level of instability; however at the same time the number of withdrawals is very low - the more peers we are looking at, the more prefixes are visible which is interesting because we expect that some upper limit of prefixes should be reached relatively fast (the full Internet routing table); since they do not appear on the Internet routing table, these addtl prefixes are called "dark prefixes"; the question is whether this effect results just from more specifics being visible which are otherwise simply aggregated - this statement is supported by the finding that more than 50% of the prefixes are /24 Besides these statistics, RIS will enable to find out who routes what when. On top of this, flap-statistics may be generated. Suggestions on additional usage is very much welcome from the audience. The development is on schedule, a demo is available. Plans are built on the actions indicated above, comprising implementation details, and including more peerings. The basic question in the end how to turn this into a regular service will be answered after these preliminaries are resolved. There was input from the audience, that similar things have already been done in other areas of the world (e.g. a project at Merit). Results and experience will be shared. With these presentations the first slot of the meeting was closed. E. Multicast Routing The second slot of the Routing WG meeting was dedicated to Multicast Routing, more precisely to show how providers have deployed it or are planning to do it. This includes both backbone and Internet service providers, and public exchange points. Not all of the presentations are available yet, but will become available on the RIPE NCC web server soon. * Reports from Backbones There are two prominent pan-European backbone providers: TEN-155 for the education/research community, and the commercial Ebone network. For both the current status, experience, and some plans were presented. The TEN-155 multicast setup was presented by Jan Nowak. Due to the different demands, levels of development, or specific implementations, the network structure is highly heterogeneous. Quite a lot of problems result from this. It was also recognized that some elements of multicast are very sensitive to frame/cell/packet loss (depending on the under lying carrier protocol). In contrast, Peter Lothberg showed that Ebone is using native multicast (avoiding any tunnels), only employing sparse mode, avoiding MHRSP which removes problems like ghosting issues. MSDP is very much favored. The result is a very clearly structured homogeneous network, which is easy to manage and configure. The design includes backup scenarios with redundant RPs to circumvent router failures. * Reports from Public Exchange Points Peter Lothberg immediately continued with his presentation on multicast routing on the Stockholm DGIX. He gave some general design rules, and shared his thoughts and experience. It was interesting to note that DPT rings based on dark fiber are used for both unicast and multicast. Niels den Otter followed with his presentation on the plans, AMSIX has to add multicast (Amsterdam Internet Exchange). They are still in the planning phase. According to Steve Walker, the LINX (London Internet Exchange) is already a step further down the road: even though they are still in the developing phase, they already have a testbed running with several multicast feeds. On the one hand, more multicast feeds are expected, and the LINX wants to switch to production sometime during year 2000. It is interesting to note that both AMSIX and LINX are deploying multicast on separate hardware, keeping it away from their unicast exchange infrastructure. However, on the Stockholm DGIX unicast and multicast are run on a common shared infrastructure. * Reports from Active ISP Networks Originally, there were reports planned from three networks. Unfortunately, Peter Heiligers on very short notice could not join the meeting, and thus the report from DFN was dropped. The two remaining reports from Renater by Bernard Tuy and on Surfnet by Niels den Otter showed the same situation like described for the backbone networks. Renater has started relatively early with the French Multicast Backbone (FMbone), and thus for historical reasons there are still various protocols in use, and the network has been running on dense mode. When the network grew, configuration with all the filters required became just too complex. Therefore, Renater is now moving to sparse mode, and will reduce the number of protocols used in their network. Surfnet has also tested a few protocols, but for final implemenation is adopting a model similar to Ebone, with PIM sparse mode throughout, MSDP with backup RPs etc. The Surfnet multicast backbone will be congruent to the unicast network, using the same routers. Y. General I/O with other WGs There has been no immediate I/O with other WGs. Z. AOB There was no AOB for this working group session. Joachim announced that there will be held a multicast tutorial during the next RIPE meeting in Budapest. --- Agenda ------ R I P E 3 5 A M S T E R D A M Routing Working Group Session 24-February-2000 Draft Agenda A. Preliminaries (Joachim Schmitz) (5min) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 34 minutes - actions from earlier meetings B. Report from the RIPE NCC (JLS Damas) - transition to RPSL (15min) - consistency checking of the IRR (5min) C. Report on the IRR at RADB (Gerald Winters) (20min) D. Report on RIS (RIPE NCC) (20min) E. Multicast Routing - reports from backbones * TEN-155 * Ebone - reports from exchange points (15min each) * Stockholm D-GIX * AMS-IX * LINX - reports from active networks (15min each) * Renater * DFN (skipped) * SURFnet Y. General I/O with Other WGs Z. AOB Summary of open Action Points ----------------------------- 31.R1 on RIPE NCC, D.Kessens, J.Schmitz Basic design for an IPv6 IRR - postponed - 32.R1 on RIPE NCC, JLS.Damas Prepare draft document on issues of RIPE-181 to RPSL transition - in progress - 34.R1 on C.Panigl Provide update to RIPE-178 - in progress - Emil Gorter, Joachim Schmitz, May-2000

1 0