Subject: Re: [rrg] semantic overloading

From: [email-masked]
Date: Fri, 11 Jun 2010 06:12:22 EDT

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-masked]:

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-masked]> 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-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 11 Jun 2010 20:10:10 +0900

On Fri, Jun 11, 2010 at 7:12 PM,  <[email-masked]> wrote:
> loose hop is the path to the egress-locator. The second loose hop is the
> path from there to the destination host.

Would it be a problem if we split the routing in three hops?

  - One from the source host to the egress-locator(router?).

  - Another form the source egress-locator the destination ingress-locator.

  - The last from the destination ingress-locator to the destination host.
-- 
DY

---

From: [email-masked]
Date: Fri, 11 Jun 2010 07:36:57 -0400

Not at all.
Heiner

---

From: [email-masked]
Date: Fri, 11 Jun 2010 07:59:30 -0400

Not at all. 
We may consider the entire path from
source host to the (well known) ingress node to the locator-bestowed ingress node to the locator-bestowed egress node to the
(well-known) egress node to the destination host.
On this whole way we may consider where and how locators are transported (and also inserted, exchanged or removed) 
- e.g. by which layer i   (with potential i= 2 or 2.5 or 3)

Heiner

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 11 Jun 2010 22:57:28 +0900

Great.

I think I was using terms in the opposite way.

In your and other usual tunnel based scenario like LISP, it is

    host - ingress - egress - host

I used them in different sense like

    host - egress - ingress - host

How interesting and confusing our terminologies are.

On Fri, Jun 11, 2010 at 8:59 PM,  <[email-masked]> wrote:
> source host to the (well known) ingress node to the locator-bestowed ingress
> node to the locator-bestowed egress node to the
> On this whole way we may consider where and how locators are transported
> (and also inserted, exchanged or removed)

-- 
DY