Subject: Re: Why do we need to go with 128 bits address space ?

From: Masataka Ohta <[email-masked]>
Date: Tue, 3 Sep 2019 09:38:24 +0900

To justfy cross posting by Shyam Bandyopadhyay to many lists;

As I wrote:

> shyam bandyopadhyay wrote:
> 
>> draft-shyam-real-ip-framework
> 
> is a reinvention of geography based addressing not acceptable
> by ISPs in the real world.

among many participants of all the lists, I, only on IETF list,
am the only person to pay respect to him by, spending some time,
reading his draft seriously enough to find a known defect.

Though he may be disappointed, it is better if defects, if any,
are found as early as possible.

So, he did the right thing.

						Masataka Ohta

PS

Attacking someone's draft without reading it is a personal attack.

PPS

I found RINA, seemingly, have the same defect. I'll discuss it in
a separate mail.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 3 Sep 2019 10:12:30 +0900

Fred Baker wrote:

> I'm familiar with the paper "End to end arguments in system design"
> as well. I'm also familiar with John Day, although I suspect I have
> learned more from him than he has learned from me.

As for RINA by John Day, following description in wikipedia (if any
of you have better reference, hopefully open access one, let me know)
disturbed me:

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

	CLNP was an OSI-based protocol that addressed nodes instead
	of interfaces, solving the old multi-homing problem
	introduced by the ARPANET, and allowing for better routing
	information aggregation.

As CLNP addresses basically are telephone numbers, they are
aggregated by country code, which requires reliable telephone
exchangers exist connecting all the international and intra-national
long distance carriers in each country.

Similarly, aggregation by area code needs similar telephone
exchangers in each area.

That is, John, seemingly, think geography based addressing
is good, which is against our understanding that requiring
IXes in all the geographic regions is not practical.

Or, according to the E2E 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. Therefore, providing that
	questioned function as a feature of the communication
	system itself is not possible.

providing multihoming function by telephone exchangers or
IXes, that is, "as a feature of the communication system
itself", completely and correctly is not possible.

Thus, if telephone exchangers or IXes fail and intra-national
network is partitioned, the result will be disastrous.

						Masataka Ohta

PS

Distribution of this mail is unlimited.

---

From: shyam bandyopadhyay <[email-masked]>
Date: Tue, 3 Sep 2019 21:01:42 +0530

The intention to establish hierarchy is to reduce
the number of entries in the global routing table.

Relating a (networking) region to a geographic
region is just to satisfy administrative policies.

If no such requirements arise, establishment of
hierarchy becomes easier at the same time
address space can be used in a better fashion.

By the way, I am thankful to you just because you
took the pain to go through my document.

Shyam

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 4 Sep 2019 06:42:12 +0900

Welcome back.

> the number of entries in the global routing table.

True, and rfc2374, though obsoleted, shows a very good
way to do so.

Though the rfc limit the number of global routing table
entries 8k, which many people says too restrictive,
we must make the number below reasonably small constant,
anyway.

> region is just to satisfy administrative policies.

Yes, in theory, it is possible, like telephone network, to
regulate so.

But, it requires tight and reliable connection within all
regions and is not very elegant (network partition can be
disastrous).

It is not acceptable to many ISPs already having addresses,
because they must get new address ranges in all the regions,
which means massive renumbering. But, it is not a problem
if we start over with new network protocols.

> address space can be used in a better fashion.

The problem is that, with rfc2374 style addressing,
those who can not get a TLA must ask others with TLA
part of their address, which means massive renumbering.

Automatic renumbering including routers within ISPs, which
IETF failed to develop, is absolutely necessary to limit
the number of TLAs.

My colleagues actually developed automatic renumbering
system including automatic rewriting of DNS entries.
It works both for IPv4 and IPv6.

> took the pain to go through my document.

Not any pain. I enjoyed it. Thank you.

					Masataka Ohta

---

From: shyam bandyopadhyay <[email-masked]>
Date: Wed, 4 Sep 2019 17:16:40 +0530

> we must make the number below reasonably small constant,

BGP report (https://bgp.potaroo.net) shows
number of entries in the routing table
has crossed 800000 mark.

Solution for site multihoming will give some relief,
then it will start growing again. I guess something
has to be done to restrict this growth.

Thanks.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 4 Sep 2019 15:42:43 +0200

Le 04/09/2019 à 13:46, shyam bandyopadhyay a écrit :
> 
> 
> On Wednesday, September 4, 2019, Masataka Ohta  
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

Has it?

Last time I checked it was in the 700k ball mark.

Alex

---

From: Shyamaprasad Bandyopadhyay <[email-masked]>
Date: Wed, 4 Sep 2019 23:59:27 +0530

I should have been little more careful.
I saw the upper part of the graph crossing
800000 mark. I thought that might
be the current state. Well, it may be
somewhere in between 700000 &
800000, but not very much away from the
800000 mark.

Thanks for your correction.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 5 Sep 2019 10:39:10 +0200

> 800000, but not very much away from the

Thanks, it was just some thought.

The yearly growth rate seems indeed to increase (+30k in 2010, and then 
+30, 50, 50, 50, 40, 40, 60, 90, 40) making think it may reach 800000 
before end of year 2020, but not now.  That's why I reacted to the 
800000 mark you posted.

These are "BGP routing table entries examined" excerpts from the "Weekly 
Routing Table Report" reported on nanog email list.

[...]
         12-06-09    287824
         09-04-10    317715
         11-02-11    345778
         03-02-12    397625
         31-01-13    443138
         07-02-14    492404
         30-01-15    535593
         05-02-16    579829
         27-01-17    630069
         07-11-18    724058
         30-08-19    768323

Alex

> On Wed, 4 Sep 2019, 19:13 Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]> wrote:
> 
> 
> 
>     <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >