Error in assignments....?
Uhm, from whois.ra.net : route: 209.81.0.0/19 descr: ViaNet Communications 1235 Pear Ave, Suite 107 Mountain View, CA 94043 origin: AS7091 notify: gshaver@he.net notify: mleber@he.net mnt-by: HE-NOC changed: mleber@he.net 19970808 source: RADB route: 209.81.0.0/19 descr: CRL Network Services Box 326 Larkspur CA 94977, USA origin: AS2041 member-of: RS-COMM_NSFNET mnt-by: MAINT-AS2041 changed: nsfnet-admin@merit.edu 19990223 source: RADB ??? - kurtis -
Kurt Erik Lindqvist wrote:
Uhm, from whois.ra.net :
route: 209.81.0.0/19 origin: AS7091 source: RADB
route: 209.81.0.0/19 origin: AS2041 source: RADB
RADB are a routing registry not an address space registry. Consult ARIN, APNIC, RIPE, etc for IP space ownership details. Any RADB member can register pretty much any route/AS pair and many members don't bother to put real details when it comes to owner of the route, etc (putting the ISP instead of the customer). David. -- David Luyer Phone: +61 3 9674 7525 Network Development Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 1111 BYTE http://www.pacific.net.au/ NASDAQ: PCNTF
RADB are a routing registry not an address space registry. Consult ARIN, APNIC, RIPE, etc for IP space ownership details. Any RADB member can register pretty much any route/AS pair and many members don't bother to put real details when it comes to owner of the route, etc (putting the ISP instead of the customer).
Yes, and this is my point. There is one route with two different sources AS:es... Now, if I where to try and filter on this, I would have a problem....and after all, one of the advantages of a routing registry is that you can filter from it... - kurtis -
In message <17427469.1023807505@LTP012682.kpnqwest.com>, Kurt Erik Lindqvist wr ites:
RADB are a routing registry not an address space registry. Consult ARIN, APNIC, RIPE, etc for IP space ownership details. Any RADB member can register pretty much any route/AS pair and many members don't bother to put real details when it comes to owner of the route, etc (putting the ISP instead of the customer).
Yes, and this is my point. There is one route with two different sources AS:es...
Shit happens.
Now, if I where to try and filter on this, I would have a problem....and after all, one of the advantages of a routing registry is that you can filter from it...
Mirror the information that is relevant to you, and create an exception database. Merge those two, and create your filters from there. Then you can start bugging your peers to update their information. - marcel
On Tue, 11 Jun 2002, Kurt Erik Lindqvist wrote: Hi,
Uhm, from whois.ra.net :
route: 209.81.0.0/19 descr: ViaNet Communications 1235 Pear Ave, Suite 107 Mountain View, CA 94043 origin: AS7091
route: 209.81.0.0/19 descr: CRL Network Services Box 326 Larkspur CA 94977, USA origin: AS2041
A route is something different then an IP assignment/allocation. There can be multipe routes and multiple originating AS's for a netblock. The netblock you are referring to is not globally visible btw. -- Sabri Berisha "I route, therefore you are" ~ my own opinions etc ~ Join Megabit LAN in open air! http://www.megabit.nl
A route is something different then an IP assignment/allocation. There can be multipe routes and multiple originating AS's for a netblock. The netblock you are referring to is not globally visible btw.
Ok, my fault. I ment to say route object. However, I fail to see why (if) you would like to allow the same route to source from muliple AS:es.... Best regards, - kurtis -
On Tue, 11 Jun 2002, Kurt Erik Lindqvist wrote:
A route is something different then an IP assignment/allocation. There can be multipe routes and multiple originating AS's for a netblock. The netblock you are referring to is not globally visible btw.
Ok, my fault. I ment to say route object. However, I fail to see why (if) you would like to allow the same route to source from muliple AS:es....
Why not? Suppose company A has a PA allocation 10.21.0.0/20. Company A gets a T1 from Carrier B. Carrier B announces 10.21.0.0/20 with their AS65531 and statically route the /20 to company A. If Company A wants to be redundant and gets another T1 from Carrier C, Carrier C will announce 10.21.0.0/20 with their AS65532 and statically route 10.21.0.0/20 to Company A. I see no problem in this. If Carrier B screws up, the traffic will still flow through Carrier C. If Carrier B screws up in such a way that they still announce the netspace, Carrier C can announce 2 /21's instead of 1 /20 so it will still work. -- Sabri Berisha "I route, therefore you are" ~ my own opinions etc ~ Join Megabit LAN in open air! http://www.megabit.nl
Ugh, this is why ASN's exist and is why ppl have been posting about inconsistent BGP announcements of late If you originate the same block from 2 ASNs then you no longer have a single administrative area and need a 3rd ASN as per the RFC. Steve On Tue, 11 Jun 2002, Sabri Berisha wrote:
On Tue, 11 Jun 2002, Kurt Erik Lindqvist wrote:
A route is something different then an IP assignment/allocation. There can be multipe routes and multiple originating AS's for a netblock. The netblock you are referring to is not globally visible btw.
Ok, my fault. I ment to say route object. However, I fail to see why (if) you would like to allow the same route to source from muliple AS:es....
Why not?
Suppose company A has a PA allocation 10.21.0.0/20. Company A gets a T1 from Carrier B. Carrier B announces 10.21.0.0/20 with their AS65531 and statically route the /20 to company A. If Company A wants to be redundant and gets another T1 from Carrier C, Carrier C will announce 10.21.0.0/20 with their AS65532 and statically route 10.21.0.0/20 to Company A.
I see no problem in this. If Carrier B screws up, the traffic will still flow through Carrier C. If Carrier B screws up in such a way that they still announce the netspace, Carrier C can announce 2 /21's instead of 1 /20 so it will still work.
On Tue, 11 Jun 2002, Stephen J. Wilcox wrote:
Ugh, this is why ASN's exist and is why ppl have been posting about inconsistent BGP announcements of late
If you originate the same block from 2 ASNs then you no longer have a single administrative area and need a 3rd ASN as per the RFC.
And if your regional registry refuses to assign an ASN you are cooked and you will probably end up using a solution like this. I'm not saying its good, I'm saying its bad, but unfortunately common practice. -- Sabri Berisha "I route, therefore you are" ~ my own opinions etc ~ Join Megabit LAN in open air! http://www.megabit.nl http://www.telegraaf.nl/imail/teksten/imail.lan.staat.party.megabit.html
On Tue, Jun 11, 2002 at 09:06:07PM +0200, Sabri Berisha wrote:
On Tue, 11 Jun 2002, Stephen J. Wilcox wrote:
Ugh, this is why ASN's exist and is why ppl have been posting about inconsistent BGP announcements of late
If you originate the same block from 2 ASNs then you no longer have a single administrative area and need a 3rd ASN as per the RFC.
And if your regional registry refuses to assign an ASN you are cooked and you will probably end up using a solution like this. I'm not saying its good, I'm saying its bad, but unfortunately common practice.
Which RIR is refusing to assign an ASN if you want to multi-home? At least not that one your living in ... Arnold -- Arnold Nipper / nIPper consulting mailto:arnold@nipper.de Hermann-Loens-Weg 15 Phone: +49 700 NIPPER DE D-69207 Sandhausen Mobile: +49 172 2650958 Germany Fax: +49 1212 512364310
On Tue, 11 Jun 2002, Arnold Nipper wrote: Hi,
Which RIR is refusing to assign an ASN if you want to multi-home? At least not that one your living in ...
I'm not bashing RIPE here, I'm just saying that not every PI assigned /24 automagically gets (needs) an ASN. -- Sabri Berisha "I route, therefore you are" ~ my own opinions etc ~ Join Megabit LAN in open air! http://www.megabit.nl http://www.telegraaf.nl/imail/teksten/imail.lan.staat.party.megabit.html
This config can also exist for an interim period whilst a customer is switching providers - hopefully the ex-provider will clean up, but there is nothing now in place to enforce it. Tim -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Sabri Berisha Sent: Tuesday, June 11, 2002 15:06 To: Stephen J. Wilcox Cc: Kurt Erik Lindqvist; nanog@nanog.org Subject: Re: Error in assignments....? On Tue, 11 Jun 2002, Stephen J. Wilcox wrote:
Ugh, this is why ASN's exist and is why ppl have been posting about inconsistent BGP announcements of late
If you originate the same block from 2 ASNs then you no longer have a single administrative area and need a 3rd ASN as per the RFC.
And if your regional registry refuses to assign an ASN you are cooked and you will probably end up using a solution like this. I'm not saying its good, I'm saying its bad, but unfortunately common practice. -- Sabri Berisha "I route, therefore you are" ~ my own opinions etc ~ Join Megabit LAN in open air! http://www.megabit.nl http://www.telegraaf.nl/imail/teksten/imail.lan.staat.party.megabit.html
I'm not familiar with all the RIR policies but RIPE is very straightforward, if you want an ASN you have to be multihomed. I cant see any logic why another RIR would be different in its approach... In my experience its far easier to get an ASN from RIPE than an IP assignment approved. For the latter you need to prove all kinds of things as to why you need it, for an ASN all you have to do is prove you have two upstream ISPs and nothing more! Steve On Tue, 11 Jun 2002, Sabri Berisha wrote:
On Tue, 11 Jun 2002, Stephen J. Wilcox wrote:
Ugh, this is why ASN's exist and is why ppl have been posting about inconsistent BGP announcements of late
If you originate the same block from 2 ASNs then you no longer have a single administrative area and need a 3rd ASN as per the RFC.
And if your regional registry refuses to assign an ASN you are cooked and you will probably end up using a solution like this. I'm not saying its good, I'm saying its bad, but unfortunately common practice.
...exactly. So, again, I can't see a valid reason for a single route to originate from two different AS:es. Unless for transition purposes as was mentioned. - kurtis - --On Tuesday, June 11, 2002 9:58 PM +0100 "Stephen J. Wilcox" <steve@opaltelecom.co.uk> wrote:
I'm not familiar with all the RIR policies but RIPE is very straightforward, if you want an ASN you have to be multihomed. I cant see any logic why another RIR would be different in its approach...
In my experience its far easier to get an ASN from RIPE than an IP assignment approved. For the latter you need to prove all kinds of things as to why you need it, for an ASN all you have to do is prove you have two upstream ISPs and nothing more!
Steve
On Tue, 11 Jun 2002, Sabri Berisha wrote:
On Tue, 11 Jun 2002, Stephen J. Wilcox wrote:
Ugh, this is why ASN's exist and is why ppl have been posting about inconsistent BGP announcements of late
If you originate the same block from 2 ASNs then you no longer have a single administrative area and need a 3rd ASN as per the RFC.
And if your regional registry refuses to assign an ASN you are cooked and you will probably end up using a solution like this. I'm not saying its good, I'm saying its bad, but unfortunately common practice.
On Tue, 11 Jun 2002, Sabri Berisha wrote:
Suppose company A has a PA allocation 10.21.0.0/20. Company A gets a T1 from Carrier B. Carrier B announces 10.21.0.0/20 with their AS65531 and statically route the /20 to company A. If Company A wants to be redundant and gets another T1 from Carrier C, Carrier C will announce 10.21.0.0/20 with their AS65532 and statically route 10.21.0.0/20 to Company A.
I see no problem in this. If Carrier B screws up, the traffic will still flow through Carrier C. If Carrier B screws up in such a way that they still announce the netspace, Carrier C can announce 2 /21's instead of 1 /20 so it will still work.
This isn't being done. Only one AS is announcing the route. The other registration is cruft. Mike. +------------------- H U R R I C A N E - E L E C T R I C -------------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +---------------------------------------------------------------------------+
On Tue, Jun 11, 2002 at 03:00:41PM +0200, Kurt Erik Lindqvist wrote: [snip]
Ok, my fault. I ment to say route object. However, I fail to see why (if) you would like to allow the same route to source from muliple AS:es....
The easy answer is that there is trash in the IRR. When looking a little closer or talking about a well-run source DB consider the consolidation of multiple ASNs, customers getting their BGP training wheels, etc other typical origin changes. To smooth over any origin changes, it makes sense to get route objects in at least a day or two in advance; if you're doing large scale projects long-term overlaps are not at all uncommon. If you think of the IRR as a 'flight plan' or the list of "intended possibilities" then it makes more sense than trying to treat it as a strict tracking of the live BGP table state. The latter would bring you nothing but woe. Cheers, Joe -- Joe Provo Voice 508.486.7471 Director, Internet Planning & Design Fax 508.229.2375 Network Deployment & Management, RCN <joe.provo@rcn.com>
On Tue, 11 Jun 2002, Joe Provo wrote:
On Tue, Jun 11, 2002 at 03:00:41PM +0200, Kurt Erik Lindqvist wrote: [snip]
Ok, my fault. I ment to say route object. However, I fail to see why (if) you would like to allow the same route to source from muliple AS:es....
The easy answer is that there is trash in the IRR.
This is correct.
When looking a little closer or talking about a well-run source DB consider the consolidation of multiple ASNs, customers getting their BGP training wheels, etc other typical origin changes. To smooth over any origin changes, it makes sense to get route objects in at least a day or two in advance; if you're doing large scale projects long-term overlaps are not at all uncommon.
These are operationally valid cases where multiple route objects might exist for a single prefix (as opposed to errors such as left over cruft).
If you think of the IRR as a 'flight plan' or the list of "intended possibilities" then it makes more sense than trying to treat it as a strict tracking of the live BGP table state. The latter would bring you nothing but woe.
Agreed. For good reason you shouldn't be able to delete other networks route objects. Correspondingly it is left to each network to clean up their own registrations. This can be hard when the company in question no longer exists per se. (CRL was acquired by Applied Theory which filed for bankruptcy, whose assets were recently acquired by Fastnet.) The IRRs don't check third party sources for validation of route objects and even if they did the address registries don't map prefixes to AS numbers. This is an interesting subject to think about, however many of the solutions end up being very complicated like S-BGP if they try to address every issue. Mike. +------------------- H U R R I C A N E - E L E C T R I C -------------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +---------------------------------------------------------------------------+
On Tue, 11 Jun 2002, Sabri Berisha wrote:
On Tue, 11 Jun 2002, Kurt Erik Lindqvist wrote:
route: 209.81.0.0/19 origin: AS7091
The netblock you are referring to is not globally visible btw.
Correct, ViaNet is announcing 209.81.0.0/18 now and the 209.81.0.0/19 is an example of that cruft I was talking about that people should clean up. (typing in the background as somebody sends in an update ;) Mike.
On 6/12/02 6:10 PM, "Mike Leber" <mleber@he.net> wrote:
On Tue, 11 Jun 2002, Sabri Berisha wrote:
On Tue, 11 Jun 2002, Kurt Erik Lindqvist wrote:
route: 209.81.0.0/19 origin: AS7091
The netblock you are referring to is not globally visible btw.
Correct, ViaNet is announcing 209.81.0.0/18 now and the 209.81.0.0/19 is an example of that cruft I was talking about that people should clean up.
(typing in the background as somebody sends in an update ;)
Mike.
Even when CRL was alive (not just a zombie) we were never able to get them to clean this up.
At 10:49 PM 6/12/02, joe mcguckin wrote:
On 6/12/02 6:10 PM, "Mike Leber" <mleber@he.net> wrote:
On Tue, 11 Jun 2002, Sabri Berisha wrote:
On Tue, 11 Jun 2002, Kurt Erik Lindqvist wrote:
route: 209.81.0.0/19 origin: AS7091
The netblock you are referring to is not globally visible btw.
Correct, ViaNet is announcing 209.81.0.0/18 now and the 209.81.0.0/19 is an example of that cruft I was talking about that people should clean up.
(typing in the background as somebody sends in an update ;)
Mike.
Even when CRL was alive (not just a zombie) we were never able to get them to clean this up.
I had similar experiences with @Home. Could not get them to pull a record. Couldn't even get to someone with enough clue to know what the RADB was, for that matter. Ultimately, whomever ARIN (or other RIR) says owns a netblock has to have the right to remove crap from the RADB/IRR type databases. That's the only way the data ever has a chance of getting clean. Anyone trying to use such databases to build filters is going to have major trouble. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com
On Wed, 12 Jun 2002, Daniel Senie wrote:
I had similar experiences with @Home. Could not get them to pull a record. Couldn't even get to someone with enough clue to know what the RADB was, for that matter.
Ultimately, whomever ARIN (or other RIR) says owns a netblock has to have the right to remove crap from the RADB/IRR type databases. That's the only way the data ever has a chance of getting clean.
Anyone trying to use such databases to build filters is going to have major trouble.
Hmmm. Since there are approximately 13089 ASes in the global BGP routing table (this number is from Tony Bates Cidr report from June 7th), and if there were duplicate entries for 1 percent of the route objects in the RADB, then it would mean that for the networks that use the RADB to build prefix filters (filter users) inclusive of any route objects found for a particular prefix: * For 99 percent of the prefixes the number of ASes that could announce your route and have it be accepted by filter users would be 1. * For 1 percent of the prefixes the number of ASes that could announce your route and have it be accepted by filter users would be approximately 2. For the networks that don't use the RADB to build prefix filters: * For 100 percent of the prefixes the number of ASes that could announce your route and have it be listened to by some of the other the networks that don't use filters is about 13089. Give or take a few, 13089 is more than 2. Filters are probably good and people that get it working smoothly should probably be admired and copied. Could somebody that has done this comment on how complicated this is to set up? What steps were involved? (perhaps tar xzf filter-builder.tgz; cd filter-builder; make install? :) Mike. +------------------- H U R R I C A N E - E L E C T R I C -------------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +---------------------------------------------------------------------------+
NB: this is neither an endorsement for or against generating policy from databases.
Could somebody that has done this comment on how complicated this is to set up? What steps were involved?
Taking "this" to mean "filter on policy learned from databases," following is a Tcl fragment wrapped around RAToolkit's "peval" that I used to use to query the RADB and build intermediate data from which I would then generate either Cisco prefix lists or Juniper policy statements. The Tcl proc "psort," used to sort a list of prefixes in CIDR notation, is left as an exercise to the reader. proc peval {macro tag allow_incomplete description} { set res [list "$tag\tdescription\t[list $description]"] set incomplete 0 if {[catch {set tmp [exec peval $macro]} why]} { set tmp [lindex [split $why \n] 0] set incomplete 1 } set plist "" if {[regexp {\(\{([^\}]+)\}\)} $tmp junk tmp2]} { set tmp3 [split $tmp2 ,] foreach U [lsort -command psort $tmp3] { lappend res "$tag\tpermit\t[string trim $U]" } } if {[info exists res]} { if {$incomplete && !$allow_incomplete} { return "# [join $res "\n# "]" } else { return "[join $res \n]" } } } The Tcl proc named "peval" takes four arguments: the macro to be evaluated, a tag that I would use later to name the final result, whether an incomplete list of prefixes is permitted, and a description. That third bit, whether an incomplete list of prefixes is permitted, turns out to be an important bit. Some bits of policy refer to other bits of policy, and when bits referenced to not exist peval (the RAToolkit peval, called by Tcl exec) writes them to stderr and causes Tcl to raise an exception. An example (I used to run AS33, and the policy for AS33 doesn't appear to have been changed since I last updated it so I'll take the liberty of picking on it; yes, I know DEC was bought by Compaq and Compaq bought by HP): % source xpeval.tcl % peval as33 33 1 "Digital Equipment Corporation prefixes" 33 description {Digital Equipment Corporation prefixes} 33 permit 16.0.0.0/8 33 permit 128.45.0.0/16 33 permit 130.180.0.0/16 33 permit 198.55.32.0/21 33 permit 198.55.40.0/23 33 permit 199.33.32.0/24 33 permit 199.33.32.0/19 33 permit 199.80.128.0/17 33 permit 204.123.0.0/16 (Goodness, that's a lot of address space, isn't it?) RAToolkit's peval uses rpsl-p.merit.edu as its source of data, and, amusingly, returns data for the macro "AS33," even though the RADB seems to have no AS33 aut-num object. Go figure. Anyways, there was more glue to (a) build vendor-specific configuration language to turn that into a syntactically correct filter for routers (the kind of glue that has to be rewritten every time a new vendor invents a new configuration language), with care taken not to replace a previously-defined filter with no filter should an error be introduced into the RADB, (b) and update the router configs nightly with the new policy. When I ran into the problem of a list of prefixes for one peer being generated that caused the resulting (compressed) configuration to exceed the size of flash memory on my routers, I stopped the cron job and switched all the peers over to "maximum-prefix"-style limits with a standard bogon exclusion filter. It took a couple days to put it together and test it (although I didn't think to test the "list too long" case), and was in production for about a year and a half. The vendors' implementation of maximum prefix limits was not available when I started it, and was available when the "list too long" case cropped up.
On Thu, Jun 13, 2002 at 02:38:12AM -0700, Stephen Stuart wrote:
RAToolkit's peval uses rpsl-p.merit.edu as its source of data, and, amusingly, returns data for the macro "AS33," even though the RADB seems to have no AS33 aut-num object. Go figure.
peval uses the !gas<as#> query to return the prefixes. This will return all registered route: objects for all databases that are being used to respond to queries. These currently seem to be: !s-lc A267 radb,ans,ripe,bell,cw,apnic,verio,i2,arcstar,altdb,sinet,soundinternet,look,dodnic,panix,epoch,rgnet,area151,deru,risq,semaphore,iij,gts,csas,telstra,nestegg,gw,level3,crc,enterzone,kt,alltel,arbor,reach,apirr,spacelink,sakura,aoltw,hs,sprint,openface,wl2k,arin,chtr C -- Jeff Haas NextHop Technologies
209.81.0.0/19 has been announced by AS 7091 from the day it was assigned to them by ARIN back in 1997. The CRL registration possibly predates ViaNet's use as noted by the mention of RS-COMM_NSFNET, and the fact that it was last updated by nsfnet-admin@merit.edu, not CRL. The CRL registration is probably cruft left over from long ago. $ whois 209.81.0.0@whois.arin.net [whois.arin.net] ViaNet Communications (NETBLK-VIANETCO) 1235 Pear Ave, Suite 107 Mountain View, CA 94043 US Netname: VIANETCO Netblock: 209.81.0.0 - 209.81.63.255 Maintainer: VIA Coordinator: Mcguckin, Joseph (JM7712-ARIN) joe@VIA.NET 415 969-2203 (FAX) 415 969-2124 Domain System inverse mapping provided by: NS.VIA.NET 209.81.9.1 NS2.VIA.NET 216.218.130.58 ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE RWHOIS auth.via.net 4321 Record last updated on 22-Mar-2000. Database last updated on 11-Jun-2002 20:00:57 EDT. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and whois.nic.mil for NIPRNET Information. Mike. On Tue, 11 Jun 2002, Kurt Erik Lindqvist wrote:
Uhm, from whois.ra.net :
route: 209.81.0.0/19 descr: ViaNet Communications 1235 Pear Ave, Suite 107 Mountain View, CA 94043 origin: AS7091 notify: gshaver@he.net notify: mleber@he.net mnt-by: HE-NOC changed: mleber@he.net 19970808 source: RADB
route: 209.81.0.0/19 descr: CRL Network Services Box 326 Larkspur CA 94977, USA origin: AS2041 member-of: RS-COMM_NSFNET mnt-by: MAINT-AS2041 changed: nsfnet-admin@merit.edu 19990223 source: RADB
???
- kurtis -
+------------------- H U R R I C A N E - E L E C T R I C -------------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +---------------------------------------------------------------------------+
participants (13)
-
Anne Marcel Roorda -
Arnold Nipper -
Daniel Senie -
David Luyer -
Jeffrey Haas -
joe mcguckin -
Joe Provo -
Kurt Erik Lindqvist -
Mike Leber -
Sabri Berisha -
Stephen J. Wilcox -
Stephen Stuart -
Tim McKee