Dear Keith, Sorry I couldn't respond earlier (if, that is, a response was expected). On Thu 2002.11.07, Keith Moore wrote: > problem is, if you keep the same API, then apps that depend on that API > will expect that the name space has the same characteristics as DNS, > (benefits and shortcomings and everything else). so for instance they > will still try to bypass DNS when DNS would have been a poor choice for > them. > > even if the resulting architecture makes more sense than the old one, > you can't expect to be compatible with existing apps if you significantly > change how the services that were accessed by those APIs work. The essence of my thesis is as follows: - A namespace suffices as the end to end primary/effective address space in itself - no lower level or manually set up destination labels are necessary to define names. A distributed name tree is itself an effective addressing mechanism, and provides default end to end routes by up-and-down treewalk. (Of course it wouldn't be optimal, hold your horses. Let's start with a Pascal-like simplification at the high level for once, and treat the practical/optimal/efficient/whatever routing as a separate implementational/compiler/route-translation problem.) - Fixed length numeric addresses (FLNA) for routing, as in IP, can be automatically assigned and reassigned to the names for non-triangular/efficient/etc. routing, so long as * an end to end primary EA space remains available for datagrams and new connections; * ongoing connected sessions are switched over transparently, but this, as in Snoeren/Balakrishnan's paper for TCP, should be treated as an individual protocol level issue rather than an address space and management issue. Note: I prefer the terms 'allocation' and 'assignment' for FLNA because these terms are already used broadly in automated software like OS's and device drivers for things like real memory/IO/bus addresses and interrupts. 'Renumbering' appears to be special to IP and connotes two things: (a) that a human agent must be involved in deciding and effecting it, and (b) that the connected universe constitutes a single numeric label space. This is undue baggage that would limit reconsideration of the assumptions currently made for IP, as will be clear from the next bullet. (In fact, (b) is not even physically sound on the unlimited scale that I allow for.) - Notice that: * Routing with FLNA can and would be done using automatic route discovery, within each FLNA space, which ensures *independence* of the FLNA-based actual routes from the namespace structure. * Since every FLNA space involves management and FLNA are reflected in routing tables, each FLNA represents *networking state*. * We do not need, and in fact do not use a single FLNA today. VPNs are FLNAs stacked vertically because of the end to end paradigm we have been following philosophically. NAT gateways illustrate horizontal tiling of FLNA spaces, although in conventional NAT, the FLNA spaces overlap (over 192.168 etc. private network ranges) and are not disjoint. Using virtual path style state representation in the gateways can yield the same level of connectivity for the same state volume, with the essential difference that the address will now be faked both ways making the client space disjoint. Secondary issues like how the traffic will distribute across gateways concerns distribution of the state across gateways. This has been in effect shown for IP-like FLNAs in IPNL, and primary difference in going to 2-way NAT or virtual paths is the signalling/initialization mechanism for the state set up, not its resulting volume. In other words, virtual path/circuit state represents horizontal tiling form of network state - there's no getting away from state altogether, only how much we keep horizontal and how much vertical. To compare, IPNL describes a limited form of tiling. * Given the state equivalence and the availability of an end to end EA in the form of names, which applications already have to consult every so often (from what I seem to recall reading, netscape caps the ttl to 15 mins regardless of what the dns said), there is no reason to continue mandating end-to-endness of an FLNA, which means vertical stacking only as in VPNs. - Within an FLNA space, the route translation problem from namespace to non-triangular/efficient/optimal/ best-effort-but-better-than-Prasad's-namespace/ whatever-you-want-to-do routes reduces to the name->FLNA problem which is the DNS. This essentially answers your comment above. However, the treatment is now more general than the current IETF/IRTF/IP vision: Section 2 of my thesis describes linkage of the local DNS-equivalent namespaces across FLNA spaces, provide the default "Prasad's stupid routes" (PSR) defined by the namespace treewalks. Section 3.2 describes IP-like datagram routing across FLNA spaces and Section 3.3 describes route discovery and connection state setup across FLNAs. The latter routes need to partially dependent on PSRs, but only on the unlimited scale allowed by horizontal tiling, because of very basic rules of logic and physics, as explained in Section 1.1. On any finite scale, however, the routing would reduce to being independent and IP-like. - Lastly, I haven't considered variable length numeric addresses (VLNA) other than referring to the Nimrod. The only practical application that I can recall is the worm routing in IBM's SP switch fabric, and the scarcity of examples makes me a bit wary. In any case, the namespace is in principle of variable length (ignoring the pragmatic limits set in the dns), and the combination of namespace EA and horizontal tiling of FLNA transports like IP seem to achieve the same thing. There seems to be little motivation for an VLNA solely as transport, and none, imho, as EA other than as textual names. > > It's so frustrating to work alone and become unable to communicate, even > > if it lightens the inertia to make great leaps quietly :( > > agreed. thanks ;-) -prasad.