Subject: [RAM] revised draft proposed definitions

From: RJ Atkinson <[email-masked]>
Date: Mon, 11 Jun 2007 10:13:44 -0400

Here is a revised draft proposal for terminology,
with the goal being greater clarity of communication.  This
is still not fully cooked yet.  No terminology will be perfect;
the goal here is to come up with something that most folks can
tolerate and that is "good enough" to clarify our discussions
(here and in related fora such as the IRTF Routing RG).

	Thanks to Dino, Scott, and Joel for their offlist feedback,
some of which is reflected below.

	One good question raised off-list is how to classify
an IEEE MAC in this terminology.  On the one hand, an IEEE MAC
does not really have any location embedded inside it.  IEEE MAC
values belong to the end system interface and remain constant
even if the interface's point of attachment changes (i.e. the end
system moves location), so they could be called an Identifier.
An IEEE MAC contains several items of information [Manufacturer
prefix + scope bit (global/local) + multicast/unicast bit +
end system value].  The "end system value" indirectly might imply
when the system was manufactured, but is otherwise entirely opaque.
On the other hand, the IEEE MAC is used directly (feed a Destination
MAC  into a table and get back which I/O port(s) to transmit
it upon) to bridge frames within a layer-2 infrastructure.

Yours,

Ran

Identifier:	An object that is used only for identification,
		never for forwarding packets or determining location.

		Identifiers might exist at different protocol layers.
		For example, a fully-qualified domain name is one
		sort of Identifier.  The EUI-64 in the low-order
		bits of an IPv6 address might be an Identifier,
		for example in an proposed protocol of the "8+8" class,
		though that would be a different kind of identifier
		than an FQDN.

ID:		Abbreviation for Identifier.  See "Identifier" entry.

Locator:	An object that is used only for forwarding packets
		or determining location, never for identification.

Address:	An object that with mixed semantics, where it is
		sometimes used for identity and sometimes used
		for packet forwarding.  Examples include, but are
		not limited to, IP addresses, which are sometimes
		used to forward packets and sometimes used for
		node identity (e.g. in TCP session state).

LISP RLOC:	An object used for forwarding packets in the
		LISP protocol proposal.  This is typically for
		forwarding outside of an edge site.

LISP EID:	An object that has scoped location semantics
		(e.g. used for location when inside an edge site)
		and has end-to-end identity semantics.
		Since it has mixed semantics, this is a kind of
		address, rather than being a pure identifier.

Scoped Locator:	A locator that has non-global scope.  Note that
		a scoped locator only has location semantics,
		never identification semantics.

Scoped Identifier:  An identifier with non-global scope.  Note that
		a scoped identifier only has identity semantics,
		never location semantics.

Identity:	A possible property of an object.  Addresses and
		Identifiers are examples of objects that have
		identity semantics.  Identity can exist at multiple
		protocol layers.  One might compose a transport-
		layer identity from an IP address and a TCP port
		number or from a node identifier and a TCP port
		number -- for example.

Location:	A possible property of an object.  Addresses and
		Locators are examples of objects that have
		location semantics.   Location also can exist
		at multiple protocol layers; most notably,
		a node typically has both a link-layer location
		and a congruent but distinct network-layer location
		at a given instant in time.

Identifier/Locator split:	A class of network protocol that
		has no addresses, and only has (pure) identifiers
		and (pure) locators.  Proposals in the GSE/8+8
		class of solution might be examples of this,
		depending on the details of the proposal.

Multi-Address split:		A class of network protocol where
		one type of address is used for forwarding in one
		portion of the internetwork and a different type
		of address is used for forwarding in a different
		portion of the internetwork.  Simple NAT is not
		an example of a multi-address split, since the
		same *type* of address (IPv4 xor IPv6) is used
		in all routing domains.  LISP might be an example
		of a Multi-Address split.

EOF

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 11 Jun 2007 16:27:56 +0100

Hi Ran,

I'd like to think that we all get it.  Perhaps I'm wrong.  Here are some 

>         never for forwarding packets or determining location.
Just as a matter of principle, I think it's best to define what these 
things are, rather than what they're not.  Never is a long time, and 
quite frankly it's not very descriptive.  Better to say something like, 
"An identifier [or the thing it identifies] may change its location at 
any time, and may in fact be present in multiple locations."

>         or determining location, never for identification.

Same comment only in reverse ;-)  "A locator denotes presence at a 
specific point in the network.  When one's location within a network 
changes, one locator changes".

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 11 Jun 2007 16:27:56 +0100

Hi Ran,

Eliot

---

From: Tony Li <[email-masked]>
Date: Mon, 11 Jun 2007 13:05:56 -0700

On Jun 11, 2007, at 8:27 AM, Eliot Lear wrote:

