Subject: Re: [rrg] Scalable Internet

From: [email-masked] (Noel Chiappa)
Date: Thu, 19 Nov 2009 09:42:56 -0500 (EST)

> From: Dae Young KIM <[email-masked]>

    > Many people out there believe BOTH id AND locator should be global. In
    > fact, there's no compelling architectural reason why they have to be
    > globally unique.

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.

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 agree with you that there is no fundamental reason endpoint identifiers
have to be global. As I mentioned, altough NewArch didn't really have
endpoint names, the closest thing they had to them weren't globally unique,
and they worked fine.

Depending on how/where you use them, though, it may be necessary to have them
global - if you ever need to look them up, for instance. (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.)

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.

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.

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.

	Noel

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 20 Nov 2009 00:51:01 +0900

> revision hard/impossible. It did not have globally-unique endpoint names.

Good work they did.

> 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

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

> trying to process packets which contain only an EID, and need to look the

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.

> '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?

> is inteesting but not really relevant.

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

-- 
Regards,

DY
http://cnu.kr/~dykim