Weekly Routing Table Report

Sat Aug 31 11:18:55 UTC 2019

> On Aug 31, 2019, at 02:51 , Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp> wrote:
> 
> Owen DeLong wrote:
> 
>> Consider, for example AS7922
> 
> COMCAST is not a good example.

It seemed as good as any… Also, note that many of the Comcast mergers ended up in other
Comcast ASNs, possibly not changing ASNs either?

However, since you don’t like Comcast, let’s try another one that has few (if any) mergers involved:

AS6939 — 125 prefixes...

5.152.177.0/24
5.152.179.0/24
5.152.181.0/24
5.152.182.0/24
5.152.183.0/24
12.177.5.0/24
12.192.16.0/24
12.192.17.0/24
23.142.192.0/24
23.164.160.0/24
23.175.160.0/24
27.50.32.0/21
38.72.144.0/20
38.87.144.0/23
45.33.128.0/22
45.33.132.0/22
45.33.136.0/22
45.33.140.0/24
45.33.140.0/22
45.40.118.0/23
52.129.12.0/23
64.62.128.0/18
64.62.128.0/17
64.71.128.0/18
64.209.56.0/21
64.209.68.0/22
64.214.184.0/21
65.19.128.0/18
65.49.0.0/17
65.49.2.0/24
65.49.14.0/24
65.49.68.0/24
65.49.108.0/22
66.97.177.0/24
66.119.119.0/24
66.160.128.0/18
66.160.192.0/20
66.178.176.0/20
66.207.160.0/20
66.220.0.0/19
67.43.48.0/20
72.14.64.0/24
72.14.65.0/24
72.14.66.0/24
72.14.67.0/24
72.14.89.0/24
72.52.64.0/18
72.52.71.0/24
72.52.92.0/24
74.82.0.0/18
74.82.22.0/23
74.82.46.0/24
74.82.48.0/22
74.116.112.0/22
74.121.104.0/22
74.122.152.0/21
103.6.216.0/22
103.96.214.0/24
103.100.138.0/24
103.193.186.0/23
104.36.120.0/22
104.194.216.0/23
104.247.128.0/22
104.247.132.0/23
104.254.152.0/21
104.255.240.0/21
107.178.32.0/24
107.178.33.0/24
107.178.34.0/23
107.178.36.0/22
107.178.40.0/21
124.252.248.0/21
139.56.8.0/24
139.60.15.0/24
141.193.188.0/23
148.51.0.0/17
161.129.140.0/22
162.213.130.0/24
162.247.12.0/22
162.247.75.0/24
162.249.152.0/23
162.249.154.0/23
167.136.239.0/24
168.245.149.0/24
170.199.208.0/23
173.242.48.0/20
184.75.240.0/21
184.104.0.0/17
184.104.0.0/15
184.104.200.0/21
184.104.208.0/20
184.105.7.0/24
184.105.16.0/20
184.105.32.0/20
184.105.48.0/20
184.105.62.0/24
184.105.88.0/21
184.105.100.0/22
184.105.248.0/21
185.101.97.0/24
185.101.98.0/24
185.114.36.0/24
185.149.69.0/24
185.242.47.0/24
199.164.248.0/23
199.192.144.0/22
204.13.226.0/23
207.126.64.0/19
208.64.56.0/21
208.75.96.0/21
208.79.140.0/22
209.51.160.0/19
209.130.152.0/22
209.135.0.0/19
209.150.160.0/19
216.66.0.0/19
216.66.32.0/19
216.66.64.0/19
216.66.72.0/21
216.66.80.0/20
216.99.220.0/23
216.218.128.0/17
216.224.64.0/21
216.224.64.0/19
216.229.96.0/20

Admittedly some of this appears to be TE routes, but compare with:

2001::/32
2001:470::/32
2001:470:1A::/48
2001:DF2:7900::/48
2001:49E8::/32
2002::/16
2400:7A00::/32
2600:7000::/24
2602:FECA::/36
2602:FF06:725::/48
2604:A100:100::/48
2604:C800:FFFF::/48
2605:4C0::/32
2620:0:50C0::/48
2620:64:6000::/48
2620:138:C001::/48
2620:138:C002::/48
2A03:B2C0::/29
2A06:1C80::/32
2A09:2580::/29
2A09:2780::/29
2A09:3880::/29
2A09:3B80::/29
2A09:3D80::/29
2A09:E500::/29
2A09:F480::/29
2A09:FA80::/29

27 prefixes with most of them being obvious TE or customer carve-outs.

In fact, the first prefix appears to be a bogon from the IANA reserve, so I’m not sure why HE is originating a route for that.

If you still think this isn’t a good example, then pick a decent sized transit AS of your choosing and I’ll run their statistics.

> 
>> but, rather organic customer growth and RIR applications over time.
> 
> No, if you know theory and practice of how additional address ranges
> are allocated as a result of growth, you could have noticed that the
> large number of prefixes of COMCAST should mostly be a result of
> mergers, where merged parts won't renumber their hosts.
> 
>> That’s the kind of prefix growth we should be able to mostly avoid in
>> IPv6 that is rather rampant in IPv4.
> 
> Without automatic renumbering, IPv6 is of no help against mergers.

Merging 10 organizations each of whom have 27 IPv6 prefixes = 270 prefixes.
Merging 10 organizations each of whom have 125 IPv4 prefixes = 1250 prefixes.

IPv6 is of some help even in the case of mergers…

> 
>> Sure, but the number of multi homed sites is way _WAY_ less than the
>> IPv4 routing table size.
> 
> The following page by Geoff Huston is better than your delusion.
> 
> 	http://www.potaroo.net/ispcolumn/2001-03-bgp.html
> 	What is driving this recent change to exponential growth
> 	of the routing table?
> 	In a word, multi-homing.

Yeah, not quite the whole story in that one word… Let’s look at what is driving that increase
in “multihoming”…

While it’s true that cost reduction for circuits has made multihoming more practical, it’s also true
that IPv4 scarcity is driving a lot of this as ISPs are less and less willing to provide free addresses
to customers driving the economics for smaller and smaller customers to get tiny fractions of space
from the remaining limited pools at various RIRs (e.g. ARIN NRPM 4.10 set-aside for v6 transition,
APNIC last /8 policy, RIPE last /8 policy, etc.).

Once you’re getting to the point of BYOA with your ISP, it’s really not much of a farther step to get an
ASN to go with that and turn on BGP.

Geoff’s not entirely wrong about the economics he describes, but he does, IMHO, leave some things
out. For example, he seems to completely ignore (doesn’t even mention) the fact that this latest
exponential expansion also coincides with the rise of the IPv4 transfer markets and the fragmentation
of previously solid large blocks (e.g. MIT’s /8, AMPR selling off a /10 from 44/8, lots of /16s being
sold for /24 pieces, etc.).

> 
>>> With the current routing practice, the number will increase to 14Mwith 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?
> 
> I don't think I must explain the current routing practice here.

You don’t need to explain the current routing practice, but if you want to be taken seriously,
simply assuming that every possible /24 in IPv4 and/or every possible /48 in IPv6 will be
eventually advertised is a case of reductio ad absurdum. I was trying to give you a chance
to provide a better argument for your position.

> 
>>> 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.
> 
> I'm afraid you are not very familiar with semiconductor technology
> trend.

While I appreciate that you enjoy speaking to people in condescending tones, looking at the
history and current trends shows that we are in a period where Moore’s law is leveling off.
We’ve had such periods before and then someone eventually develops something new that
leads to a resumption of the curve.

Past examples have included sub micron technology, the shift from 5v0 to 3v3 and then
later 1v8 core logic, etc.

I stand by my statement. I have no idea what the next breakthrough will be, but I doubt that we
have seen the last breakthrough in computing efficiency.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190831/e9764c51/attachment.html>