Subject: [RRG] Possible Identifier Properties

From: RJ Atkinson <[email-masked]>
Date: Tue, 8 Jul 2008 13:24:09 -0400

Earlier, Lixia Zhang wrote:
% BTW here is what I got from other msgs on this thread,
% that is MAC address is not an ideal node ID in the
% strict sense, as it is associated with a specific
% interface, while hosts are increasingly multihomed
% today.

I would suggest that we distinguish carefully between:

A) using a MAC address as an interface-ID [MAC]
A) using a MAC address as a node-ID [MAC]
B) using a MAC address as a handy set of bits
    to use in deriving a node-ID.  [f(MAC)]

% There are really two issues:
% 1/ the need for a unique node ID

Depending on the details of one's design, I do not
think that one necessarily needs a Node-ID to be
absolutely globally-unique.

I do think that it is normally helpful if a Node-ID
is very likely to be unique.

Again, depending on the details of one's design,
I also think it is necessary for a Node-ID to be
unique within the context of some given Locator.

% 2/ an engineering judgment call of whether
%    one could borrow MAC address to serve the
%    above purpose.
%
% 2/ represents an engineering tradeoff
%    because the borrowing saves the trouble
%    of managing another new ID space.

If there were a new identifier space that in no way
derived from any property of the node, this would
create some significant issues:
	- political (e.g. who manages that space ?
                      and under what rules ?)
	- deployment (e.g. getting IDs into systems)
	- other

So I think a very reasonable approach is to use
some MAC that belongs to a node as input to some
function that then generates a Node Identifier.
One could use such a generated Node Identifier
to name the node -- rather than limiting that
Identifier to naming a single interface of the node.

As it happens, IPv6 normally does something pretty
reasonable here, which is to use the MAC address
bits and apply a function to transform them into
an EUI-64.  While current IPv6 uses a different
EUI-64 on each different interface, one could easily
imagine an alternate design where a common EUI-64
were used to name the node (hence a common EUI-64
is used with ALL interfaces).

Cheers,

Ran Atkinson
[email-masked]

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: [email-masked]
Date: Tue, 8 Jul 2008 17:39:05 EDT

In einer eMail vom 08.07.2008 19:25:36 Westeuropäische Normalzeit schreibt  
[email-masked]:

In the case that my design is hereby meant (otherwise ignore this  email):
 
I started out asking for approx. 2 additional octets for the  sake of 
forwarding e.g.from Europe to California without looking at the  dest. address, and 
only thereafter, while evaluating the  dest address, to  get to Sausolito.This 
additional information (it might be viewed or not be  viewed as a Node-Id) 
wouldn' t have been globally unique - of  course  not.
 Later on LISP-folks admitted, that they do not consider LISP being  the 
clean-slate solution for eternity.
But since then, there has been still interest in a so-called  clean-slate 
solution. And also: There has been the discussion about the role of  IPv6 (yes, I 
do envy those IPv6-folks who managed to get 16 octets for the  address, by 
which you can identify any fraction by the million of any  square-millimeter of 
the globe.).
Hence I tried to improve my design such that forwarding hops can be done by  
one single table-lookup even down to the last egress node ( no matter whether  
inter- or intra-domain) - sure, by asking for more than 2 octets. But IPv6 
can  easily cater for the necessary octets. 

So I think a very reasonable  approach is to use
some MAC that belongs to a node as input to  some
function that then generates a Node Identifier.
One could use such  a generated Node Identifier
to name the node -- rather than limiting  that
Identifier to naming a single interface of the node.
Here I am completely lost.Will say: I do not understand why MAC addresses  
come now into play. But I have learnt to be patient.

Cheers,
Heiner

Cheers,

Ran  Atkinson
[email-masked]