I am afraid that some of the definitions of the poll just create confusion (incl.this email below). An "identifier" identifies some specific entity within a given set of comparable such entities. It is not good to define such a general term by some very specific applications (btw, how would session-id fit in wrt the given definition?) . Obviously these definitions of the terms address, locator and identifier have been given one after the other as to differentiate them from each other. imho the confusion stems from the way how loc/id-split has been discussed. The network layer needs to cater for a two-loose-hops routing. The first loose hop is the path to the egress-locator. The second loose hop is the path from there to the destination host. A completely different issue is the clean separation between TCP and IP. If we would properly handle the first issue the second issue would become obsolute (as an additional bonus). Heiner In einer eMail vom 11.06.2010 10:47:58 Westeuropäische Sommerzeit schreibt [email protected]:
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
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
