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