Subject: Re: [rrg] critique of RANGI

From: [email-masked]
Date: Tue, 19 Jan 2010 06:34:16 EST

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  
[email-masked]:

> -----邮件原件----- 
> 发件人: Lixia Zhang  [mailto:[email-masked]] 
> 发送时间: 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
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg