Re: [rrg] Constraints due to the need for widespread voluntary adoption

[Dae Young KIM <[e-mail]>]

On Fri, Dec 4, 2009 at 3:13 AM, Noel Chiappa <[e-mail]>wrote:

>
> My original message was trying to understand the fundamental and
> unavoidable
> problems/weaknesses caused by having _two_ mapping systems ('DNS names' ->
> identifiers, and identifiers -> locators) as opposed to one - i.e. things
> no
> mere engineering changes could improve (hence my "assuming that at the
> future
> point in time we are talking about, both systems have been well
> engineered").
>

How about one mapping in the way:

   - DNS names -> ID     (here to me, ID = IP address = node address)

   - ID -> locator; this is not the job of Internet layer. In this context,
the locator here is to me the address of the underlying layer, such as

        - the X.25 address or
        - the ATM address or
        - the LAN MAC address or even
        - the private IP address of an enterprise network

So, my picture is as close as the RANGER proposal in that

        - although I can identify my destination node by 'node address' or
'ID'
        - the local address within each of the enterprise network cascaded
inbetween can all be different, independent.

Assume I'm sending a post mail in Corea to my destination node address (or
you can call it ID, too)

         237 Madison Avenue, New York City, NY, USA
              (happens to be the Morgans where I stayed...)

wherein my home (source) address might be somewhere in Seoul.

Still, the post mail reaches my destination without any problem. In each
county, country on the way from Seoul to New York, through mail boxes,
trucks, trains, ships, airplanes, down back to trains, boxes..., they all
use totally independent local addresses which I (as communicator to my
destination) don't care about, are not known to me, I'm not interested, is
none of my business.

So, all I need is the address (or ID) of my destination, and any locators
local to domains inbetween is none of my business. Locators will be mapped
again and again through the delivery process. In fact, a whole lot of NATs
on the way. NAT is not an evil, rather a norm.

I don't need a artificial concept of domain and interdomain, in fact. There
are only series of concatenated networks (or enterprise networks or whatever
you name it) which are chucked in whatever useful sizes/purposes only local
operators would be concerned about. I don't have to know all that details in
sending out my post mail.

.. network - NAT - network - NAT - network - NAT - .... etc.

So, the terminology 'address' in my use of 'node address' might be confusing
to many of people who used to think that

       address is only for routing whereas
       ID is only for identifying your 'abstract host stack'.

To me, they're one and the same thing. There's no routing without
identifying your partner. There's no identifying your partner without
routing to, i.e., without locating it. The two are one and the same.

The 'locator' which is being used in this community is not something
belonging to the internetworking layer we're talking about. It belongs to
the underlying layer, whatever the latter is. I don't even care how many
sub- and sub-sub- layers my underlying layer might have beneath it. I just
don't know, there's no way I can know, I don't care, not my business.

So, 'locator' is out of scope to our concern. You guys (or enterprise
networks if you like the term better) take whatever locator schemes/sets you
like, but just make sure you work with your neigboring business partners
that my post mail with an exact destination address (ID) be delivered
without fail. If you fail, I'll claim for reimbursement...

This is the model I have.

So.. where am I wrong? Or.. where am I correct or right?


-- 
Regards,

DY
http://cnu.kr/~dykim