[jump-admins] Routing problems to www.eurovision.tv 2400:CB00::/32 CLOUDFLARE

[James A. T. Rice]

Terry,

I appreciate your response, but I don't think that's very helpful.

Cloudfare are the ones with the badly engineered v6, not the rest of the 
world. You can take steps to make your v6 work correctly, indeed simply 
aggregating to a /36 or /40 level will likely make your problems go away. 
Otherwise announcing a /32 covering route will definitely make your 
problems go away. If necessary, renumbering into PI space might be the 
long term solution.

A "Either accept the routes or carry a default." stance gets us nowhere - 
there's plenty of reasons, including those I've outlined in my previous 
email, as to why either of those options are a bad idea in the long run.

For everyones sake, I would ask you to reconsider your position on this. 
Other operators have managed to do v6 in a way which does not cause these 
problems. I'm sure you can too.

Best wishes
James



On Fri, 15 Jun 2012, Terry Rodery wrote:

> Either accept the routes or carry a default.
>
> On Fri, Jun 15, 2012 at 10:02 AM, James A. T. Rice <admins at jump.net.uk> wrote:
>> Hi Tom,
>>
>>
>>
>> On Fri, 15 Jun 2012, Tom Paseka wrote:
>>
>>> CloudFlare operates a discontiguous network and we are unable to announce
>>> the /32.
>>
>>
>> route-views shows you using the same upstreams for each /48, in fact, all of
>> the bgp attributes seem identical for each /48 that you announce.
>>
>> There is no reason why you can't announce a /32 to your upstreams, and then
>> steer traffic to your discontiguous sites with /48s (preferably tagged with
>> no-export on the /48s).
>>
>>
>>
>>
>>
>>> The /48 is a valid announcement for the global table.
>>
>>
>> That's bogus. You could say the same that /32 is a valid announcement for
>> IPv4 table. It doesn't help.
>>
>>
>>
>>
>>> While we understand there are some concerns about de-aggergation
>>
>>
>> /48 was designed as the size of an 'end user' assignment, so opening filters
>> to accept /48 across the v6 space is similar to accepting that each end user
>> on the internet can have a place in the global tables. This is clearly not
>> plausible.
>>
>>
>>
>>
>>> aggregation is not possible and we would either be announcing the
>>> deaggregated address space from a single assignment, or we'd have multiple
>>> assignments for the same purpose, so the impact on the routing table would
>>> be the same.
>>
>>
>> Some level of deaggregation can be seen as reasonable, you could announce
>> your /32 as a /36 per site, assuming 16 sites is sufficient and most sites
>> will accept this, or a bunch of /40s if 256 sites is required. Even so
>> announcing the /32 covering route is desirable too.
>>
>> Announcing as /48s is a deaggregation ratio of 65536 times. This is
>> ridiculous. In the same way that you wouldn't try to announce a IPv4 /16 as
>> individual IPv4 /32s (which is exactly the same deaggregation amount that
>> you are doing here).
>>
>>
>>
>>
>>> If the full table can not be accepted, I would recommend installing a
>>> default route to one or all of your upstreams, otherwise many parts of the
>>> global table will not be reachable, not just to CloudFlare.
>>
>>
>> That breaks resilience. Lots of the internet would rather have known
>> resilience and breakage to places announcing incorrectly, rather than rely
>> on defaults.
>>
>>
>> If you need help with fixing this on your side there is plenty of clue on
>> this list. At the moment the ghost route hunter shows you're lacking
>> connectivity to many major sites - if others can get it right I'm sure you
>> can too.
>>
>>
>> Cheers
>> James
>
> _______________________________________________
> admins mailing list
> admins at jump.net.uk
> http://www.jump.org.uk/mailman/listinfo.cgi/admins
>