Dear Ohta-san,
While some of your points are very good I would like to make an observation that your idea expressed in the quoted below draft is a bit flown.
You say:
"Instead, APIs and applications must be modified to detect and react against the loss of connection."
Well it is clear that you are making an implicit assumption that quality of the available paths is equal and all you need to care about is end to end connectivity/reachability.
Real life shows otherwise.
When I have N providers regardless if this is in my POP in Toyosu, my POP in NY or my home the quality of the path significantly differs on a per destination basis. So if I were to give my hosts full power to decide which is the optimal end to end path to choose - imagine having even mini DC at each location - all 1000s of hosts would now need to probe all paths to choose optimal exit to reach their destinations.
Note that passive probing will not cut it so active probing is required as well. With that it is very clear that my edge router should do that job on behalf of 1000s of endpoints rather then each host itself..
Few weeks back I got few list of pointers to some proposals trying to tackle that real problem: rfc7556, DHCPv6 class based prefix or IPv6 Prefix Properties. As you can see making some of those measurements and classifications centrally is the only optimal option followed by locally educating end hosts or even applications about optimal paths.
And btw I would not immediately dismiss LISP nor call it garbage till you can demonstrate code and deployment which can do better.
Kind regards,
R.
On Wed, Aug 21, 2019 at 4:51 AM Masataka Ohta <mohta@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
shyam bandyopadhyay wrote:
> draft-shyam-real-ip-framework
is a reinvention of geography based addressing not acceptable
by ISPs in the real world.
> 2. Separation between Locators and Identifiers. Even though it
> was not documented in the requirement specification of IPv6, growth of
> routing table have become a real problem. One of the source of this
> growth is the way site multihoming has been supported in the existing
> system. Designers spent hell lot of time to come up with solutions like
> ILNP/LISP (with the concept of PI addresses)
LISP is not a solution but yet another garbage.
Attempt to convert ID to locator at the end (using ID as locator)
means loss of reachability to the end results in lack of conversion,
which is not multihoming.
Additional "optimization" to convert ID to locator also in the network
is against the E2E principle needing conversion information, amount
of which is at least proportional to the number of multihomed sites,
in the network, which is no better than having global routing table
entries, number of which is proportional to the number of multihomed
sites.
To make multihoming scale, think end to end, which means both ends
must be involved to make multihoming scale, which is what
draft-ohta-e2e-multihoming-* proposes.
Masataka Ohta
