Re: Weekly Routing Table Report

[Owen DeLong <owen () delong com>]

> On Aug 30, 2019, at 20:04 , Masataka Ohta <mohta () necom830 hpcl titech ac jp> wrote:
>
> Patrick W. Gilmore wrote:
>
> > The hope is the v6 DFZ will not grow nearly as fast because of far
> > less fragmentation.
>
> As the problem is caused by multihomed sites (including ISPs), there
> is no such hope.

Part of the problem is caused by multi homed sites. Much more of the problem is actually
caused by organizations needing multiple prefixes acquired over time through IPv4 slow
start and other similar rationing mechanisms deployed to try and create a fair allocation
strategy in light of IPv4 scarcity.

Consider, for example AS7922 which originates the following 124 prefixes according to
route-views:

23.7.80.0/20
23.24.0.0/15
23.30.0.0/15
23.33.186.0/24
23.40.176.0/20
23.41.0.0/20
23.49.56.0/24
23.58.92.0/24
23.67.49.0/24
23.68.0.0/14
23.194.116.0/22
23.213.134.0/23
23.217.129.0/24
24.0.0.0/12
24.16.0.0/13
24.30.0.0/17
24.34.0.0/16
24.40.0.0/18
24.40.64.0/20
24.60.0.0/14
24.91.0.0/16
24.98.0.0/15
24.104.0.0/17
24.104.128.0/19
24.118.0.0/16
24.124.128.0/17
24.125.0.0/16
24.126.0.0/15
24.128.0.0/16
24.129.0.0/17
24.130.0.0/15
24.147.0.0/16
24.153.64.0/19
24.218.0.0/16
24.245.0.0/18
50.73.0.0/16
50.76.0.0/14
50.128.0.0/9
50.227.16.0/22
50.227.20.0/22
64.56.32.0/19
64.139.64.0/19
65.34.128.0/17
65.96.0.0/16
66.30.0.0/15
66.41.0.0/16
66.56.0.0/18
66.176.0.0/15
66.208.192.0/18
66.229.0.0/16
66.240.0.0/18
67.160.0.0/11
68.32.0.0/11
68.80.0.0/13
68.86.80.0/20
69.136.0.0/13
69.180.0.0/15
69.240.0.0/12
70.88.0.0/14
71.24.0.0/14
71.56.0.0/13
71.192.0.0/12
71.224.0.0/12
72.55.0.0/17
72.247.190.0/24
74.16.0.0/12
74.92.0.0/14
74.144.0.0/12
75.64.0.0/13
75.72.0.0/15
75.74.0.0/16
75.75.0.0/17
75.75.128.0/18
75.144.0.0/13
76.16.0.0/12
76.96.0.0/11
76.128.0.0/11
96.6.80.0/20
96.17.145.0/24
96.17.164.0/24
96.17.165.0/24
96.17.166.0/24
96.64.0.0/11
96.96.0.0/12
96.112.0.0/13
96.120.0.0/14
96.124.0.0/16
96.128.0.0/10
96.192.0.0/11
98.32.0.0/11
98.192.0.0/10
104.69.216.0/22
104.69.220.0/23
104.70.48.0/20
104.70.64.0/20
104.70.178.0/24
104.77.121.0/24
104.77.150.0/24
104.109.53.0/24
107.0.0.0/14
107.4.0.0/15
162.148.0.0/14
173.8.0.0/13
173.160.0.0/13
173.222.176.0/22
174.48.0.0/12
174.160.0.0/11
184.25.157.0/24
184.28.64.0/23
184.28.68.0/23
184.28.117.0/24
184.51.52.0/22
184.51.207.0/24
184.86.251.0/24
184.108.0.0/14
184.112.0.0/12
198.0.0.0/16
198.137.252.0/23
198.178.8.0/21
204.11.116.0/22
208.39.128.0/18
209.23.192.0/22
209.23.192.0/18
216.45.128.0/17


A quick scan didn’t reveal significant overlap or even a lot of adjacent prefixes. As such, I don’t think you can blame 
multihoming or TE for this, but, rather organic customer growth and RIR applications over time.

That’s the kind of prefix growth we should be able to mostly avoid in IPv6 that is rather rampant in IPv4.

> With the current way of multihoming to compute available routes to
> multihomed sites by global routing system, the load, including routing
> table size, to the global routing system increases at least linearly
> to the number of multihomed sites.

Sure, but the number of multi homed sites is way _WAY_ less than the IPv4 routing table size.

> Some people was aware of the problem when the size was 50,000.

When the size was 50,000, that was the primary source of the problem. Today, long prefixes issued due to scarcity 
constitute a much larger fraction of the problem than multi homed sites originating single prefixes.

> With the current routing practice, the number will increase to 14M
> with IPv4 and a lot more than that with IPv6.

I’m curious as to why you think that the number is bounded at 14M for IPv4 and why you think there will be so many more 
multi homed sites in IPv6?

> The solution is:
>
>       https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03
>
> but IETF is working on stupid things like LISP only to increase
> load to the global routing system.

Not that you’d be prejudiced in favor of your own draft or anything.

> > Also, even today TCAM ain’t cheap. Let’s hope it those numbers are
> > not "nothing".
>
> The problem is serious especially because Moore's law is ending.

People have been claiming that Moore’s law is at an end longer than we have been pushing for IPv6 deployment.

TCAM ain’t cheap, but it’s also not the only solution to the problem and solutions are getting cheaper (per prefix) 
over time. 

Owen