-----邮件原件-----
发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 代表 Jari
Arkko
发送时间: 2008年7月23日 22:18
收件人: Dino Farinacci
抄送: [EMAIL PROTECTED]; 'RJ Atkinson'; 'IRTF Routing RG'
主题: Re: [RRG] IEEE EUI-64 as an Identifier format
Dino,
However, you get zero aggregation of ID space with EUI-64
assignments.
Not good for a mapping database.
Yes. But I suspect that wishes about the aggregatability of the ID
space
are similar to past wishes about aggregatability of addresses. I.e.,
wishes that do not necessarily become true.
Well, it came true for LISP using LISP-ALT. But you have to use all
128-bits and not the low-order 64-bits which is random and flat. If
you are flat then there is a mapping entry for every host in the
Internet. Clearly a non-starter.
Note that aggregation of the ID space can come in two ways: ability
to
map range of IDs belonging to an organization vs. ability map an
individual host's ID. I would suggest that we need the former. The
latter would replace current scalability and aggregation problems
with
different scalability and aggregation problems.
Besides of the above mentioned issue, there are also some other
issues with the flat identifier:
1) Burden the control policy configuration.
Since the flat identifier has no hierarchy, it's hard to enforce
identifier-block based security control policy on firewalls. That's
to say, only host granularity access control list is available.
2) Lack of trust and economic model in the id/locator mapping system.
Since these flat identifiers are randomly scattered across the
namespace and stored at essentially random nodes, the id/locator
resolution infrastructure has no "pay-for-your-own" model, unless
the id/locator resolution infrastructure is managed by one and only
one authority.
So I wonder whether the flat identifier is acceptable for the id/
locator split architecture.
Xiaohu Xu
Agree with your points.
Dino
--
to unsubscribe send a message to [EMAIL PROTECTED] 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
