RIPE NCC Region Weekly Routing Report
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@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@cisco.com>. Europe, Middle East, North Africa Report 08 Dec, 2000 Analysis Summary ---------------- BGP routing table entries examined: 98964 Origin ASes present in the Internet Routing Table: 9338 Origin ASes announcing only one prefix: 3296 Transit ASes present in the Internet Routing Table: 1253 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: 15 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 4 Number of addresses announced to Internet: 1219031583 Equivalent to 72 /8s, 168 /16s and 242 /24s Percentage of available address space announced: 32.9 Percentage of allocated address space announced: 64.5 Percentage of available address space allocated: 51.0 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 14906 Prefixes being announced from the RIPE address blocks: 11770 RIPE Region origin ASes present in the Internet Routing Table: 2544 RIPE Region origin ASes announcing only one prefix: 1257 RIPE Region transit ASes present in the Internet Routing Table: 468 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 102428390 Equivalent to 6 /8s, 26 /16s and 238 /24s Percentage of available RIPE address space announced: 87.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 395 307 TeliaNet Sweden 1257 336 258 Swipnet AB 702 305 426 UUNET Technologies, Inc. 1270 273 410 UUNET Germany 1849 208 316 PIPEX 719 190 154 LANLINK 3215 187 181 RAIN 5515 185 334 Sonera Finland 786 181 959 JANET IP Service 3320 159 457 Deutsche Telekom AG 1942 139 53 INRIA-Rocquencourt 517 138 146 Xlink 2856 132 384 BTnet UK Regional network 680 131 612 Deutschef Forschurgsnetz 3303 125 277 Swisscom 2609 120 8 EUnet-TN 1275 106 535 DFN IP Service 1901 104 77 EUnet Austria 1267 97 987 IUnet S.p.A 1939 93 35 INRIA-Rocquencourt Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2525 3469 UUNET Technologies, Inc. 1221 2162 1191 Telstra 9768 1433 75 Korea Telecom 705 1199 55 UUNET Technologies, Inc. 1 1009 4555 BBN Planet 7018 896 3025 AT&T 1239 728 1629 Sprint ICM-Inria 7046 681 514 UUNET Technologies, Inc. 2914 662 1275 Verio, Inc. 2548 636 564 Digital Express Group, Inc. 174 603 2773 PSINet Inc. 209 564 566 Qwest 3561 561 1368 Cable & Wireless USA 6082 538 66 Management Analysis, Incorpor 3549 503 418 Frontier GlobalCenter 2563 477 64 Seoul National University 3908 457 289 Supernet, Inc. 271 442 312 BCnet Backbone 3602 437 80 Sprint Canada 4293 430 54 Cable & Wireless USA List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 65501 PRIVATE 64.21.103.0/24 16890 Network Services, In 64800 PRIVATE 64.78.130.128/25 5705 Sirius Solutions, In 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 1880 Stupi, house man's 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 1880 Stupi, house man's 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 64512 PRIVATE 202.61.84.0/24 4743 IPhil Communications 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 50.0.0.0/8 9487 Handong University 91.16.23.0/24 11770 Net56 105.200.136.0/30 9768 Korea Telecom 219.219.219.0/24 2563 Seoul National University 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:9 /12:32 /13:57 /14:188 /15:293 /16:6749 /17:991 /18:1965 /19:6157 /20:4221 /21:4153 /22:6266 /23:8278 /24:57118 /25:563 /26:953 /27:379 /28:152 /29:149 /30:156 /31:0 /32:103 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:2 12:301 15:1 24:607 26:1 32:7 38:7 44:2 53:2 55:1 57:9 61:59 62:97 63:2158 64:999 65:7 66:44 91:1 128:19 129:163 130:16 131:30 132:9 133:3 134:76 135:1 136:51 137:78 138:174 139:45 140:107 141:17 142:46 143:36 144:89 145:12 146:126 147:58 148:110 149:109 150:23 151:250 152:989 153:32 154:47 155:60 156:13 157:94 158:49 159:46 160:18 161:53 162:63 163:123 164:94 165:94 166:166 167:74 168:56 169:29 170:178 171:2 192:5326 193:1897 194:2008 195:856 196:361 198:3664 199:3413 200:1705 202:2516 203:5312 204:3507 205:2392 206:2730 207:2684 208:2759 209:3269 210:677 211:188 212:704 213:256 214:6 215:11 216:2582 217:61 219:1 End of report
* Routing Analysis (cscora@dev.apnic.net) [001207 19:04]:
Number of /24s announced per /8 block (Global) ----------------------------------------------
9:2 12:301 15:1 24:607 26:1 32:7 38:7 44:2 53:2 55:1 57:9 61:59 62:97 63:2158 64:999 65:7 66:44 91:1 128:19 129:163 130:16 131:30 132:9 133:3 134:76 135:1 136:51 137:78 138:174 139:45 140:107 141:17 142:46 143:36 144:89 145:12 146:126 147:58 148:110 149:109 150:23 151:250 152:989 153:32 154:47 155:60 156:13 157:94 158:49 159:46 160:18 161:53 162:63 163:123 164:94 165:94 166:166 167:74 168:56 169:29 170:178 171:2 192:5326 193:1897 194:2008 195:856 196:361 198:3664 199:3413 200:1705 202:2516 203:5312 204:3507 205:2392 206:2730 207:2684 208:2759 209:3269 210:677 211:188 212:704 213:256 214:6 215:11 216:2582 217:61 219:1
There's one /24 in 219/8 space? Although, it doesn't seem to be announced. According to the list of RIRs on the APNIC's website, 219/8 is IANA-Reserved. ana. -- ~ ~ Oh hello, Mr. Soul, I dropped by to pick up a reason; ~ NY
There's one /24 in 219/8 space? Although, it doesn't seem to be announced.
According to the list of RIRs on the APNIC's website, 219/8 is IANA-Reserved.
Looks like someone definitely put a wrong object in the db: inetnum: 219.3.97.0 - 219.3.97.255 netname: FE-NET descr: Future Electronics Ltd descr: Zaporizhzya, Ukraine country: UA admin-c: AE1363-RIPE admin-c: SB187-RIPE tech-c: IF388-RIPE rev-srv: ns.fe-club.net rev-srv: ns2.trifle.net status: ASSIGNED PA notify: hostmaster@trifle.net changed: hostmaster@trifle.net 19990913 source: RIPE Well, he is indeed not announcing that one and there is no route-object either so why don't you ripe-ncc people not just go ahead and remove it? ;-) Regards, Sascha --- Sascha E. Pollok Internet Port Hamburg Technical Manager / Network Operations Grosse Reichenstrasse 27 D-20457 Hamburg Germany Tel.�� +49 (0)40 37 49 19-0 Fax��� +49 (0)40 37 49 19-29 Email: sp@iphh.net ICQ #38955239
At 02:32 11/12/00 +0100, Ana Susanj wrote:
216:2582 217:61 219:1
There's one /24 in 219/8 space? Although, it doesn't seem to be announced.
According to the list of RIRs on the APNIC's website, 219/8 is IANA-Reserved.
Well, Korea National University have decided to announce 219.219.219.0/24 and inspite of me sending them e-mail, they still are. Ofcourse, I really don't understand why their upstream provider(s) is accepting this garbage from them. cheers, philip --
At 12/12/00 04:11 AM +1000, Philip Smith wrote:
At 02:32 11/12/00 +0100, Ana Susanj wrote:
216:2582 217:61 219:1
There's one /24 in 219/8 space? Although, it doesn't seem to be announced.
According to the list of RIRs on the APNIC's website, 219/8 is IANA-Reserved.
Well, Korea National University have decided to announce 219.219.219.0/24 and inspite of me sending them e-mail, they still are. Ofcourse, I really don't understand why their upstream provider(s) is accepting this garbage from them.
A good motivation for such an action is the exchange of money. These's policy, desired policy and commerce. The most harmonious outcomes are when these things coincide. What you are seeing in this case is either a misunderstanding, or a deliberate outcome of a commercial transaction. The former can be fixed by bring it to the attention of the parties involved. The latter has no such form of solution. kind regards, Geoff
We should ask their upstream provider why they are accepting this prefix! Soltani, Abi (AS2563) and Sprintlink (AS1239) xxxxxx#sh ip bgp 219.219.219.0 BGP routing table entry for 219.219.219.0/24, version 60351890 Paths: (4 available, best #2) Advertised to non peer-group peers: 212.38.194.14 212.38.194.66 212.38.194.82 212.117.65.190 1239 2563, (received & used) 144.232.228.5 (metric 68096) from 172.24.248.73 (212.38.195.68) Origin IGP, metric 62, localpref 150, valid, internal Community: 8938:2400 Originator: 212.38.195.68, Cluster list: 0.0.28.105 1239 2563, (received & used) 144.232.228.5 (metric 68096) from 172.24.248.72 (212.38.195.68) Origin IGP, metric 62, localpref 150, valid, internal, best Community: 8938:2400 Originator: 212.38.195.68, Cluster list: 0.0.28.105 cheers, Mike
Well, Korea National University have decided to announce 219.219.219.0/24 and inspite of me sending them e-mail, they still are. Ofcourse, I really don't understand why their upstream provider(s) is accepting this garbage from them.
A good motivation for such an action is the exchange of money.
These's policy, desired policy and commerce.
The most harmonious outcomes are when these things coincide.
What you are seeing in this case is either a misunderstanding, or a deliberate outcome of a commercial transaction. The former can be fixed by bring it to the attention of the parties involved. The latter has no such form of solution.
kind regards,
Geoff
******************************************************************** Mike Portworsnick
On Mon, Dec 11, 2000 at 09:37:13PM +0100, Mike Portworsnick wrote:
We should ask their upstream provider why they are accepting this prefix!
Soltani, Abi (AS2563) and Sprintlink (AS1239)
sh ip bgp reg 2563$ way too many prefixes, and a lot of them can be aggregated. ;) I've noticed this behavior with sprint/as1239, qwest/as209, and few other major carriers, as soon as their customer is gone 20+ prefixes they just stop maintain ACLs/prefix-lists for them... :| -- Basil Kruglov [BK252-ARIN] Network Engineering and Security CIFNet, Inc.
On Mon, Dec 11, 2000 at 09:37:13PM +0100, Mike Portworsnick wrote:
We should ask their upstream provider why they are accepting this prefix! Soltani, Abi (AS2563) and Sprintlink (AS1239)
sh ip bgp reg 2563$
way too many prefixes, and a lot of them can be aggregated. ;) I've noticed this behavior with sprint/as1239, qwest/as209, and few other major carriers, as soon as their customer is gone 20+ prefixes they just stop maintain ACLs/prefix-lists for them... :|
is there any possibility than ripe may do some suggestions to customers about correct those agregations and give some pressions for that...
-- Basil Kruglov [BK252-ARIN] Network Engineering and Security CIFNet, Inc.
-- Regards, Adam Obszy�ski ATM Inc. +48-22-5156418
At 08:59 AM 12/12/00, Adam Obszynski wrote:
is there any possibility than ripe may do some suggestions to customers about correct those agregations and give some pressions for that...
RIPE can only sugest to people to behave like good citizens, explaining the reasons for it from the community perspective and also tell them why their mileage may vary anyways. There is no way RIPE or the RIPE NCC can pressure ISPs to change their behavior. They only way to improve this is for their peers/upstreams to put pressure on, either by talking or by charging for announcements. Daniel
On 2000-12-13T00:46:02, Daniel Karrenberg <Daniel.Karrenberg@ripe.net> said:
RIPE can only sugest to people to behave like good citizens, explaining the reasons for it from the community perspective and also tell them why their mileage may vary anyways. There is no way RIPE or the RIPE NCC can pressure ISPs to change their behavior.
"Bad" behaviour could result in the assignment window being lowered, future allocations being delayed, RIPE NCC could suggest to relevant upstreams that the downstream be filtered (or see figure 1)... Sincerely, Lars Marowsky-Brie <lmb@suse.de> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl
On Wed, 13 Dec 2000, Lars Marowsky-Bree wrote:
On 2000-12-13T00:46:02, Daniel Karrenberg <Daniel.Karrenberg@ripe.net> said:
RIPE can only sugest to people to behave like good citizens, explaining the reasons for it from the community perspective and also tell them why their mileage may vary anyways. There is no way RIPE or the RIPE NCC can pressure ISPs to change their behavior.
"Bad" behaviour could result in the assignment window being lowered, future allocations being delayed, RIPE NCC could suggest to relevant upstreams that the downstream be filtered (or see figure 1)...
But this would still be the RIPE NCC acting as regulator, exactly what Daniel believes we should avoid. To add to that, you've also suggested the NCC should behave like some sort of child-minder dealing with naughty children, by rationing sweeties. Punitive measures are just counter-productive. Encouraging and teaching responsibility/cluefulness in this area is the way to go - and the RIPE (as a body, not the NCC) could help to do this by bringing up route filtering as part of the Routing-WG, and/or running some sort of workshop on "Being a good peer" as far as filtering goes. Mike -- Mike Hughes Network Architect London Internet Exchange mike@linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1"
On Wed, 13 Dec 2000, Daniel Karrenberg wrote:
At 08:59 AM 12/12/00, Adam Obszynski wrote:
is there any possibility than ripe may do some suggestions to customers about correct those agregations and give some pressions for that...
RIPE can only sugest to people to behave like good citizens, explaining the reasons for it from the community perspective and also tell them why their mileage may vary anyways. There is no way RIPE or the RIPE NCC can pressure ISPs to change their behavior.
LIR's sign a contract with RIPE, so they are legaly obliged to obey those terms thay sign up to. I suspect pretty much the same is the case for ARIN and APNIC customers. Apart from the legal route it's technicaly possible for ripe stop delegateing reverse dns, and to remove all of an LIR objects from the ripe database. Disclamer: i don;t work for ripe, this list is just what i could think up... -- Internet Vision Internet Consultancy Tel: 020 7589 4500 60 Albert Court & Web development Fax: 020 7589 4522 Prince Consort Road vision@ivision.co.uk London SW7 2BE http://www.ivision.co.uk/
Lars, Adam, Jasper, ... this discussion is taking a *very dangerous* turn. The RIPE NCC allocates IP address space in its role as a Regional Internet Registry and provides reverse DNS service as part of this. The RIPE NCC does that according to a set of policies developed by the local-ir working group which are aligned globally. The RIPE NCC does not, and in my opinion should never, have *authority* over routing policy set by ISPs or any other operational decision by ISPs for that matter. If one would go down ths route the RIPE NCC would in fact assume some sort of regulatory authority which is a Bad Idea(TM). Do not get me wrong. I agree with your intentions and I can get quite passionate about the strain various combinateions of carelessness, cluelessness and selfishness put on the BGP routing system. Also note that some of this strain comes from people using BGP as a method for traffic engineering in many ways BGP's designers never even had nightmares about. But the particular pressure mechanism you are suggesting is *not appropriate*. The best we can do is bring problems to the attention of those causing the problems and their (routing) peers. If this continues to get worse I expect that ISPs will start charging for announcements or something equivalent and that will produce the back-pressure needed. Again: The RIPE NCC does not, and should not, have this authority. Daniel
I agree with Daniel. It's nothing under the control of the RIPE NCC causing this. It's the community at large. From the routing reports available it's most likely fair to say that the biggest problem is not in the RIPE or ARIN areas anyway. Seans suggestion made at the IEPG in San Diego (for those not there it was basically to start charging per announced route) is tempting but most likely not realistic. However, fact is that it's up to us as a community to let the operators announcing huge amounts of unaggregated or bogus routes that this is wrong and causing a problem. Just as you contact ISP:S abuse contacts or NOC:s for other problems. If enough people show them that we care I am sure they will act (or if you CC their upstream their upstream might care). - kurtis -
Lars, Adam, Jasper, ...
this discussion is taking a *very dangerous* turn. The RIPE NCC allocates IP address space in its role as a Regional Internet Registry and provides reverse DNS service as part of this. The RIPE NCC does that according to a set of policies developed by the local-ir working group which are aligned globally.
The RIPE NCC does not, and in my opinion should never, have *authority* over routing policy set by ISPs or any other operational decision by ISPs for that matter. If one would go down ths route the RIPE NCC would in fact assume some sort of regulatory authority which is a Bad Idea(TM).
Do not get me wrong. I agree with your intentions and I can get quite passionate about the strain various combinateions of carelessness, cluelessness and selfishness put on the BGP routing system. Also note that some of this strain comes from people using BGP as a method for traffic engineering in many ways BGP's designers never even had nightmares about.
But the particular pressure mechanism you are suggesting is *not appropriate*.
The best we can do is bring problems to the attention of those causing the problems and their (routing) peers. If this continues to get worse I expect that ISPs will start charging for announcements or something equivalent and that will produce the back-pressure needed.
Again: The RIPE NCC does not, and should not, have this authority.
Daniel
Kurt Erik Lindqvist Kurtis.Lindqvist@KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm
At 19:02 13/12/00 +0100, Kurt Erik Lindqvist wrote:
I agree with Daniel. It's nothing under the control of the RIPE NCC causing this. It's the community at large. From the routing reports available it's most likely fair to say that the biggest problem is not in the RIPE or ARIN areas anyway.
Likewise I agree, the registries should not be involved in policing the announcements. Definitely a case for industry self control here... One thing that I have on my todo list is to look at the aggregation potential in each registry region. I guess it could take Tony's CIDR report and split it on a per region basis? The biggest problems are from surprising places. Private AS leakage comes mostly from the US, deaggregation comes from every region,... It's usually, but not always limited to newer providers...
Seans suggestion made at the IEPG in San Diego (for those not there it was basically to start charging per announced route) is tempting but most likely not realistic.
I'd be curious to see what happened if someone tried... :-)
However, fact is that it's up to us as a community to let the operators announcing huge amounts of unaggregated or bogus routes that this is wrong and causing a problem. Just as you contact ISP:S abuse contacts or NOC:s for other problems. If enough people show them that we care I am sure they will act (or if you CC their upstream their upstream might care).
I don't think anyone really cares any more. There is enough memory and CPU in the big routers these days, it seems... I could be wrong about both assertions. All this will become a real issue once the number of prefixes being announced becomes a problem for BGP convergence, or storage space on the routers runs out... philip --
One thing that I have on my todo list is to look at the aggregation potential in each registry region. I guess it could take Tony's CIDR report and split it on a per region basis?
It's listed on a per AS basis at http://www.mcvax.org/~jhma/routing/all.html. James, when will the IOS config maker become available? :) (he claims as soon as he has power to his laptop..:) )
The biggest problems are from surprising places. Private AS leakage comes mostly from the US, deaggregation comes from every region,... It's usually, but not always limited to newer providers...
So you mean we need a "aggregation for Newbies"? What might be useful was if RIPE (for an example) at the LIR courses explained the problem.
However, fact is that it's up to us as a community to let the operators announcing huge amounts of unaggregated or bogus routes that this is wrong and causing a problem. Just as you contact ISP:S abuse contacts or NOC:s for other problems. If enough people show them that we care I am sure they will act (or if you CC their upstream their upstream might care).
I don't think anyone really cares any more. There is enough memory and CPU in the big routers these days, it seems... I could be wrong about both assertions.
Well disk space is even cheaper but people still care about SPAM. But I might be wrong too.
All this will become a real issue once the number of prefixes being announced becomes a problem for BGP convergence, or storage space on the routers runs out...
Well, what strikes me is that aggregation keeps popping up at NANOG, RIPE, IETF etc and everyone (more or less) agrees we needs to fix this. Still... I agree we need a bigger carrot (and there is no bigger carrot than money) to achieve this. The question is just how and what? But it's not the registries' job. Maybe we could define Tier-0 ISP:s as upstreams with a aggregation conscious? I doubt that more mailinglists and reports will help. And more meetings with concensus will not add much. Having things automated (a script mailing the corresponding AS) might be one idea, but I agree that more mails will not do it alone. - kurtis - Kurt Erik Lindqvist Kurtis.Lindqvist@KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm
You should not be surprised if you get the answer is "We accept the routes they send us because as a customer of ours they pay us money, and in exchange we carry and advertise the routes they advertise to us". Of course you should not be surprised if you get no answer at all, on the basis that the provider may be of the view that the details of a commercial relationship with a customer are not part of the public domain. Its a tricky problem, and the lack of forcing functions in the routing space is part of the particular characterization of this space. regards, Geoff Huston At 12/11/00 09:37 PM +0100, Mike Portworsnick wrote:
We should ask their upstream provider why they are accepting this prefix!
Soltani, Abi (AS2563) and Sprintlink (AS1239)
xxxxxx#sh ip bgp 219.219.219.0 BGP routing table entry for 219.219.219.0/24, version 60351890 Paths: (4 available, best #2) Advertised to non peer-group peers: 212.38.194.14 212.38.194.66 212.38.194.82 212.117.65.190 1239 2563, (received & used) 144.232.228.5 (metric 68096) from 172.24.248.73 (212.38.195.68) Origin IGP, metric 62, localpref 150, valid, internal Community: 8938:2400 Originator: 212.38.195.68, Cluster list: 0.0.28.105 1239 2563, (received & used) 144.232.228.5 (metric 68096) from 172.24.248.72 (212.38.195.68) Origin IGP, metric 62, localpref 150, valid, internal, best Community: 8938:2400 Originator: 212.38.195.68, Cluster list: 0.0.28.105
cheers, Mike
Well, Korea National University have decided to announce 219.219.219.0/24 and inspite of me sending them e-mail, they still are. Ofcourse, I really don't understand why their upstream provider(s) is accepting this garbage from them.
A good motivation for such an action is the exchange of money.
These's policy, desired policy and commerce.
The most harmonious outcomes are when these things coincide.
What you are seeing in this case is either a misunderstanding, or a deliberate outcome of a commercial transaction. The former can be fixed by bring it to the attention of the parties involved. The latter has no such form of solution.
kind regards,
Geoff
******************************************************************** Mike Portworsnick
participants (13)
-
Adam Obszynski -
Ana Susanj -
Basil Kruglov -
Daniel Karrenberg -
Geoff Huston -
Jasper Wallace -
Kurt Erik Lindqvist -
Lars Marowsky-Bree -
Mike Hughes -
Mike Portworsnick -
Philip Smith -
Routing Analysis -
Sascha E. Pollok