Re: [irtf-discuss] Why do we need to go with 128 bits address space ?

[Robert Raszuk <[e-mail]>]

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 <
[e-mail]> 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
>
>