[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Possible Identifier Properties



In einer eMail vom 08.07.2008 19:25:36 Westeuropäische Normalzeit schreibt rja@extremenetworks.com:
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.
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.
 
 

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


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
rja@extremenetworks.com