Re: [rrg] Scalable Internet

> From: Dae Young KIM <dykim at cnu.kr>

Dave Clark's NewArch project talked about this at some length. The design
they produced was a lot more radical than I think (alas) is feasible in the
Internet, because there are 'deployed base' issues which make such a radical
revision hard/impossible. It did not have globally-unique endpoint names.

Good work they did.

We never finshed the locator part, but I argued to them that there are
fundamental reasons (which I explain below) why those do have to be globally
'meaningful' (to pick a slightly less rigorous word than 'unique'); although
they essentially need to be 'unique' too, because if two different locations
have the same globally meaningful locator, you cannot distinguish between
them, which seems.... problematic.

I'll try to repeat below, but in my picture again, it looks like:

o locator can be local (no need to be globally unique).
o the remote locator would be retrieved (from a cache or a server) at the arrival of a packet there. On inter-AS links, AS# is enough to reach the other side.

Since then, the combination of AS (available already on the inter-domain link) and locator (to be available at the arrival of the packet) should provide us a 'meaningful' locator in effect. Would it?

(To me, naming a thing with a name of local scope, and naming the scope with a globally-unique
name, so that you can refer to the thing with a two-part name which is
globally unique, is effectively giving it a globally unique name.)

Yes, exactly. Why don't you take this two-step approach?

So many systems which attempt an evolutionary path which turns the existing
IPvN addresses into EIDs need them to be globally unique, since they will be
trying to process packets which contain only an EID, and need to look the EID
up.

Using IPvN addr as EID has the advantage. Although EID need not be globally unique from architectural sense, the current IPvN infrastructure already provides us the global uniqueness. Why then shall we abandon this already acquired asset(free lunch?) without good reason?

Having EID global provides us with an additional advantage, as you pointed out. A compromise with the 'deployed-base', but a rewarding compromise.

As to locators, the argument for their need to be globally 'meaningful' (and
hence unique, as shown above) is simple: to compute paths across a fabric,
you need names which are unique across the fabric. I.e. when you give a
locator for some place on the far side of the network to the path-selection
(i.e. routing), that name has to be 'meaningful' to the path-selection. In
other words, that name has to uniquely identify, out of all the possible
'places' in the network, the place you are trying to get to.

Well, here, let's break the name in two pieces. The AS part is globally unique, and it will ensure the delivery of the packet to the destination AS. The local locator will then be retrieved/appended in injecting the packet into the target AS.

Wouldn't this two-step approach yet provide us with the effectively 'meaningful' global uniqueness sufficient for routing?

Sometimes people aay 'oh, but you can have a source route which is a list of
local-scope names, so therefore you don't need global-scope locators'. The
first part is true, but the second part is not: how was that source route
computed to begin with? Unless there is some way to create that source route,
some way to compute the path (which I claim requires globally significant
names), the fact that a source route can be composed of local-scope names
is inteesting but not really relevant.

I won't be enthusiastic at all with this source routing idea.

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.