2009/12/29 Xu Xiaohu <[email protected]>: > > >> -----邮件原件----- >> 发件人: [email protected] [mailto:[email protected]] 代表 Joel M. >> Halpern >> 发送时间: 2009年12月27日 3:40 >> 收件人: Brian E Carpenter >> 抄送: [email protected]; wei zhang >> 主题: Re: [rrg] Aggregatable EIDs >> >> Two points of clarification: >> 1) EIDs need to be aggregatable only if they are used as look up keys. >> If they are never the key for a lookup (and some proposals have that >> property) then aggregatability is a non-issue. >> 2) The corollary to 1 is that EIDs only need to be aggregatable in the >> structure in which they are looked up. If they are looked up in the >> routing system, then they need to be topological. If they are looked up >> in something else, then they need to right structure for that something >> else. If the EID is a DNS name, then the DNS structure defines its >> aggregatability. If it is looked up in a binary delegation tree, then >> that defines the structure. If they are looked up in a DHT, and we are >> prepared to mandate a DHT, then again they don't need aggregation >> properties. >> 2') It is very likely that EIDs will have at least delegation oriented >> aggregation, unless we resort to random EID creation. > > I fully agree to the above clarification! > > Then the question is: among the delegation oriented aggregation and the > random creation, which one is the better choice for EIDs? Or do we need a > third option, a compromise between these two options, e.g., one part of the > EID is delegation-oriented aggregatable, while the other part is randomly > created? > > Xiaohu > I agree to differentiate EIDs into different groups (maybe in different mapping systems), not only it is possible with delegation oriented and random, but we can have 'stable" and "mobile" as well ( just like the mobile phone number and wired phone number). There won't be harmful to deploy more than one mapping system in the Internet and most likely scalable for a long run.
Here we are touching the EID fundamental features. I quote RRG's terminology for ID: An identifier is the name of an object at a given layer; identifiers have no topological sensitivity, and do not have to change, even if the object changes its point(s) of attachment within the network topology. Identifiers may have other properties, such as the scope of their uniqueness (local or global (default)), the probability of their uniqueness (statistical or absolute (default)), and their lifetime (ephemeral or permanent (default)). Since there might be contradictory properties why not we put them into different boxes. ID can hardly be changed once it is put in use, why not arrange them properly beforehand. If we hold this to be ture, we may get hierarchical aggregatable delegation EID mapping system(s), mobile/ephemeral random EID with DHT mapping system(s), which of course will not interfere connections between any pair of EIDs. What we need is to draw the demarkation between them and let ITR knows how to map different EIDs. RFC Wei Zhang _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
