Subject: Re: [rrg] Aggregatable EIDs: a summary attempt

From: Lixia Zhang <[email-masked]>
Date: Tue, 12 Jan 2010 10:09:45 -0800

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

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 12 Jan 2010 10:53:46 -0800

after summarizing the main points, I'd also like to clarify the  
following I caught from this thread of exchange:

> there are about 10 times fewer active AS numbers than there are active
> prefixes. So flat-routing on AS numbers would gain one order of  
> magnitude
> immediately.

I've seen similar statement several times by now.  I suppose people  
understand that routing on AS numbers *alone* is not a feasible  
solution.
ASes come in all size and colors.  Some AS could be a small company;  
some other AS can cross multiple continents.  So AS does not represent  
a granularity suited for today's routing needs. Routing on ASes can  
get one reachability, but not performance, load balance, traffic  
engineering etc etc.
(Had we only cared reachability, I bet the DFZ table would not have  
grown so big)

> ......
> Well, until people drop the stupidity of reverse DNS lookup as a  
> "security check" it's very hard to drop this. Of course it's bogus.

I agree that different opinions exist regarding the use of reverse DNS  
lookup, the degree of its effectiveness etc.  But it is undeniable  
that it has been a useful checking in many cases.
And we should not overlook its merit: it got adopted quickly and  
widely because it made use of an existing function.

Lixia

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 14 Jan 2010 17:27:57 +0800

<Skiped>

> widely because it made use of an existing function.

The reverse DNS infrastructure is actually used as the id->locator mapping
system in my RANGI proposal. We are now developing such a mapping system and
will do an experiment on it latter.

A brief introduction of the above mapping system is as follows:

The hierarchical host identifier (HHI) consists of two parts: the leftmost
part is Administrative Domain ID (AD ID), and the rightmost part is Local
Host ID which is the hash of the AD ID and the public key owned by the host.
The structured AD ID is used as a key in the reverse DNS infrastructure to
locate the corresponding DHT ring (or a super server) which maintains
mappings for the identifiers belonging to that Administration Domain, while
the Local Host ID is used as a key in that corresponding DHT ring to locate
the node which holds the mapping for that identifier. Hence, the mapping
system has a reasonable business model and clear trust boundaries.

A detailed example is given as follows:

1. A HHI will be transformed to a FQDN format string. Firstly, a HHI is
expressed as "country-code.authority-code.region-code.local-host-ID" by
inserting dots between adjacent fields, then it is transformed into a FQDN
format string as "local-host-ID.region-code.authority-code.country-code".
2. The FQDN format string is used as a key in the reverse DNS infrastructure
for ID->Locator resolution.
3. DHT can be optionally used to scale the bottom-level authoritative name
servers if necessary, since the Local Host ID part of the HHI is a flat
label.

Best wishes,
Xiaohu