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