Subject: Re: [RAM] Crisper Terminology

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

> From: Scott W Brim <[email-masked]>

    > Some approaches have IP-layer identifiers that are in fact pure
    > identifiers. Others like LISP use locally-significant locators as
    > identifiers, when outside of their locator scope.

Just to clarify something (you probably meant this, but the words don't quite
say this), it's always an identifier, wherever it is in the network (i.e.
either inside or outside its locator scope).

I think there is general agreement/understanding that it's only
meaningful/useful as a locator inside its locator scope. (Which one would
think would naturally lead one to the question "What is it when it's outside
that scope, since it's not a locator out there", but I digress...)

	Noel

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

---

From: [email-masked]
Date: Fri, 8 Jun 2007 15:14:51 EDT

We are dealing here with some information and the ways we are using it give  
it different meanings.
Is the used information sufficient or does it need some extension? Are the  
ways we use it still appropriate or do our handling mechanisms  cause  problems 
and should therefore better be changed or replaced ?
 
Obviously, new developments and applications as well as the internet growth  
itself demand for changes and improvements.
 
Two natures of the information are in stake: location information and  
identification information.
First we should know what shall be accomplished, then we can see what  is to 
be changed.
 
Routing is a big issue, but as far as I can observe, all just stick to  the 
traditional mechanisms and prefer a fundamental change rather be  postponed. TE 
is accused to be part of the problem. But isn't in this case the  mechanism 
itself a subject for chapter 11 ?
 
Identification is an urgent problem, too (e.g.we are running out  of 
IPv4-addresses).
Brian wrote: "is more so" meaning IPv6 is just more of IPv4. Very true.  
Correct me if I am wrong:the IPv6 address space does not INCLUDE the IPv4  address 
space. If so, is that good or rather bad ? intended or unintended ? Why  
isn't there an address family Identifier (AFI) ? One for IPv4, one for IPv6 ?  Or: 
one for roaming users rather than static users? One for E.164 (instead of  
DNS mapping a la enum) ? Etc. etc.
 
And given such multiple address families processing types like unicast,  
anycast, multicast, mp2p, mp2mp
becomes really orthogonal to it, i.e. needs to be differentiated by  
operational flags rather than address subranges ! 
 
Both locating  and identification have their special aspects by  themselves. 
Both shall be handled accordingly.
 
The current discussion rather shows that the split itself is the real goal,  
the true objective - which is not.
 
Heiner

In einer eMail vom 08.06.2007 19:26:29 Westeuropäische Normalzeit schreibt  
[email-masked]:

On   8 Jun 2007, at 12:20, Noel Chiappa wrote:
>> 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.

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.

>> 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.

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: [email-masked] (Noel Chiappa)
Date: Mon, 11 Jun 2007 12:03:32 -0400 (EDT)

>>> LISP is a dual-locator scheme, rather than an ID-Locator split.

    >> 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" ... any bit-string/name which serves this
    >> purpose of naming the transport-layer entity at the other end is,
    >> semantics

    > and location semantics. This community generally calls them

That's an interesting point. I have in the past generally tried to
discourage use of the term "address" because it means different things to
different people, and use of it is therefore often confusing.

As an example, the term 'locator' was introduced to the lexicon by the Nimrod
project because in Nimrod, 'addresses' (which in Nimrod are long, and
variable-length) are not necessarily carried in all packets, and whenever
people heard the word 'address' they kept assuming they were in every packet
(i.e. inefficient processing), no matter how hard we tried to get it through
that they were not.

(And of course the current assumed main point of the definition of 'locator',
i.e. meaning 'a name with topological semantics', wasn't really the point of
what differentiated a 'locator' from an 'address'.)

So, I'm perfectly happy if you and I use the term 'address' to mean 'a name
that is used at the internetwork level to name an interface, and has location
semantics; and is also a name which is used at the transport layer to name
end-end entities'. However, we can't assume that when we use the term
'address', other people will understand that meaning...

Anyway, using that terminology, LISP has a locator and an address, but the
'interface naming with location semantics' part of the the latter has only
local scope/utility.

    > 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.

Right, but there's another axis we need to be worrying about, past the
locational/non-locational, which is 'what kind of thing are these names
naming'. And to me (perhaps because I started using 'identifier' as part of
the phrase 'endpoint identifier') 'identifier' has always *also* meant 'names
a transport entity'; and 'locator' has always also meant 'names an
internetwork-level entity'.

Which is the main reason why I always objected when you said that "LISP is a
dual-locator scheme, rather than an ID-Locator split", because to me one of
those names was, in part, always an identifier, i.e. the name of the
transport entity.

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

That will certainly help. Unfortunately, at the moment it seems to me that we
have too few terms (or too many concepts :-). First, let's look at the
attributional axes we need to cover:

- Locational/non-locational
- Internetwork/transport
- Interface/'endpoint'

Of course, some people might argue that the latter two are identical, but I
have heard people argue for locational names for endpoints, so I would suggest
we not collapse them together.

Then, in theory at least, one could have one term for each possible choice,
so a Nimrod 'locator' is locational/internetwork/interface. But of course
IPv4 addresses are *both* for at least two of the three! So really it's three
choices for each:

- Locational/non-locational/both
- Internetwork/transport/both
- Interface/'endpoint'/both

Even assuming the last two are identical, that leaves us with nine possibile
ways of mixing those attributes; we could, in theory, have a term for each
possible combination... Some of the combinations are not worth naming, of
course, which simplifies things somewhat. However, we still have a lot more
potentiall useful combinations than we have terms.

Also, then there are some subsidiary ones we haven't discussed yet:

- In all packets/not-in-all-packets
- The field looked at by the switches to forward the packet (which I have
	in the past called the 'forwarding tag')

So that a Nimrod 'locator' is in fact neither in all packets, nor a
'forwarding tag'... But I think this makes clear we can't have a term for
each possible combination of naming attributes.

I don't have an immediate suggestion for the solution here. Even if you and I
were to come up with a wonderful set of crisp definitions for 'locator',
'address', etc, there's no way we will be able to get everyone to agree on
them.

I think the best we can all do, when using a term such as 'identifier' or
'locator', is to clearly indicate what we mean by that term, using the various
attributional axes I laid out above - and there are probably other ones I
have missed (in-a-directory/non-in-a-directory, etc, etc).

     Noel