sorry folks for a long absence on this list. Now that family emergency
is over I'm catching up here by going through the archive by subject
line.
under "Aggregatable EIDs" people brought up several issues, mainly (as
I see):
1/ whether EIDs are allocated in some "hierarchy" way
2/ whether EIDs are used for lookups
3/ whether geo-location information can be part of IP address and used
for routing purpose.
I will send a separate msg for the 3rd issue.
Joel made a great comment regarding the first two issues:
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.
and to that last point, Tony also added that, "At the very least, ANY
large name space needs to be managed, and that management needs to be
hierarchical to scale."
My summary after seeing all the exchanges:
- Yes any large name space needs to be managed, and management means
hierarchical structure at certain scope.
- Exact how loose/tight the scope may be depends on the intended use.
e.g. the US's SSN (social security number) system could be an example
of a rather loose hierarchy. If I guessed right: it assigns big chunk
of numbers to each state->county, and people move freely no matter
whether they got their SSN. But it does not need real time lookup
(e.g. within sub-second), as we do.
Maybe ILNP would fit a similarly loose EID management? As ILNP uses
DNS, not EID for realtime look.
- It seems to me that most posts implied that this "EID" would be used
for lookup, even though it is not explicitly stated each time.
from Xiaohu's many posts: there is a management issue associated with
this mapping/lookup services, including concerns about (1) cost for
running the service, who runs and who pays; (2) quality control for
the service, who cares and how much control he gets, and (3) the
critical dependancy of network service on this lookup. My
understanding for his push for a hierarchical EID is to have
identified, authorized, responsible parties to provide this critical
lookup service with high performance and efficiency.
- So as one sees from my above reasoning, the need for a hierarchical
EID system is dependent on individual solution proposals. It is not a
general requirement. It is up to how EID is used in a solution.
Lixia
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