> Just as a matter of principle, I think it's best to define what  
> these things are, rather than what they're not.  Never is a long  
> time, and quite frankly it's not very descriptive.  Better to say  
> something like, "An identifier [or the thing it identifies] may  
> change its location at any time, and may in fact be present in  
> multiple locations."

That still fails the test of describing what things are.  What we  
want is to take a constructive approach:

An identifier is an element of a namespace.  There is a 1:1 mapping  
between the namespace and the entities being enumerated.

> specific point in the network.  When one's location within a  
> network changes, one locator changes".

Ok, but a locator does NOT denote reachability.  Thus, a locator is a  
string of bits that indicates a topological location.

Tony

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 11 Jun 2007 22:30:28 +0200

On Mon, Jun 11, 2007 at 10:13:44AM -0400,
 RJ Atkinson <[email-masked]> wrote 

> 	Here is a revised draft proposal for terminology,

I understand better when there are examples so let me suggest some and
RAM people will tell me if I understood properly or if I'm completely
and hopelessly lost.

> 		sort of Identifier. 

OK

> 		or determining location, never for identification.

I was not able to find an example of a global locator, in the current
IETF standards. Does anyone have an existing example?

> 		never identification semantics.

A MPLS label is a scoped locator. Am I right?
 
> 		never location semantics.

A non-qualified domain name is OK for a scoped identifier? Or a Local
Scope Identifier (LSI) (RFC 4423)?
 
> 		depending on the details of the proposal.

HIP too, no?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jun 2007 10:33:23 +0200

On 2007-06-11 22:30, Stephane Bortzmeyer wrote:
...
> IETF standards. Does anyone have an existing example?

I would have thought that a global-scope IPv6 address under a PA
prefix is certainly intended to be a global locator.

Before RFC 1597, I understood all IPv4 addresses to be intended to
be global locators.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jun 2007 10:38:16 +0200

On 2007-06-11 22:05, Tony Li wrote:
...
> That still fails the test of describing what things are.  What we want 
> is to take a constructive approach:
> 

It seems relevant to paste in the definitions I use in
draft-carpenter-idloc-map-cons. I strongly agree with Tony that
we must relate the notion of ID to a specific namespace. We may
differ slightly on Loc:

    Locator: A binary quantity (not necessarily an IP Address) that can
    be used by a routing or forwarding device to decide where to send a
    packet.

    Identifier: A binary quantity (not necessarily an IP Address) that
    can be used by a Stack "A" to uniquely identify another Stack "B"
    both for bilateral communication and for informing a third Stack "C"
    that it should communicate with Stack "B".  (Note that there is an
    assumption in this definition that a Stack is the entity we require
    to identify; in this era of virtualized servers with failover
    capabilities, and of mobile clients, this seems to be a reasonable
    assumption.)

    Namespace: a set of natural numbers, each of which is referred to as
    a name.  Since it is a set, by definition each name is unique and
    thus the namespace is unambiguous.  Locators and Identifiers must
    belong to specific namespaces.

    Namespace Context: the context within which a given namespace retains
    its uniqueness property.  (For example, the Namespace Context of the
    Namespace created by [RFC1918] is a single Internet site.)

       Brian

---

From: Russ White <[email-masked]>
Date: Tue, 12 Jun 2007 06:58:18 -0400

> string of bits that indicates a topological location.

I think we should, perhaps, leave reachability out? It seems like both a
locator and and id indicate some element of reachability (?). IE, if you
have a locator, and no ID, then there is nothing to reach, but if you
have an id, and no locator, there is no place to reach it at.

I don't see an easy way to separate these two concepts?

:-)

Russ

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

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 12 Jun 2007 08:14:39 -0400

On  12 Jun 2007, at 06:58, Russ White wrote:
> Earlier, someone else said:
>> Ok, but a locator does NOT denote reachability.  Thus,
>> a locator is a string of bits that indicates a topological
>> location.
>
> I think we should, perhaps, leave reachability out? It seems
> like both a locator and and id indicate some element of  
> reachability (?).

Neither indicates reachability.

> IE, if you have a locator, and no ID, then there is nothing to reach,

The locator might name a subnetwork, for example.  That subnetwork
might well be reachable or might not be reachable.

> but if you have an id, and no locator, there is no place to reach  
> it at.

Then one can name the node, but one doesn't know where the
node is located, (even if it happens to be reachable at that
instant in time at some specific location).

The original quote at top is correct.  Having a locator does not
mean that there is a working forwarding path between one's
current location and the location named by that original loocator.
Purely as an example, an ACL somewhere along the path might
cause one's packets towards that location to be dropped.

Ran

---

From: JFC Morfin <[email-masked]>
Date: Tue, 12 Jun 2007 12:57:45 +0200

