Mailing List Archive

The hope is the v6 DFZ will not grow nearly as fast because of far less fragmentation.

But who knows?

Also, even today TCAM ain’t cheap. Let’s hope it those numbers are not “nothing”.

--
TTFN,
patrick

> On Aug 30, 2019, at 4:33 PM, Romeo Czumbil <Romeo.Czumbil@tierpoint.com <mailto:Romeo.Czumbil@tierpoint.com>> wrote:
>
> These numbers are nothing. Wait till IPv6 really start taking off.
>
>
> -----Original Message-----
> From: NANOG <nanog-bounces@nanog.org <mailto:nanog-bounces@nanog.org>> On Behalf Of Patrick W. Gilmore
> Sent: Friday, August 30, 2019 3:09 PM
> To: North American Operators' Group <nanog@nanog.org <mailto:nanog@nanog.org>>
> Subject: Re: Weekly Routing Table Report
>
> A very long time ago, I commented on this report hitting 250,000 prefixes. It was a Big F*#@$&! Deal at the time. A quarter million prefixes in the DFZ? Wow….
>
> Then I did it again at 500,000. People commented that I should have waited for 512,000 - especially since a popular piece of kit was expected to fall over at 512K prefixes. But I said I liked round numbers.
>
> This time I waited for 768,000. (Everyone happy now?)
>
> To say “the Internet grew more than anyone expected” is beyond cliché these days, but that does not make it any less true. The Internet has transformed from a curiosity into something my son[*] and a good portion of his entire generation cannot conceive of living without. A great many people on this list had a part in making all that happen.
>
> Stop and think about that for a second. You had a part in literally changing the world.
>
> It is a 3-day weekend in the US. A good time to pause for a few minutes and consider what all of us accomplished together. Pat yourselves on the back, raise a glass or whatever your personal traditions are, and bask in the glory of a job well done.
>
> --
> TTFN,
> patrick
>
> [*] The fact I can say “my son” is probably even more amazing. But that is a different story.
>
>
>> On Aug 30, 2019, at 2:04 PM, Routing Analysis Role Account <cscora@apnic.net <mailto:cscora@apnic.net>> wrote:
>>
>> This is an automated weekly mailing describing the state of the
>> Internet Routing Table as seen from APNIC's router in Japan.
>>
>> The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
>> TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
>>
>> Daily listings are sent to bgp-stats@lists.apnic.net <mailto:bgp-stats@lists.apnic.net>
>>
>> For historical data, please see https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY&e=> .
>>
>> If you have any comments please contact Philip Smith <pfsinoz@gmail.com <mailto:pfsinoz@gmail.com>>.
>>
>> Routing Table Report 04:00 +10GMT Sat 31 Aug, 2019
>>
>> Report Website: https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY&e=>
>> Detailed Analysis:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n <https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n>
>> et_current_&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpk
>> Dj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=
>> 1SzKtCXB1OQXt_kKzDwHmtLE8a44hKEkYUtraUzC3gI&e=
>>
>> Analysis Summary
>> ----------------
>>
>> BGP routing table entries examined: 768323
>> Prefixes after maximum aggregation (per Origin AS): 295832
>> Deaggregation factor: 2.60
>> Unique aggregates announced (without unneeded subnets): 370810
>> Total ASes present in the Internet Routing Table: 65326
>> Prefixes per ASN: 11.76
>> Origin-only ASes present in the Internet Routing Table: 56226
>> Origin ASes announcing only one prefix: 24072
>> Transit ASes present in the Internet Routing Table: 9100
>> Transit-only ASes present in the Internet Routing Table: 269
>> Average AS path length visible in the Internet Routing Table: 4.3
>> Max AS path length visible: 45
>> Max AS path prepend of ASN ( 27978) 31
>> Prefixes from unregistered ASNs in the Routing Table: 27
>> Number of instances of unregistered ASNs: 27
>> Number of 32-bit ASNs allocated by the RIRs: 28444
>> Number of 32-bit ASNs visible in the Routing Table: 23268
>> Prefixes from 32-bit ASNs in the Routing Table: 105688
>> Number of bogon 32-bit ASNs visible in the Routing Table: 14
>> Special use prefixes present in the Routing Table: 0
>> Prefixes being announced from unallocated address space: 288
>> Number of addresses announced to Internet: 2834690304
>> Equivalent to 168 /8s, 245 /16s and 241 /24s
>> Percentage of available address space announced: 76.6
>> Percentage of allocated address space announced: 76.6
>> Percentage of available address space allocated: 100.0
>> Percentage of address space in use by end-sites: 99.3
>> Total number of prefixes smaller than registry allocations: 257215
>>
[…]

