Hi all, In my attempt to answer Lixia’s question why using FQDN for ID and Locator lookup is a problem (see the following email), I occasionally found a doubt about ILNP. That 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 is not that intelligent so as to resort the DNS to get the new locator of the ILNP-aware host.
Could someone please tell me which ILNP draft or paper describes the approach to the above issue? Best wishes, Xiaohu ________________________________________ 发件人: Xu Xiaohu [mailto:x...@huawei.com] 发送时间: 2010年1月19日 15:33 收件人: 'Lixia Zhang' 抄送: 'RRG'; 'Paul Francis' 主题: re: [rrg] critique of RANGI > -----邮件原件----- > 发件人: 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
