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

[Jared Mauch]

I personally agree with James on this topic. The aggregate isn't too hard, or obtaining the right rir space isn't either. 

Jared Mauch

On Jun 15, 2012, at 1:10 PM, "James A. T. Rice" <admins at jump.net.uk> wrote:

> 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
>>