Hi, Ran, I think you're missing the point.
Where did I assert anything about semantic overloading? Take, for example, the MAC address. It points to a MAC device in a LAN. And the MAC address is taken out of a flat number space. That is, it's a flat address space. And the whole LAN is operating without a problem with this single number called MAC address. It not only identifies a MAC node, but also used in the whole routing. The only difference with the Internet routing is that MAC uses a different routing algorithm call spanning tree. So, with the MAC address, they are doing - node identification - routing, and - forwarding. I've never heard that MAC addressing is a problem because of context overloading. The same picture should repeat at the internet-layer. Nothing different. This leads me to say that, in fact, the diagnosis that address overloading was a problem with the Internet is simply a wrong diagnosis. By saying this, I know I'll be one of very few minorities that don't believe in what the whole IETF or the whole prominent workshops that you mentioned has graciously taught us. Now, look at the picture of ILNP that you yourself draw again. o ID identifies a node. o Locator identifies a subnet. They are basically the same thing. With my above example of MAC, they're using only node IDs (MAC addresses) to do all L2 routing, with bridge (L2 relay) instead of router (L3 relay). Would you now then go further to say that we should start calling them MAC ID's instead of address? No, because they're used for routing. Then would you rather propose to start calling them MAC Locators? According to the definition of yours, both ID and Locator are exactly the same thing as address as it is used in MAC address. So, the problem was not IP address overloaded. The real problem was, to me, that the IP addresses point to the interface, not to the body. But, very fortunately, you yourself propose a way out of this dilemma, independently whether you knew yourself what you're really doing: o ID points to a node; body, not leg. o Locator points to a subnet; body, not leg. Perfectly fine. This really was what we needed in every tackling the problem of the architectural flaw of the current Internet which is the source of the whole mess/confusion. You did an excellent job. Congratulations. And so, now that the real problem was not overloading of the address in the Internet, we don't have to split the same thing into different terminologies, and we only need to keep the same terminology 'address' with only a more careful perception what each address space is meant for: o Node address for nodes o Subnet address for subnets o MAC address for MAC nodes etc. On Fri, Jun 11, 2010 at 5:22 PM, RJ Atkinson <[email protected]> wrote: > > On 10 Jun 2010, at 21:34 , Dae Young KIM wrote: >> So, basically, I wouldn't need any terminology than 'address' which has been >> out there and used without problem(?) for forty years or more. > > The fundamental disagreement you and I have is your assertion/ > belief above that the existing overloaded semantics of the > IP address are "without problem for forty years or more". > > If we ignore the lack of 40 years since the initial definition > of IP itself, I believe there is actually pretty broad consensus, > both within this RG, and also within the routing/addressing parts > of the IETF, that the current overloaded semantics are indeed > the root of multiple problems. The RG doesn't have consensus > on the best engineering approach to resolve those issues, > but that is a separate question from where the problems originate. > > I've rummaged around in a reasonable literature search, > and as near as I can tell, the earliest description of > these problems caused by overloaded semantics dates back > to 29 July 1977 when [IEN-1] was published. More recently, > a belief among the IAB Routing & Addressing Workshop folks > and the IAB generally that overloaded semantics of the IP > address was a significant problem caused this RG being > re-chartered about 2 years back [RFC-4984]. > > (Now, all that noted, I will observe that a real effort was made > to make the Terminology poll neutral with respect to a range > of proposals (e.g. LISP).) > > Yours, > > Ran > > PS: To find [IEN-1] online, do a web search for "ien001.pdf". > It is only available in PDF these days, not text/plain. > > -- DY _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