It doesn't bode well with deaggregation in IPv6 going down to the /48 in
places I see it happen. A large chunk of the /48s out there are from
/32s. If that carries on, we'll have to be more afraid then I remember
us being at 30k IPv4 prefixes, 100k IPv4 prefixes, etc. :-(

Actually when I started doing this back in early 1999, it was to
supplement with a regional view of what Tony Bates was producing in the
CIDR Report. Sloppy code on my part back then as we didn't have "too
many prefixes". Didn't think I'd be doing this still, and have had to
sort the code many times since too. :-)

philip
--

Patrick W. Gilmore wrote on 31/8/19 06:40 :
> The hope is the v6 DFZ will not grow nearly as fast because of far less
> fragmentation.
>
> But who knows?
>
> Also, even today TCAM ain’t cheap. Let’s hope it those numbers are not
> “nothing”.
>
> -- 
> TTFN,
> patrick
>
>> On Aug 30, 2019, at 4:33 PM, Romeo Czumbil
>> <Romeo.Czumbil@tierpoint.com <mailto:Romeo.Czumbil@tierpoint.com>> wrote:
>>
>> These numbers are nothing. Wait till IPv6 really start taking off.
>>
>>
>> -----Original Message-----
>> From: NANOG <nanog-bounces@nanog.org <mailto:nanog-bounces@nanog.org>>
>> On Behalf Of Patrick W. Gilmore
>> Sent: Friday, August 30, 2019 3:09 PM
>> To: North American Operators' Group <nanog@nanog.org
>> <mailto:nanog@nanog.org>>
>> Subject: Re: Weekly Routing Table Report
>>
>> A very long time ago, I commented on this report hitting 250,000
>> prefixes. It was a Big F*#@$&! Deal at the time. A quarter million
>> prefixes in the DFZ? Wow….
>>
>> Then I did it again at 500,000. People commented that I should have
>> waited for 512,000 - especially since a popular piece of kit was
>> expected to fall over at 512K prefixes. But I said I liked round numbers.
>>
>> This time I waited for 768,000. (Everyone happy now?)
>>
>> To say “the Internet grew more than anyone expected” is beyond cliché
>> these days, but that does not make it any less true. The Internet has
>> transformed from a curiosity into something my son[*] and a good
>> portion of his entire generation cannot conceive of living without. A
>> great many people on this list had a part in making all that happen.
>>
>> Stop and think about that for a second. You had a part in literally
>> changing the world.
>>
>> It is a 3-day weekend in the US. A good time to pause for a few
>> minutes and consider what all of us accomplished together. Pat
>> yourselves on the back, raise a glass or whatever your personal
>> traditions are, and bask in the glory of a job well done.
>>
>> --
>> TTFN,
>> patrick
>>
>> [*] The fact I can say “my son” is probably even more amazing. But
>> that is a different story.
>>
>>
>>> On Aug 30, 2019, at 2:04 PM, Routing Analysis Role Account
>>> <cscora@apnic.net <mailto:cscora@apnic.net>> wrote:
>>>
>>> This is an automated weekly mailing describing the state of the 
>>> Internet Routing Table as seen from APNIC's router in Japan.
>>>
>>> The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG 
>>> TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
>>>
>>> Daily listings are sent to bgp-stats@lists.apnic.net
>>> <mailto:bgp-stats@lists.apnic.net>
>>>
>>> For historical data, please
>>> see https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY&e= .
>>>
>>> If you have any comments please contact Philip Smith
>>> <pfsinoz@gmail.com <mailto:pfsinoz@gmail.com>>.
>>>
>>> Routing Table Report   04:00 +10GMT Sat 31 Aug, 2019
>>>
>>> Report Website:
>>>     https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY&e= 
>>> Detailed Analysis:  
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n
>>> et_current_&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpk
>>> Dj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=
>>> 1SzKtCXB1OQXt_kKzDwHmtLE8a44hKEkYUtraUzC3gI&e=
>>>
>>> Analysis Summary
>>> ----------------
>>>
>>> BGP routing table entries examined:                              768323
>>>   Prefixes after maximum aggregation (per Origin AS):          295832
>>>   Deaggregation factor:                                          2.60
>>>   Unique aggregates announced (without unneeded subnets):      370810
>>> Total ASes present in the Internet Routing Table:                 65326
>>>   Prefixes per ASN:                                             11.76
>>> Origin-only ASes present in the Internet Routing Table:           56226
>>> Origin ASes announcing only one prefix:                           24072
>>> Transit ASes present in the Internet Routing Table:                9100
>>> Transit-only ASes present in the Internet Routing Table:            269
>>> Average AS path length visible in the Internet Routing Table:       4.3
>>>   Max AS path length visible:                                      45
>>>   Max AS path prepend of ASN ( 27978)                              31
>>> Prefixes from unregistered ASNs in the Routing Table:                27
>>>   Number of instances of unregistered ASNs:                        27
>>> Number of 32-bit ASNs allocated by the RIRs:                      28444
>>> Number of 32-bit ASNs visible in the Routing Table:               23268
>>> Prefixes from 32-bit ASNs in the Routing Table:                  105688
>>> Number of bogon 32-bit ASNs visible in the Routing Table:            14
>>> Special use prefixes present in the Routing Table:                    0
>>> Prefixes being announced from unallocated address space:            288
>>> Number of addresses announced to Internet:                   2834690304
>>>   Equivalent to 168 /8s, 245 /16s and 241 /24s
>>>   Percentage of available address space announced:               76.6
>>>   Percentage of allocated address space announced:               76.6
>>>   Percentage of available address space allocated:              100.0
>>>   Percentage of address space in use by end-sites:               99.3
>>> Total number of prefixes smaller than registry allocations:      257215
>>>
> […]
>

