Subject: Re: [rrg] Scalable Internet

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

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

I think a lot of my message may have confused you, because I was using the
term "name" as a generic term, in the sense of 'something used to name a
particular thing', with no particular syntax or properties.

So, 'addressesa', 'locators', 'identifiers' - they are all 'names', in the
sense I was using the term 'name'. So perhaps you could re-read my message:

  http://www.ietf.org/mail-archive/web/rrg/current/msg05312.html

with that in mind, and perhaps it will make a bit more sense this time... :-)

    > 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.

Yes, and as we discussed earlier, everyone seems to agree that 'separation of
location and identity' is a _necessary_ part of 'solving the inter-domain
routing problem' (whatever that is :-).

    > one approach seemingly getting wider support is to take separation of
    > ID(host) and Locator(for routing) as the basis.
    > ...
    > In the endeavor, this RRG might possibly come up with a again different
    > picture than what HIT and LISP drew.

Except that LISP is an attempt to 'do' that part of the problem, in a way
that is practical, realistic, and feasible - i.e. actually likely to be
deployed and used in a widespread way. As we have discovered over the last
couple of decades, it's easy to dream up a new design - what's hard is to
come up with a design that the world actually takes up and uses.

I happen to think that the path of which LISP is a first step is the best
path, but because it does separate location and identity is only a part of
the reason I like it. To me, there are other, more important reasons I like
this path - the layer of xTRs which will hopefully grow up gives us a nice
boundary inside of which we can make changes which are not necessarily
visible to legacy hosts and site routers (e.g. deploy a new locator
namespace, deploy a new routing architecture, etc).

But I think it's a bit premature to try and design all that new stuff - and
in any case, there's no manpower for it. What I am trying to do with LISP is
make sure that it has useful 'hooks' in it to make deployment of future
pieces easier (e.g. the RLOC resolution protool can produce answers which are
in a format other than 'IPv4' or 'IPv6').

Like I said, the chief difficulty with any new architecture we come up with
is not designing the architecture - any competent architect can do that.
Coming up with a way to deploy it is the real challenge.

	Noel

---

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

> with that in mind, and perhaps it will make a bit more sense this time...

Joe, I don't have a problem at all with your arrangement. I used be an OSI
guy, and this notion is not new to me at all. I'm already with you.

   > problem, or more specifically, the inter-domain routing problem.

 Yes, and as we discussed earlier, everyone seems to agree that 'separation
> of

Joe, I read LISP, and yet, it's still very complicated and confusing.
Introducing too many extra artifacts into the infra.

My idea of using AS# in inter-domain routing would alleviate the burden with
the 'deployed base' issue. With my scheme, only one additional significant
component is a LocS (AS or ID to Loc mapper) inside a local AS. DNS would
keep a AS# in addition to string-AS - ID(IPvN addr) pair.

At this point, I think I'll better have to post my unfinished PPT to better
highlight my idea, for better understanding. Please find my 'unfinished'
presentation file. Numbers in Scenario are different from my text memo,
though.

(I've been here in Salt Lake City for this week to attend the GENI Conf. 6
(GEC), and found little time working on it.)

> in a format other than 'IPv4' or 'IPv6').

Again, I might also buy much of LISP, but I'd like to try to use only AS# in
inter-domain routing to keep gateway tables from exploding.

If, as you said, LISP still relies on the current routing architecture, then
it shouldn't be free of table explosion problem. What is the case? Am I
right?

The top design requirement for my idea is to eliminate the risk of exploding
table.

> Coming up with a way to deploy it is the real challenge.

Yes, my second top priority. I tried to introduce minimal disturbance to the
current infrastructure. Doesn't LISP introduce any more significant artifact
to the infra than mine?

-- 
Regards,

DY
http://cnu.kr/~dykim