RE: Thinking differently about names and addresses

["Tony Hain" <[e-mail]>]

Dave Crocker wrote:
> TH>  The discussions on the multi6 mail list
> TH> have basically been about how the routing community believes the 
> TH> address is the topology locator, while your & Dave's 
> comments show 
> TH> the app community believes it is an identifier.
> 
> By definition, an address is a topology indicator.  Always.
> 
> The point that I was trying to make is that the uniqueness of 
> an address's bits permits its use as an uninterrupted label, 
> ie, a name. (Up a few layers, this is the basis for including 
> URL's in the set of
> URI's.)

And my point is that when you take that uninterpreted label out of its
context of uniqueness, it can't be used as a meaningful name. The real
problem that the app community has with 1918 & SL is that they validly
want a single namespace, but they also want to insist on using addresses
as names. The disjoint nature of the deployed address space precludes
both of those actions at the same time. 

> 
> So this is not about competing definitions of the bits, but 
> different USES of them.  IP needs to interpret those bits.  
> Hence, it MUST handle them as topological indicators.  Apps 
> that use IP addresses use them as simple labels.

Which I would call competing definitions, but that is not the point.
What the app community is indirectly saying is that we use topology
locators as names, we have to have a single rooted name space, therefore
the locators have to point at a unified topology. The reality of
deployed networks is that there will be routing filters, therefore we
have a disjoint views of the address space. In addition, the app
community expects their use of the topology locator as a name to be
stable over a long period, while the routing community wants the
flexibility to change the locator as needed for significant* topology
changes. These 'USES' are clearly at odds.

* I define significant in this context as disruption of an ISP/customer
interconnect, that would cause a prefix to become unusable. These are
relatively infrequent in relation to overall topology changes, but more
frequent than current procedures for DNS changes.

> 
> 
> TH>  Where the two communities agree
> TH> is that the DNS as currently deployed and operated is not 
> up to the 
> TH> task of handling the identifier role. My point is that 
> this is due 
> TH> more to implementation & operation than architecture.
> 
> Responding to this point takes us into the world of 
> solutions. I suspect we will all find this topic more 
> productive (and probably more pleasant) when we move into that mode.
> 
> 
> TH> Also I believe the multi6
> TH> discussion about creating a new identifier, to get the 
> app community 
> TH> to stop camping on the topology locator, will end up creating a 
> TH> distributed database infrastructure almost identical to DNS. We 
> TH> don't need two of those, so we should fix DNS.
> 
> That was my own view roughly 10 years ago, when Noel Chiappa 
> was pushing for use of an end-point identifier, as part of 
> what is now IPv6.
> 
> At this stage, I would want to hear the requirements (or 
> probably better, the desired usage scenarios) before being 
> certain that a modified DNS is the answer.

We agree that we need to understand the requirements before starting on
a design.

> 
> 
> TH> I disagree with the perspective that subnetting or CIDR 
> changed the 
> TH> character of the address.
> 
> Before:  IP addresses contained no topological information.
> 
> After:   IP addresses contained quite a bit of topological information
> AND that information was (is) used quite heavily.
> 
> A change that permits a routing table to be reduced massively 
> necessarily involves changing the character of something.
> 

You cut off the significant part. Since at least RFC 791, IP addresses
have always indicated the topology significance of local or remote
networks. What subnetting did was add structure as the definition of
'local' was reduced in geographic scope. What CIDR did was add structure
to the network identifier part to reduce the effort of finding the
proper next hop as the number of remote networks grew. Neither of those
acts changed the architectural nature of the address, just the bit
positions.  

Clearly the app community has taken advantage of using the 'where'
identifier as a 'what' identifier. This worked fine until ~1987 when
people started putting in routing filters which fragmented views of the
'where' space. The fragmented views became more widespread as sites that
had squatted on unallocated space interconnected without injecting
global routes. With 1597/1918, the fragmentation was formalized and the
market demand for squatting disappeared. What the anti-SL camp is
arguing is that if we only take one step back, we will rid ourselves of
the problem of fragmented views. What they miss is that reintroduces the
market demand for squatting, because we offer no alternative, as well as
the point that it doesn't really remove the original issue of filtering
causing differing views. 

We really need a big-picture perspective here before any knee-jerk
reactions. I have one alternative for how to preallocate space to deal
with the squatting issue, but even that doesn't solve the disconnect
between the app community view of a unified 'where' space to be used as
'whats', when the network managers will continue to install route
filters and fragment the 'where' space. 

Tony