--- web@typo.org wrote:

"WTF, PEOPLE??? CAN'T ANYONE AGGREGATE ANYMORE???"
---------------------------------------


Is that like the NANOG version of "get off my lawn"? :)

scott
bgp since ~50k

web> "WTF, PEOPLE??? CAN'T ANYONE AGGREGATE ANYMORE???"

surfer> Is that like the NANOG version of "get off my lawn"? :)

Lawns? You had lawns? :)

BGP when under 2k-ish and CLNP for sins in past lives...

On Fri, Aug 30, 2019 at 07:15:17PM -0700, Scott Weeks wrote:
>
>
> --- web@typo.org wrote:
>
> "WTF, PEOPLE??? CAN'T ANYONE AGGREGATE ANYMORE???"
> ---------------------------------------
>
>
> Is that like the NANOG version of "get off my lawn"? :)
>
> scott
> bgp since ~50k

Hah!

"The internet woulda been perfect, if not for those meddling kids!"

---
Wayne Bouchard
web@typo.org
Network Dude
http://www.typo.org/~web/

On Fri, 30 Aug 2019 20:27:10 -0600, Paul Ebersman said:

> BGP when under 2k-ish and CLNP for sins in past lives...

CLNP? Now there's a name I've not heard in a long time...

(Go ahead, admit it, you read that in Alec Guiness's voice :)

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.

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.

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

With the current routing practice, the number will increase to 14M
with IPv4 and a lot more than that with 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.

> Also, even today TCAM ain$B!G(Bt cheap. Let$B!G(Bs hope it those numbers are
> not "nothing".

The problem is serious especially because Moore's law is ending.

Masataka Ohta

> 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

> Sent: Saturday, August 31, 2019 3:50 AM
> To: Paul Ebersman <list-nanog2@dragon.net>
>
> On Fri, 30 Aug 2019 20:27:10 -0600, Paul Ebersman said:
>
> > BGP when under 2k-ish and CLNP for sins in past lives...
>
> CLNP? Now there's a name I've not heard in a long time...
>
> (Go ahead, admit it, you read that in Alec Guiness's voice :)

Ha, since reminiscing, anybody remembers the good old SNA or god forbid SDLC
to mainframes and then rocking it over DLSW?
Oh or here's another one Token-Ring routing anybody?

We came quite a long way from these to current EVPN and SR-TE...

But still I can't shake the feeling that back in the days architects were
somewhat more ingenious coming up with these extraordinary designs to work
around resource or protocol limitations.
Now it's just down to simple slap more cpu/ram/tcam at the problem and
you're done I feel. Nowadays boxes can easily take 5x the current 768 in
tcam and in control-plane -only sky is the limit, so for example there's no
need for any clever RR infrastructure designs anymore to hold all the routes
in your AS control-plane.

adam

Owen DeLong wrote:

> Consider, for example AS7922

COMCAST is not a good example.

> 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$B!G(Bs 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.

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

>> With the current routing practice, the number will increase to 14M
>> with IPv4 and a lot more than that with IPv6.
>
> I$B!G(Bm 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.

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

Masataka Ohta

Masataka Ohta wrote on 31/08/2019 04:04:
> 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.

nothing comes for free. Pushing the complexity down to the host level
is not a "solution", just a workaround with its own set of problems.

Nick

On Sat, 31 Aug 2019 18:51:16 +0900, Masataka Ohta said:
> Owen DeLong wrote:

> >> With the current routing practice, the number will increase to 14M
> >> with IPv4 and a lot more than that with IPv6.
> >
> > I$B!G(Bm curious as to why you think that the number is bounded at 14M fo
r
> > 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.

Actually, maybe you *should* explain how it will grow to 14M IPv4 routes.

Are there 13 million /24s still out there to be allocated? Where will these
routes come from?

Nick Hilliard wrote:

>> 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.
>
> nothing comes for free. Pushing the complexity down to the host
> level is not a "solution", just a workaround with its own set of
> problems.

If you can't accept the following principle of the End to End
argument:

The function in question can completely and correctly be
implemented only with the knowledge and help of the
application standing at the end points of the
communication system.

validity of which is demonstrated by the Internet, and insist
that something complete and correct is not a solution
but a workaround, feel free to keep using POTS not smart phones.

Masataka Ohta

Masataka Ohta wrote on 31/08/2019 11:35:
> If you can't accept the following principle of the End to End
> argument:
>
>     The function in question can completely and correctly be
>     implemented only with the knowledge and help of the
>     application standing at the end points of the
>     communication system.

this is a straw man argument. E2E works regardless of the current
network-based multihoming mechanism or the proposals in
draft-ohta-e2e-multihoming.

> validity of which is demonstrated by the Internet, and insist
> that something complete and correct is not a solution
> but a workaround

Your proposal is almost a text-book case of RFC1925, section 6:

> (6) It is easier to move a problem around (for example, by moving
> the problem to a different part of the overall network
> architecture) than it is to solve it.

I.e. instead of having network level complexity, you're proposing to
shift the problem to maintaining both state and network into the host
level. No doubt it has some benefits, but this comes at the cost of
bringing dfz complexity down to the host and all the consequent support,
scaling and management headaches associated with that. I.e. the problem
space shifts, but is not solved.

> feel free to keep using POTS not smart phones.

Thank you, I certainly will. Conversely, please feel free to use
arguments instead of rhetoric.

Nick

Nick Hilliard wrote:

>> If you can't accept the following principle of the End to End
>> argument:
>>
>>      The function in question can completely and correctly be
>>      implemented only with the knowledge and help of the
>>      application standing at the end points of the
>>      communication system.
>
> this is a straw man argument.

The text is in the original paper on the principle:

End-To-End Arguments in System Design
J. H. SALTZER, D. P. REED, and D. D. CLARK
http://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf

> E2E works regardless of the current
> network-based multihoming mechanism or the proposals in
> draft-ohta-e2e-multihoming.
As the next sentence of the paper is:

Therefore, providing that questioned function as a feature
of the communication system itself is not possible

which means:

Therefore, providing multihoming as a feature
of the communication system itself is not possible

you are wrong.

> Your proposal is almost a text-book case of RFC1925, section 6:

FYI, the rfc was published on 1 April.

> I.e. instead of having network level complexity, you're proposing to
> shift the problem to maintaining both state and network into the host
> level. No doubt it has some benefits, but this comes at the cost of
> bringing dfz complexity down to the host and all the consequent support,
> scaling and management headaches associated with that. I.e. the problem
> space shifts, but is not solved.

So, you are joking, aren't you?

> > feel free to keep using POTS not smart phones.
>
> Thank you, I certainly will. Conversely, please feel free to use
> arguments instead of rhetoric.

Instead of rhetoric, I argue by quoting from papers, hopefully not
published on 1 April, validity of which is well recognized.

Masataka Ohta

> On Aug 31, 2019, at 02:51 , Masataka Ohta <mohta@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

Masataka Ohta wrote on 31/08/2019 12:14:
>> Your proposal is almost a text-book case of RFC1925, section 6:
>
> FYI, the rfc was published on 1 April.

I'm aware of the date that rfc1925 was published and the significance of
the date, and also that rfc1925 was intended to take a humorous approach
towards some very fundamental, recurrent themes which continue to
present themselves in networking theory and practice.

No-one is compelled to pay attention to anything rfc1925 for this
reason, but anyone dismissing it will do so to their own disadvantage.

>> I.e. instead of having network level complexity, you're proposing to
>> shift the problem to maintaining both state and network into the host
>> level. No doubt it has some benefits, but this comes at the cost of
>> bringing dfz complexity down to the host and all the consequent
>> support, scaling and management headaches associated with that. I.e.
>> the problem space shifts, but is not solved.
>
> So, you are joking, aren't you?

We need agree to disagree then. I wish you well.

Nick

Nick Hilliard wrote:

>>> Your proposal is almost a text-book case of RFC1925, section 6:
>>
>> FYI, the rfc was published on 1 April.
>
> I'm aware of the date that rfc1925 was published and the significance
> of the date, and also that rfc1925 was intended to take a humorous
> approach towards some very fundamental, recurrent themes which
> continue to present themselves in networking theory and practice.

Thank you for your rhetoric.

Masataka Ohta

Owen DeLong wrote:

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

I don't think so.

> AS6939 — 125 prefixes...

Are you spamming?

> 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

If you are saying some merger happened before v6 transition,
which explains why there are less v6 prefix than v4, I can agree
with you.

But, so what?

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

The number of prefixes by swamp is recognized to be not a problem
even when we were discussing it in 1998 when there was only less
than 50000 prefixes.

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

> Yeah, not quite the whole story in that one word… Let's look at what
> is driving that increase in "multihoming"…

OK. You admit that the problem is caused by multihoming. OK.

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

I don't think I need such chance as my argument is already good enough.

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

I'm afraid you are not very familiar with semiconductor technology
trend.

Masataka Ohta

> I don't think I need such chance as my argument is already good enough.

I'm curious if you're able to convince anyone that your thoughts are valid
and correct with such an attitude.

From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>

If you can't accept the following principle of the End to End
argument:

The function in question can completely and correctly be
implemented only with the knowledge and help of the
application standing at the end points of the
communication system.
-------------------------------------------------------


I have been reading your posts on IETF and here regarding the
above and I'm curious as to your thoughts on John Day's RINA.
It tosses all this on its head.

scott

Scott Weeks wrote:

> I have been reading your posts on IETF and here regarding the
> above and I'm curious as to your thoughts on John Day's RINA.

As you give no reference, let's rely on wikipedia

https://en.wikipedia.org/wiki/Recursive_Internetwork_Architecture

and restrict scope only for multihoming.

Then, it is true that:

> 1972. Multi-homing not supported by the ARPANET.

which means current specifications do not support multihoming very well.

but, the statement

> The solution was obvious: as in operating systems, a logical address
> space naming the nodes (hosts and routers) was required on top of the
> physical interface address space.

is wrong, because it is enough to let transport layer identify
connections based on a set of physical interface addresses of
all the interfaces, which is what draft-ohta-e2e-multihoming-*
proposes.

That is, he misunderstand restrictions by the current specification
something inevitably required by layering.

> It tosses all this on its head.

If you have some text of RINA denying the E2E argument, quote it
with URLs please.

Masataka Ohta

On Sat, 31 Aug 2019 12:04:43 +0900, Masataka Ohta said:

> The solution is:
>
> https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03

All I see there is some handwaving about separating something from
something else, without even a description of why it was better than
what was available when you wrote the draft.

I don't see anything about how it's supposed to work - for example, if my cell
phone had an IP address via DHCP from my home wireless router but also has an
IPv6 from cellular connection, how *exactly* does it *securely* fall back to
cellular if a thunderstorn knocks out Comcast's gear in the area?

It's little details like that which were why your IETF draft wasn't taken
seriously, and your commentary today isn't doing any better.

Try attaching an actual protocol specification - preferably one that you've
actually got at least somewhat-working software to implement it. I guarantee
that you'll learn a few things in the process...

Valdis Kl?tnieks wrote:

>> The solution is:
>>
>> https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03
>
> All I see there is some handwaving about separating something from
> something else, without even a description of why it was better than
> what was available when you wrote the draft.

Read the first three paragraphs of abstract of the draft:

This memo describes the architecture of end to end multihoming. End
to end multihoming does not burden routing system for multihoming.
That is, even extensive use of end to end multihoming does not
increase the number of entries in a global routing table.

Traditionally with IPv4, multihoming capability is offered by an
intelligent routing system, which, as is always the case with
violating the end to end principle, lacks scalability on a global
routing table size and robustness against link failures.

On the other hand, with end to end multihoming, multihoming is
supported by transport (TCP) or application layer (UDP etc.) of end
systems and does not introduce any problem in the network and works
as long as there is some connectivity between the end systems.

> I don't see anything about how it's supposed to work - for example, if my cell
> phone had an IP address via DHCP from my home wireless router but also has an
> IPv6 from cellular connection, how *exactly* does it *securely* fall back to
> cellular if a thunderstorn knocks out Comcast's gear in the area?

Read the title of the draft. The draft is not intended to describe
protocol details.

There are other articles, some of which are peer reviewed papers,
describing details.

But, first thing for you to do is to read the title and the abstract
section of the architectural draft

> Try attaching an actual protocol specification

Read the title of the draft.

Masataka Ohta

> There are other articles, some of which are peer reviewed papers,
> describing details.

Can you link those?