My critique: Pro(?): ITU-T will be happy to provide E164 country codes. Con: The political impact: Countries come an go, are formed by unifications and separations. Countries may be shut off from the rest. And: The Istanbul-effect will be well installed - of course not up the the level of continents but up to the level of countries. There are many more disadvantages but shared by all the other proposals. Heiner In einer eMail vom 19.01.2010 08:33:27 Westeuropäische Normalzeit schreibt x...@huawei.com:
> -----邮件原件----- > 发件人: Lixia Zhang [mailto:li...@cs.ucla.edu] > 发送时间: 2010年1月19日 12:23 > 收件人: Xu Xiaohu > 抄送: RRG; Paul Francis > 主题: Re: [rrg] critique of RANGI > > > 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) Yes. To simplify the implementation, we use CGA as host identifier currently. Hence the value of n is set to 64. > > (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 don't want to introduce too many levels in the hierarchy. Hence, in a given administrative domain (e.g., a state or a province), there may be a lot of entries to manage. > I did not following the first sentence below (what do you mean by > using "AD ID as a key"?) A detailed example is given as follows: 1. An AD ID is expressed as "country-code.authority-code.region-code" by inserting dots between adjacent fields, then it is transformed into a FQDN format string as "region-code.authority-code.country-code". 2. The above FQDN format string is used as a key in the reverse DNS infrastructure to locate the corresponding authoritative server or the DHT ring for that AD. If DHT is used to scale the bottom-level authoritative name servers, the Local Host ID part is used as a key to locate the corresponding peer which stores the mapping of that identifier. 3. The Local Host ID part is used as a key to locate the matching mapping entry in the mapping table of the corresponding name server or the corresponding peer. The following figure is a demonstration of the mapping system to be used in RANGI. > > 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 Details about the id/locator mapping system will be included in that draft or described in a separate draft soon. > >> ..... > >> 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? Not sure whether it is a drawback. However, since there is already a global unique host identifier for each host in RANGI, which can be easily used for id->locator lookup, it seems no need to assign each host a unique FQDN. > >> 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? The reason I can thought why ILNP requires each host has a unique FQDN is: the flat EIDs to which the sessions are bound are not suitable for EID->Locator resolution, so another namespace (i.e., FQDN) is referred to. My doubt is how a legacy host continues the communication to an ILNP-aware host once the latter changes its locator due to mobility or re-homing event. Note that the legacy host will not resort the DNS to get the new locator of the ILNP-aware host. > > > >> 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? To be more accurate, the site proxy is similar to LISP ITR while the transit proxy is similar to LISP PTR. Xiaohu > I am trying to identify commonalities among proposals. > > Lixia _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
<<inline: image001.gif>>
_______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
