Subject: Re: [RAM] Crisper Terminology

From: [email-masked] (Noel Chiappa)
Date: Fri, 8 Jun 2007 12:20:21 -0400 (EDT)

> From: RJ Atkinson <[email-masked]>

    > I'd agree with Brian that LISP is a dual-locator scheme, rather than an
    > ID-Locator split.

We've beaten this horse rather thoroughly in the past, so I won't belabour it
at length now, but I disagree.

Very briefly, the transport layer needs a name to distinguish the entity at
the other end with which it is communicating. That name is what we are
calling the "identifier" (for me, that's short for "endpoint identifier",
OMMV). Thus, any bit-string/name which serves this purpose of naming the
transport-layer entity at the other end is, *by definition*, an "identifier".
It may *also* have some locational semantics (as the one of the two LISP
namespaces which is an identifier does), but it is *not* - nay, *cannot* be -
a pure locator.

    > This isn't criticism of LISP, just an effort to have clear terminology
    > so that discussion can be clear and focused.

Understood. However, as I hope I make clear above, thinking that this name is
*not* an identifier is, to me, a source of potential confusion.

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 8 Jun 2007 13:25:53 -0400

On  8 Jun 2007, at 12:20, Noel Chiappa wrote:
> We've beaten this horse rather thoroughly in the past,
> so I won't belabour it at length now, but I disagree.
>
> Very briefly, the transport layer needs a name to distinguish the
> entity at the other end with which it is communicating. That name
> is what we are calling the "identifier" (for me, that's short for
> "endpoint identifier", OMMV). Thus, any bit-string/name which serves
> this purpose of naming the transport-layer entity at the other end is,
> *by definition*, an "identifier".  It may *also* have some locational
> semantics (as the one of the two LISP namespaces which is an
> identifier does), but it is *not* - nay, *cannot* be - a pure
> locator.

There is a perfectly good a name for objects with both identification
and location semantics.  This community generally calls them addresses.
For example, the existing TCP implementations use an IP address
as the endpoint name for TCP purposes.

> Understood. However, as I hope I make clear above, thinking that
> this name is *not* an identifier is, to me, a source of potential
> confusion.

This is the crux of the disagreement.  Most of this community uses
"Identifier" to mean a pure Identifier -- with no locational semantics
-- and has had that meaning for about a decade now.

The object with mixed semantics has been called an "Address" in this
community for decades.  People understand that an address has both
locational semantics and identification semantics.

The difference does matter for clarity of discussion here,
because the semantics of an Identifier and of an Address
differ -- and this discussion needs to remain architectural
(where semantics do matter) if it is going to be productive.

My guess is that this community is going to end up preferring
to retain the address and go with LISP, but the best/fastest
way to figure out the issues is to have clear, crisp terminology.

Cheers,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Jun 2007 08:42:22 +0200

On 2007-06-08 19:25, RJ Atkinson wrote:
...
> and location semantics.  This community generally calls them addresses.

I'd be tempted to agree with that, but I just had occasion to
review draft-ietf-ccamp-gmpls-addressing-07.txt, and found my head
spinning rapidly on exactly this question.

> as the endpoint name for TCP purposes.

Well, if we use OSI formalism, we'd have to say that the transport
address is the network address concatenated with the port number.
There was a fairly clear model for layered endpoint addressing in
OSI, and it still a valid thinking aid IMHO.

     Brian

---

From: Russ White <[email-masked]>
Date: Sat, 09 Jun 2007 12:18:34 -0400

> way to figure out the issues is to have clear, crisp terminology.

There are actually two parts to this:

1. The sort of split LISP uses.
2. The protocols used to provide the magic mapping between the locator
and the ID.

So far, the split appears to be "assumed," and the harder points about
this split have been not discussed at all. The discussion has centered
around the mapping protocols, with mobility being taken off the table as
being a problem to solve.

IMHO, there are two dangerous decisions here, one not to discuss the
implications of a loc/id split, and the other to take mobility off the
table as a problem to be solved.

But, I've made those points in the past, to no avail, so there's no
reason to belabor them here again.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

---

From: Jari Arkko <[email-masked]>
Date: Sun, 10 Jun 2007 16:39:55 +0300

Brian,

> spinning rapidly on exactly this question.

I actually do agree with Ran on this. (My head also started
to spin on the same document that you mentioned, but
I take it as an issue in the document, not in the terminology
above...)

Anyway, part of what complicates the terminology
discussion is that some of the proposals employ
addresses whose locator semantics are partial,
e.g., usable as locators only on the edge, not
in the core.

Jari

---

From: Scott W Brim <[email-masked]>
Date: Mon, 11 Jun 2007 13:01:41 -0400

> spinning rapidly on exactly this question.

The problem there is separation of planes.  Router and Forwarder are
somewhat independent, thus Control and Forwarding (Data) Plane are as
well.  In GMPLS you have an independent control plane, and an
independent control plane requires independent transport names.  The
IP component of control plane transport, has its own locators, and
forwards packets which carry in them identifiers of components of the
(possibly non-IP) forwarding plane.  I believe it's right to say that
the "addresses" in the forwarding plane are really identifiers, but it
depends how path setups are done.  However, it seems that those
identifiers are not only system identifiers but also interface or link
identifiers.