well-known Anycast prefixes
I wonder whether anyone has ever compiled a list of well-known Anycast prefixes. Such as 1.1.1.0/24 8.8.8.0/24 9.9.9.0/24 ... Might be useful for a routing policy such as "always route hot-potato". PS. this mail is not intended to start a flame war of hot vs. cold potato routing. -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 Technoparkstrasse 5 CH-8406 Winterthur Twitter: @init7 / @kuenzler http://www.init7.net/
On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler <kuenzler@init7.net> wrote:
I wonder whether anyone has ever compiled a list of well-known Anycast prefixes.
I don’t know of one. It seems like a good idea. BGP-multi-hop might be a reasonable way to collect them. If others agree that it’s a good idea, and it’s not stepping on anyone’s toes, PCH would be happy to host/coordinate. -Bill
Am 19.03.19 um 18:39 schrieb Bill Woodcock:
On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler <kuenzler@init7.net> wrote: I wonder whether anyone has ever compiled a list of well-known Anycast prefixes.
I don’t know of one.
It seems like a good idea.
BGP-multi-hop might be a reasonable way to collect them.
If others agree that it’s a good idea, and it’s not stepping on anyone’s toes, PCH would be happy to host/coordinate.
Thanks for the effort, much appreciated. Am 19.03.19 um 18:40 schrieb Joe Provo:
I think one would want that internal and no rely upon someone else maintaining it. You might check if Oracle followed up on the Renesys/Dyn work documented: https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf
...where there were ~600 anycast v4 prefixes at the time.
That's a lot %-] Maybe a well-known community (similar to RFC7999) could be defined and every Anycast operator could tag his prefixes? That's likely a better idea than manually maintain some list somewhere. -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 Technoparkstrasse 5 CH-8406 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 / @kuenzler http://www.init7.net/
A Well-known BGP community will be better. You'll need to rewrite next hop or do something similar if AnyCast prefixes are learnt from a multi hop BGP feed, and it made the configuration more complicated and difficult to debug. On Wed, Mar 20, 2019, 01:48 Fredy Kuenzler <kuenzler@init7.net> wrote:
Am 19.03.19 um 18:39 schrieb Bill Woodcock:
On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler <kuenzler@init7.net> wrote: I wonder whether anyone has ever compiled a list of well-known Anycast prefixes.
I don’t know of one.
It seems like a good idea.
BGP-multi-hop might be a reasonable way to collect them.
If others agree that it’s a good idea, and it’s not stepping on anyone’s toes, PCH would be happy to host/coordinate.
Thanks for the effort, much appreciated.
Am 19.03.19 um 18:40 schrieb Joe Provo:
I think one would want that internal and no rely upon someone else maintaining it. You might check if Oracle followed up on the Renesys/Dyn work documented: https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf
...where there were ~600 anycast v4 prefixes at the time.
That's a lot %-]
Maybe a well-known community (similar to RFC7999) could be defined and every Anycast operator could tag his prefixes? That's likely a better idea than manually maintain some list somewhere.
-- Fredy Kuenzler
Init7 (Switzerland) Ltd. AS13030 Technoparkstrasse 5 CH-8406 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 / @kuenzler http://www.init7.net/
Careful thought should be given into whether the BGP community means "this is an anycast prefix" vs "please hot-potato to this prefix". Latency-sensitive applications may prefer hot-potato to their network even if it's not technically an anycast range, as their private backbone may be faster (less congested) than the public internet. Damian On Tue, Mar 19, 2019 at 10:57 AM Siyuan Miao <aveline@misaka.io> wrote:
A Well-known BGP community will be better.
You'll need to rewrite next hop or do something similar if AnyCast prefixes are learnt from a multi hop BGP feed, and it made the configuration more complicated and difficult to debug.
On Wed, Mar 20, 2019, 01:48 Fredy Kuenzler <kuenzler@init7.net> wrote:
Am 19.03.19 um 18:39 schrieb Bill Woodcock:
On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler <kuenzler@init7.net> wrote: I wonder whether anyone has ever compiled a list of well-known Anycast prefixes.
I don’t know of one.
It seems like a good idea.
BGP-multi-hop might be a reasonable way to collect them.
If others agree that it’s a good idea, and it’s not stepping on anyone’s toes, PCH would be happy to host/coordinate.
Thanks for the effort, much appreciated.
Am 19.03.19 um 18:40 schrieb Joe Provo:
I think one would want that internal and no rely upon someone else maintaining it. You might check if Oracle followed up on the Renesys/Dyn work documented: https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf
...where there were ~600 anycast v4 prefixes at the time.
That's a lot %-]
Maybe a well-known community (similar to RFC7999) could be defined and every Anycast operator could tag his prefixes? That's likely a better idea than manually maintain some list somewhere.
-- Fredy Kuenzler
Init7 (Switzerland) Ltd. AS13030 Technoparkstrasse 5 CH-8406 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 / @kuenzler http://www.init7.net/
On Tue, Mar 19, 2019 at 11:52:19AM -0700, Damian Menscher via NANOG wrote:
Careful thought should be given into whether the BGP community means "this is an anycast prefix" vs "please hot-potato to this prefix". Latency-sensitive applications may prefer hot-potato to their network even if it's not technically an anycast range, as their private backbone may be faster (less congested) than the public internet.
To this point, it is pretty clear that any WK community covering this will get [ab]used in a way that the prefix annoucer wishes. We'll then see operators only accepting the WKC if it matches their prefix lists of known entities, getting us back to "hey maybe this should just be a registry I could reference". Woody, maybe generate route-sets to publish in RPSL (RADB?), one per address-family, of observed anycasters? It might be reasonable to do so in a format others can emulate if they wish to create/provide their own lists? Cheers, Joe
Damian
On Tue, Mar 19, 2019 at 10:57 AM Siyuan Miao <aveline@misaka.io> wrote:
A Well-known BGP community will be better.
You'll need to rewrite next hop or do something similar if AnyCast prefixes are learnt from a multi hop BGP feed, and it made the configuration more complicated and difficult to debug.
On Wed, Mar 20, 2019, 01:48 Fredy Kuenzler <kuenzler@init7.net> wrote:
Am 19.03.19 um 18:39 schrieb Bill Woodcock:
On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler <kuenzler@init7.net> wrote: I wonder whether anyone has ever compiled a list of well-known Anycast prefixes.
I don???t know of one.
It seems like a good idea.
BGP-multi-hop might be a reasonable way to collect them.
If others agree that it???s a good idea, and it???s not stepping on anyone???s toes, PCH would be happy to host/coordinate.
Thanks for the effort, much appreciated.
Am 19.03.19 um 18:40 schrieb Joe Provo:
I think one would want that internal and no rely upon someone else maintaining it. You might check if Oracle followed up on the Renesys/Dyn work documented: https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf
...where there were ~600 anycast v4 prefixes at the time.
That's a lot %-]
Maybe a well-known community (similar to RFC7999) could be defined and every Anycast operator could tag his prefixes? That's likely a better idea than manually maintain some list somewhere.
-- Fredy Kuenzler
Init7 (Switzerland) Ltd. AS13030 Technoparkstrasse 5 CH-8406 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 / @kuenzler http://www.init7.net/
-- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling
Hi Fredy, Our anycast prefixes for DNS resolver 185.222.222.0/24 2a09::/48 You can add them if someone will maintain a list. Regards, David -----Original Message----- From: NANOG <nanog-bounces@nanog.org> On Behalf Of Fredy Kuenzler Sent: Wednesday, March 20, 2019 1:13 AM To: nanog@nanog.org Subject: well-known Anycast prefixes I wonder whether anyone has ever compiled a list of well-known Anycast prefixes. Such as 1.1.1.0/24 8.8.8.0/24 9.9.9.0/24 ... Might be useful for a routing policy such as "always route hot-potato". PS. this mail is not intended to start a flame war of hot vs. cold potato routing. -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 Technoparkstrasse 5 CH-8406 Winterthur Twitter: @init7 / @kuenzler http://www.init7.net/
something like this? https://github.com/netravnen/well-known-anycast-prefixes/blob/master/list.tx... PR's and/or suggestions appreciated! (Can be turned into $lirDB friendly format->style RPSL) On 19/03/2019 18:12, Fredy Kuenzler wrote:
I wonder whether anyone has ever compiled a list of well-known Anycast prefixes.
Such as
1.1.1.0/24 8.8.8.0/24 9.9.9.0/24 ...
Might be useful for a routing policy such as "always route hot-potato".
PS. this mail is not intended to start a flame war of hot vs. cold potato routing.
-- Christoffer 0x18DD23C550293098DE07052A9DCF2CA008EBD2E8
On 2019-03-19 21:04, Hansen, Christoffer wrote:
https://github.com/netravnen/well-known-anycast-prefixes/blob/master/list.tx... PR's and/or suggestions appreciated! (Can be turned into $lirDB friendly format->style RPSL)
Most DNS root servers are anycasted. -- Grzegorz Janoszka
On Mar 19, 2019, at 1:11 PM, Grzegorz Janoszka <Grzegorz@Janoszka.pl> wrote:
On 2019-03-19 21:04, Hansen, Christoffer wrote:
https://github.com/netravnen/well-known-anycast-prefixes/blob/master/list.tx... PR's and/or suggestions appreciated! (Can be turned into $lirDB friendly format->style RPSL)
Most DNS root servers are anycasted.
Right, yeah, I think he was just showing an example, since he had roughly a dozen, out of thousands. -Bill
On Mar 19, 2019, at 1:04 PM, Hansen, Christoffer <christoffer@netravnen.de> wrote:
something like this?
https://github.com/netravnen/well-known-anycast-prefixes/blob/master/list.tx...
PR's and/or suggestions appreciated! (Can be turned into $lirDB friendly format->style RPSL)
Generally, static lists like that are difficult to maintain when they’re tracking multiple routes from multiple parties. Communities have been suggested, which works as long as they’re passed through to somewhere people can see. Between PCH, RIS, and Route-Views, most should be visible somewhere, but not all. I think a combination of the two is probably most useful… people tag with a well-known community, then those get eBGP-multi-hopped to a common collector, and published as a clean machine-readable list. -Bill
Hi, On 19/03/2019 23:13, Bill Woodcock wrote:
Generally, static lists like that are difficult to maintain when they’re tracking multiple routes from multiple parties.
agreed. and on the other extreme, communities are very much prone to abuse. I guess I could set any community on a number of prefixes (incl anycast) right now.... So, I think a (moderated) BGP feed of prefixes a'la bogon from a trusted {cymru[1], pch[2], ...} could be good [3]. Frank Habicht 37084 / 33791 if that matters {1] dealing with anycast? [2] biased? [3] speaking as someone not using (subscribing) any of the useful ones, nor contributing to any...
On Mar 19, 2019, at 1:55 PM, Frank Habicht <geier@geier.ne.tz> wrote:
Hi,
On 19/03/2019 23:13, Bill Woodcock wrote:
Generally, static lists like that are difficult to maintain when they’re tracking multiple routes from multiple parties.
agreed. and on the other extreme, communities are very much prone to abuse. I guess I could set any community on a number of prefixes (incl anycast) right now....
So, I think a (moderated) BGP feed of prefixes a'la bogon from a trusted {cymru[1], pch[2], ...} could be good [3].
Ok, so, just trying to flesh out the idea to something that can be usefully implemented… 1) People send an eBGP multi-hop feed of well-known-community routes to a collector, or send them over normal peering sessions to something that aggregates… 2) Because those are over BGP sessions, the counterparty is known, and can be asked for details or clarification by the “moderator,” or the sender could log in to an interface to add notes about the prefixes, as they would in the IXPdir or PeeringDB. 3) Known prefixes from known parties would be passed through in real-time, as they were withdrawn and restored. 4) New prefixes from known parties would be passed through in real-time if they weren’t unusual (large/overlapping something else/previously announced by other ASNs). 5) New prefixes from known parties would be “moderated” if they were unusual. 6) New prefixes from new parties would be “moderated” to establish that they were legit and that there was some documentation explaining what they were. 7) For anyone who really didn’t want to provide a community-tagged BGP feed, a manual submission process would exist. 8) Everything gets published as a real-time eBGP feed. 9) Everything gets published as HTTPS-downloadable JSON. 10) Everything gets published as a human-readable (and crawler-indexable) web page. Does that sound about right? -Bill
Hi, On 20/03/2019 00:03, Bill Woodcock wrote:
Ok, so, just trying to flesh out the idea to something that can be usefully implemented…
1) People send an eBGP multi-hop feed of well-known-community routes to a collector, or send them over normal peering sessions to something that aggregates…
to clarify, eBGP multi-hop sounds good, that can be a dedicated session for this purpose, BGP communities probably don't need to be added. [for the case of 'normal peering sessions', it might seem "wasteful" to use an additional IP on multiple peering LANs] ...
Does that sound about right?
to me yes. Frank
On 3/19/19 5:03 PM, Bill Woodcock wrote:
On Mar 19, 2019, at 1:55 PM, Frank Habicht <geier@geier.ne.tz> wrote:
Hi,
On 19/03/2019 23:13, Bill Woodcock wrote:
Generally, static lists like that are difficult to maintain when they’re tracking multiple routes from multiple parties.
agreed. and on the other extreme, communities are very much prone to abuse. I guess I could set any community on a number of prefixes (incl anycast) right now....
So, I think a (moderated) BGP feed of prefixes a'la bogon from a trusted {cymru[1], pch[2], ...} could be good [3].
Ok, so, just trying to flesh out the idea to something that can be usefully implemented…
1) People send an eBGP multi-hop feed of well-known-community routes to a collector, or send them over normal peering sessions to something that aggregates…
2) Because those are over BGP sessions, the counterparty is known, and can be asked for details or clarification by the “moderator,” or the sender could log in to an interface to add notes about the prefixes, as they would in the IXPdir or PeeringDB.
3) Known prefixes from known parties would be passed through in real-time, as they were withdrawn and restored.
4) New prefixes from known parties would be passed through in real-time if they weren’t unusual (large/overlapping something else/previously announced by other ASNs).
5) New prefixes from known parties would be “moderated” if they were unusual.
6) New prefixes from new parties would be “moderated” to establish that they were legit and that there was some documentation explaining what they were.
7) For anyone who really didn’t want to provide a community-tagged BGP feed, a manual submission process would exist.
8) Everything gets published as a real-time eBGP feed.
9) Everything gets published as HTTPS-downloadable JSON.
10) Everything gets published as a human-readable (and crawler-indexable) web page.
Does that sound about right?
-Bill
Hi, Interesting discussion and ideas. I like how you've laid it out above, Bill. I'm not clear on the use cases, though. What are the imagined use cases? It might make sense to solve 'a method to request hot potato routing' as a separate problem. (Along the lines of Damian's point.) Thanks! James -- James Shank Senior Technical Advisor; Team Cymru, Inc. jshank@cymru.com; +1-847-378-3365; http://www.team-cymru.com/
Hi James, On 20/03/2019 21:05, James Shank wrote:
I'm not clear on the use cases, though. What are the imagined use cases?
It might make sense to solve 'a method to request hot potato routing' as a separate problem. (Along the lines of Damian's point.)
my personal reason/motivation is this: Years ago I noticed that my traffic to the "I" DNS root server was traversing 4 continents. That's from Tanzania, East Africa. Not having a local instance (back then), we naturally sent the traffic to an upstream. That upstream happens to be in that club of those who don't have transit providers (which probably doesn't really matter, but means a "global" network). My Theory : So just because one I-root instance was hosted at a customer (or customer's customer), that got higher local-pref and now packets take the long way from Africa via Europe, NorthAmerica to Asia and that customer in Thailand. While closer I-root instances would obviously be along the way, just not from a paying customer, "only" from peering. I don't know whether or not to blame that "carrier" for intentionally(?) carrying the traffic that far - presumably the $ they got for that from the I-root host in Thailand was worth it, and not enough customers complained enough about the latency? But I think it would be worthwhile to give them an option and produce a mechanism of knowing what's anycasted. Maybe (thinking of it) a solution for really well-known prefixes available at many instances/locations (like DNS root) would be to have their fixed set of direct transits at all the "global" nodes and everywhere else to tell peers to not advertise this to upstreams. Greetings, Frank
On Thu, Mar 21, 2019 at 06:59:18PM +0300, Frank Habicht wrote:
On 20/03/2019 21:05, James Shank wrote:
I'm not clear on the use cases, though. What are the imagined use cases?
It might make sense to solve 'a method to request hot potato routing' as a separate problem. (Along the lines of Damian's point.)
my personal reason/motivation is this: Years ago I noticed that my traffic to the "I" DNS root server was traversing 4 continents. That's from Tanzania, East Africa. Not having a local instance (back then), we naturally sent the traffic to an upstream. That upstream happens to be in that club of those who don't have transit providers (which probably doesn't really matter, but means a "global" network).
Luckily there are other root servers too! :)
My Theory : So just because one I-root instance was hosted at a customer (or customer's customer), that got higher local-pref and now packets take the long way from Africa via Europe, NorthAmerica to Asia and that customer in Thailand. While closer I-root instances would obviously be along the way, just not from a paying customer, "only" from peering.
I don't know whether or not to blame that "carrier" for intentionally(?) carrying the traffic that far - presumably the $ they got for that from the I-root host in Thailand was worth it, and not enough customers complained enough about the latency?
But I think it would be worthwhile to give them an option and produce a mechanism of knowing what's anycasted.
Maybe (thinking of it) a solution for really well-known prefixes available at many instances/locations (like DNS root) would be to have their fixed set of direct transits at all the "global" nodes and everywhere else to tell peers to not advertise this to upstreams.
In all instances of what you mention you need cooperation from the network which is routing in a (from your perspective) suboptimal way. Either the customer of that upstream should use BGP communities to localize the announcement, or the upstream themselves need to change their routing policy to set 'same LOCAL_PREF everywhere' for some prefixes. Of course any input channel into routing policy can be a vector of abuse. Even if you equalize the LOCAL_PREF attribute across your network edge, you still have other tie breakers such as AS_PATH length. It is not clear to me how a list of well-known anycast addresses, in practise, would help swing the pendulum. In all cases you need cooperation from a lot of networks, and the outcome is not clearly defined because we don't have a true inter-domain 'shortest latency path' metric. Kind regards, Job
On 3/21/19 10:59 AM, Frank Habicht wrote:
Hi James,
On 20/03/2019 21:05, James Shank wrote:
I'm not clear on the use cases, though. What are the imagined use cases?
It might make sense to solve 'a method to request hot potato routing' as a separate problem. (Along the lines of Damian's point.)
my personal reason/motivation is this: Years ago I noticed that my traffic to the "I" DNS root server was traversing 4 continents. That's from Tanzania, East Africa. Not having a local instance (back then), we naturally sent the traffic to an upstream. That upstream happens to be in that club of those who don't have transit providers (which probably doesn't really matter, but means a "global" network).
/snip
Greetings, Frank
I can think of another ... We rate-limit DNS from unknown quantities for reasons that should be obvious. We white-list traffic from known trusted (anycast) ones to prevent a DDoS attack from throttling legitimate queries. This would be a useful way to help auto-generate those ACLs.
Not all any-casted prefixes are DNS resolvers and not all DNS resolvers are anycasted. It sounds like you would be better served by a list of well-known DNS resolvers. On Thu, Mar 21, 2019 at 12:35 PM Bryan Holloway <bryan@shout.net> wrote:
On 3/21/19 10:59 AM, Frank Habicht wrote:
Hi James,
On 20/03/2019 21:05, James Shank wrote:
I'm not clear on the use cases, though. What are the imagined use cases?
It might make sense to solve 'a method to request hot potato routing' as a separate problem. (Along the lines of Damian's point.)
my personal reason/motivation is this: Years ago I noticed that my traffic to the "I" DNS root server was traversing 4 continents. That's from Tanzania, East Africa. Not having a local instance (back then), we naturally sent the traffic to an upstream. That upstream happens to be in that club of those who don't have transit providers (which probably doesn't really matter, but means a "global" network).
/snip
Greetings, Frank
I can think of another ...
We rate-limit DNS from unknown quantities for reasons that should be obvious. We white-list traffic from known trusted (anycast) ones to prevent a DDoS attack from throttling legitimate queries. This would be a useful way to help auto-generate those ACLs.
On 3/21/19 11:52 AM, Ross Tajvar wrote:
Not all any-casted prefixes are DNS resolvers and not all DNS resolvers are anycasted. It sounds like you would be better served by a list of well-known DNS resolvers.
True on both counts, and that's why I said "help".
On Thu, Mar 21, 2019 at 12:35 PM Bryan Holloway <bryan@shout.net <mailto:bryan@shout.net>> wrote:
On 3/21/19 10:59 AM, Frank Habicht wrote: > Hi James, > > On 20/03/2019 21:05, James Shank wrote: >> I'm not clear on the use cases, though. What are the imagined use cases? >> >> It might make sense to solve 'a method to request hot potato routing' >> as a separate problem. (Along the lines of Damian's point.) > > my personal reason/motivation is this: > Years ago I noticed that my traffic to the "I" DNS root server was > traversing 4 continents. That's from Tanzania, East Africa. > Not having a local instance (back then), we naturally sent the traffic > to an upstream. That upstream happens to be in that club of those who > don't have transit providers (which probably doesn't really matter, but > means a "global" network).
/snip
> Greetings, > Frank >
I can think of another ...
We rate-limit DNS from unknown quantities for reasons that should be obvious. We white-list traffic from known trusted (anycast) ones to prevent a DDoS attack from throttling legitimate queries. This would be a useful way to help auto-generate those ACLs.
I imagine that the “description” of each entry in the list should include a machine-readable field indicating the use. There was a question about the use-case... I’m sure a lot of people in the ops community have their own reasons related to routing and filtering and so forth, but there’s also a huge demand for this kind of information, aggregated and sanity-checked, to support academic research at the graduate level. And the better we support those kids with real-world data, the more practical an education they receive, and the more ready they are to jump in to jobs we offer them in industry when they graduate. Supporting kids and networking graduate programs like that is a big part of our work, that tends not to be visible on the operations side. Academics downloaded routing-archive snapshots from us nearly 300 million times, last year, for example. -Bill
On Mar 21, 2019, at 09:52, Ross Tajvar <ross@tajvar.io> wrote:
Not all any-casted prefixes are DNS resolvers and not all DNS resolvers are anycasted. It sounds like you would be better served by a list of well-known DNS resolvers.
On Thu, Mar 21, 2019 at 12:35 PM Bryan Holloway <bryan@shout.net> wrote:
On 3/21/19 10:59 AM, Frank Habicht wrote:
Hi James,
On 20/03/2019 21:05, James Shank wrote:
I'm not clear on the use cases, though. What are the imagined use cases?
It might make sense to solve 'a method to request hot potato routing' as a separate problem. (Along the lines of Damian's point.)
my personal reason/motivation is this: Years ago I noticed that my traffic to the "I" DNS root server was traversing 4 continents. That's from Tanzania, East Africa. Not having a local instance (back then), we naturally sent the traffic to an upstream. That upstream happens to be in that club of those who don't have transit providers (which probably doesn't really matter, but means a "global" network).
/snip
Greetings, Frank
I can think of another ...
We rate-limit DNS from unknown quantities for reasons that should be obvious. We white-list traffic from known trusted (anycast) ones to prevent a DDoS attack from throttling legitimate queries. This would be a useful way to help auto-generate those ACLs.
participants (13)
-
Bill Woodcock -
Bryan Holloway -
Damian Menscher -
David Guo -
Frank Habicht -
Fredy Kuenzler -
Grzegorz Janoszka -
Hansen, Christoffer -
James Shank -
Job Snijders -
Joe Provo -
Ross Tajvar -
Siyuan Miao