Brian,
Tony said "a string of bits", this seems adequate.

I am not sure that you want an address to always be binary. I start 
working on multilingual semantic addressing support in relation with 
the cctags (they actually root national linguistic relational spaces 
taxonomies, as in a some more granular way the langtags do, from a 
linguistic POV). These addresses are not binary. They are not used to 
route through the network (at least now), but they can locally to the 
destination.

If you consider HTTP.1.1 it supports binary (network) and non-binary 
(virtual host) addresses collapsing naming and addressing space at 
local level into a single space. This is something you may not wish, 
but this is something possible and being used.

Also, just remember that multi-level naming (one can use for 
multilevel semantic addressing and multilevel IP addressing, must be 
self-similar (another way to say it must scale)). However, 
"self-similar" makes clearer that this can be up/down scalarity. And 
therefore, since the current binary/semantic syntax is something 
being used, which works correctly, and will therefore be used, so you 
must stay compatible with it.

jfcm

On 10:38 12/06/2007, Brian E Carpenter said:
>Content-Transfer-Encoding: 7bit
>
>>Ok, but a locator does NOT denote reachability.  Thus, a locator is 
>>a string of bits that indicates a topological location.
>

---

From: Scott W Brim <[email-masked]>
Date: Tue, 12 Jun 2007 08:59:10 -0400

> IETF standards. Does anyone have an existing example?

If your objection is because of NAT, then I have to agree that you
cannot *know* if a locator is global in scope, although things work
better if they are.

> A MPLS label is a scoped locator. Am I right?

Connection-oriented packet switching is a very different sort of
beast.  I think we should restrict this discussion to connectionless.
 What a label does is it selects how the packet should be processed
next.

>> 		depending on the details of the proposal.

Yes, HITs are identifiers (not identities :-p)

---

From: Russ White <[email-masked]>
Date: Tue, 12 Jun 2007 09:07:09 -0400

>> like both a locator and and id indicate some element of reachability (?).
> 

> cause one's packets towards that location to be dropped.

So, your basic argument is that because you may, at times, have a
locator and an id, and the device might still not be reachable, you can
never say locators or id's carry reachability information? That seems to
be stretching it a bit--if some of b is not contained in a, then none of
b must be contained in a.

If a locator/id pair never contains reachability, then reachability is a
mythological creature, and the Internet fails. The exception does not
rule out the general case.

An ID is useless for reaching a device without a locator, hence a
locator must be present to reach the device, hence a locator carries
some type of reachability information. If a locator didn't carry
reachability information, it wouldn't be required to reach a device. At
the same time, locator is useless for reaching a device without an ID.
Hence, and ID must be present to reach a device. If an ID didn't carry
any sort of reachability information, it wouldn't be required to reach
the device, hence an ID must carry some form of reachability information.

You may redefine "reachability," so there are two different types of
this beast, but if you can't reach something without a specific piece of
information, that specific piece of information carries reachability as
part of it's meaning.

Unless, of course.... You're going to propose a third, and completely
different thing, which doesn't exist in the routing context at all
today, a "reachability advertisement." This would have a "reachable
through this path" bit of some type, which says that not only does the
device exist, it is also reachable along a specific path. Since IP
networks are hop by hop, and not session oriented, the idea of a "path,"
itself, within IP, is rather ambiguous, and hence, such and
advertisement would be problematic, at best.

:-)

Russ

- --

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Jun 2007 15:44:35 +0200

On Tue, Jun 12, 2007 at 08:59:10AM -0400,
 Scott W Brim <[email-masked]> wrote 
 a message of 31 lines which said:

> > I was not able to find an example of a global locator, in the
> > current IETF standards. Does anyone have an existing example?
> 
> If your objection is because of NAT, 

No, it is independant of NAT. I said that, currently, it seems that
global "pure" locators (those that are never used for identification)
do not exist in the IETF world. (And, even outside of the IETF realm,
I have trouble naming even one. Street addresses? Longitude/latitude
coordinates for your favorite ICBM?)

> beast.  I think we should restrict this discussion to

You define MPLS as connection-oriented? This surprises me.

> Yes, HITs are identifiers (not identities :-p)

The question is not about HITs but about HIP (the protocol). Under the
above definition, is HIP a good example of a "Identifier/Locator
split"? (I would say yes.)

---

From: Tony Li <[email-masked]>
Date: Tue, 12 Jun 2007 11:21:35 -0700

Brian,

I have a minor quibble with this, in that it's really defining a  
stack identifier, not a generic identifier.

Any given proposal may choose to have identifiers at many levels  
(e.g. transport connection identifiers, interface identifiers, host  
identifiers, etc.) and the definition needs to either be sufficiently  
abstract so as to encompass all of these, or the term being defined  
needs to be qualified.

Tony