On Jan 18, 2010, at 6:47 PM, Xu Xiaohu wrote:
.....
Hi Paul,
I did not know that you were working on RANGI critique; as I
mentioned
to Xiaohu I could do one.
So what I just did now is some minor additions to your text
(1)pointing out that RAGNI ID is 24-byte long,
No, RANGI ID is 16-byte long. The following is a demonstration of
the RANGI
ID.
|<------- n bits --------->|<-- 128-n bits-->|
+--------------------------+-----------------+
| Administrative Domain ID | Local Host ID |
+--------------------------+-----------------+
| \
| \
| \
| \
| \
+-----------+-------------+-------------+
| Country ID| Authority ID| Region ID | <------Example
+-----------+-------------+-------------+
sorry, I missed the "-n" fine print :(
In your RRG presentation at Hiroshima, the slide says n=64. if that
is still the case, then your local hostID would have the same length
as ILNP EID (though the latter requires global uniqueness, and I
suppose yours not)
(2)doing ID looking
using DHT raises trust issue;
In fact, we use the reverse DNS infrastructure as the id/locator
mapping
system, while the DHT is optionally used at the bottom level of this
infrastructure to make the authoritative server scale better.
The Hiroshima RRG talk showed the other way around ...
This is my
assumption of a hierarchical DHT. IMHO, the hierarchical DHT doesn't
mean
DHT should be used in each level.
DHT is used for lookups for systems with very large number of entries.
With a hierarchical system, where the bottom level is not that big, I
wonder what is the value of using DHT in the first place.
I did not following the first sentence below (what do you mean by
using "AD ID as a key"?)
The structured AD ID is used as a key in the reverse DNS
infrastructure to
locate the corresponding super authoritative server (or the
corresponding
DHT ring when using DHT to make the authoritative server scale
better) which
maintains mappings for the identifiers belonging to that
Administration
Domain. If DHT is used to scale the authoritative server, the Local
Host ID
(flat label) is then used as a key in that corresponding DHT ring to
locate
the node which holds the mapping for that identifier. Hence, this
mapping
system has reasonable business model and clear trust boundaries.
Wonder if you have this described somewhere?
I did not find it in http://tools.ietf.org/id/draft-xu-rangi-01.txt
.....
RANGI critique
......
More thought is
needed as to what constitutes these levels, and what is the trust
relation among the ID-Locator resolution servers that use DHT for
lookup.
The RANGI draft suggests FQDN->ID lookup through DNS, and separately
an ID->locator lookup which may be DNS or may be something else.
This
Yes, the reverse DNS is used as an ID->locator mapping system in
RANGI, with
this approach there is no need for every host to have a unique FQDN.
this sounds like as if having a FQDN for each host a drawback?
represents additional cost compared to ILNP design where FQDN lookup
produces both ID and locators. Can one quantify the gain by one
additional lookup to justify the cost?
Yes, I know. However, ILNP design requires that every host should
have a
unique FQDN for ID and locator lookup.
could you elaborate what may be the problem with this as you see?
.....
Unfortunately the early-adopter incentive for host upgrade strikes me
as weak at best.
We have the RANGI-PROXY [I-D.draft-xu-rangi-proxy-01] mechanisms
with which
legacy hosts could initiate communications to RANGI-aware hosts, and
vice
verse.
Is it fair to say that RANGI-PROXY is a similar idea to LISP's PTRs?
I am trying to identify commonalities among proposals.
Lixia
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
