Subject: Re: [rrg] Scalable Internet

From: [email-masked] (Noel Chiappa)
Date: Wed, 18 Nov 2009 23:48:05 -0500 (EST)

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

    >> Locator == network  (or loosely ASN in today's bgp4 routed world)

    > Perhaps, then, you .. means that the locator is a AS number(ASN)
    > ...
    > Locator was meant to an address that IP would use in routing as it uses
    > IPv4 or IPv6 as routing locator.

Some people think that internetwork 'location names' should name just the
physical network, and that the interface 'address' is a separate name; the
reason they give is that they are conceptually separate concepts, and the
names that result are from separate namespaces. (I must confess I don't
really understand this view, so I can't explain it perfectly - perhaps
someone else can?)

I view things somewhat differently, and in a way that's similar to the one
you give above. To me, what is important about a namespace is i) what is
being named, and ii) what the characteristics of the name are; which to me
need to be driven by what the main use/uses of the name will be.

For i), I would like to be able to name interfaces - because it is to an
interface that the system of routers needs to deliver a packet. However, that
covers a large variety of names (e.g. a globally unique ID could name
intefaces), so I need to think also about ii) to pick a kind of name for
interfaces. For ii), I would like to see a structured name, which can be used
to select/compute a path to the destination in a very large network.

I suppose one could say that those names are concatenations of a) a
structured name for the physical network, and b) the name of an interface (as
I started by mentioning), but I don't see a lot of value in separating the
two in a way which is globally visible - it is only when one gets to the
destination physical network that one needs to be able to separate the two
parts.

    > I would use locator (IPv4 or IPv6 address) for intra-domain routing,
    > but not for inter-domain routing.

My view is that the strict separation between just 'intra-domain' routing and
'inter-domain' routing is a simplistic one, and one that I do not think will
last. I hink that what we really need is the ability to have multiple levels,
and not just two - and I think those should be within a unified overall
routing system.

    > In this sense, my idea and LISP's meet. Both uses ASN for inter-domain
    > routing.

LISP does not use ASN for any forwarding decision; it uses IPvN addresses
(from the RLOC namespace).

Not that LISP really has a routing component at the moment anyway - it
depends entirely on the existing routing for packet carriage.

	Noel

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 19 Nov 2009 15:11:51 +0900

On Thu, Nov 19, 2009 at 1:48 PM, Noel Chiappa <[email-masked]>wrote:

> intefaces),

Not everything has to be named. For the interface, all we need is an
identifier which more specifically is called locator. Again, in this
picture, I assume a host can have multiple interfaces, and so multiple
locators. And there's only one 'host identifier(ID)'.

Host better be named. Since in most applications, number is not very human
friendly, and we'd like to use a name like 'mercury.lcs.mit.edu.' But as
soon as it is injected into the application, the application would consult
the DNS to find a number(host ID) for the name, like, 168.188.48.120.(Sorry
not your real number...).

> so I need to think also about ii) to pick a kind of name for

So, apparently, you're looking for names for locators, for you want to use
it for routing. For this purpose, you don't really need names, and all what
you need is (interface) identifier, which in my picture, is the very
locator(IP address).

> destination physical network that one needs to be able to separate the two

This is exactly what current routing is doing. Between the 'physical'
networks, BGP only use network prefixes. Once the packet arrives the target
network, then the locator is used inside the 'physical network' which
constitutes one separate AS.

> and not just two - and I think those should be within a unified overall

Great. We agree here. So, if you have another look at my summary of the
idea, AS (aks domain) can recurs inwards and outwards. Domains are not just
one tier. There can be multiple tiers or levels. Good point.

> (from the RLOC namespace).

I see. Then I'd diverge here also from LISP. I don't need any extra name
space for this. Use of current AS numbers is enough for me.

> depends entirely on the existing routing for packet carriage.

Here lies the fundamental difference in starting point between LISP and the
mission of this RRG. The RRG's mission is to solve the routing problem, or
more specifically, the inter-domain routing problem.

There can be many approaches, but one approach seemingly getting wider
support is to take separation of ID(host) and Locator(for routing) as the
basis. Then, we're to further figure out what the best arrangement of those
would be to in regard to host, interface, gateways.. is the task of this
RRG, as I understand. In the endeavor, this RRG might possibly come up with
a again different picture than what HIT and LISP drew.

This should be no wonder, for the initiating problem space of HIT and LISP
was mainly hosts, whereas that of this RRG is mainly routing/routers.
Builing a house from bottom to top might deliver a different house than that
would be generated by building one from top to bottom. No wonder at all.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 19 Nov 2009 01:41:07 -0500

On Thu, Nov 19, 2009 at 1:11 AM, Dae Young KIM <[email-masked]> wrote:
>>    > From: Dae Young KIM <[email-masked]>
>>    > Locator was meant to an address that IP would use in routing as it
>> uses
>>    > IPv4 or IPv6 as routing locator.
>>

noel can explain a bunch more of this, but.. I think 'name' in his
context isnt 'mail.lcs.mit.edu' but rather: "192.168.2.2" in today's
parlance, in tomorrows LOC/ID separated world though it's possible
that it's something entirely different a  local IDENTIFIER, with
perhaps a LOCATOR concatenated.  Representing that thing isn't clearly
defined (that I've seen) so: "name" works... for now.

-chris

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 19 Nov 2009 21:25:07 +0900

On Thu, Nov 19, 2009 at 3:41 PM, Christopher Morrow <[email-masked]
> wrote:

> defined (that I've seen) so: "name" works... for now.

I see. I'm quite behind.

Question: In this arrangement, will the name (possibly concatenation of a
local ID and a local Loc) then be globally unique? Or is it the intention of
people that even the name may not be global?

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Tony Li <[email-masked]>
Date: Thu, 19 Nov 2009 05:40:40 -0800

Dae Young KIM wrote:

> Question: In this arrangement, will the name (possibly concatenation of 
> a local ID and a local Loc) then be globally unique? Or is it the 
> intention of people that even the name may not be global?

This is now into the realm of variations among proposals.  Both are 
reasonable and workable alternatives.

However, if one chooses a locally unique identifier, then there are more 
mobility issues.  If one chooses globally unique identifiers, then you 
have to have a mechanism to ensure uniqueness.

In many cases, statistical uniqueness with a detection and recovery 
algorithm will be acceptable.

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 19 Nov 2009 23:25:57 +0900

On Thu, Nov 19, 2009 at 10:40 PM, Tony Li <[email-masked]> wrote:

> mobility issues.

Yes, definitely.

> If one chooses globally unique identifiers, then you have to have a
> mechanism to ensure uniqueness.
>

If we take the current assignment of IPv4 and IPv6 as identifiers, then we
can assure the global uniqueness of the identifiers. But, with awakening of
Christopher and Noel, I realized the ID should be exposed also in
inter-domain routing, extra to the AS # that I chose to take, then perhaps I
might not be able to keep the gateway routing table from explosion.

> algorithm will be acceptable

Here I might seek your education, if you don't mind. Statistical? Detection
and recovery algorithm?

> .

-- 
Regards,

DY
http://cnu.kr/~dykim