On Tue, 19 Aug 2003 18:04:05 -0700 "Tony Hain" <[EMAIL PROTECTED]> wrote:
> Erik Nordmark wrote: > > ... > > FWIW, I think a multi6 solution with id/loc separation will > > make the local addressing concerns go away. > > Well a 'solution' might do that, but I don't see one happening in our > lifetimes. Any separation will require a mapping infrastructure to > dynamically bind the values back together. agreed. > Such a mapping infrastructure > will have all of the scaling concerns of DNS, Not clear. Nothing says that the mapping service has to be organized like DNS. It is not inherently necessary (though quite possibly desirable) that assignment of stable IDs be federated similarly to the way address blocks are federated, so that the service can do mapping on a per-block basis rather than a per-address basis. However, there is no inherent reason that the servers that provide the mapping have to be provided by the assignees of those ID blocks. Nor is there any inherent reason that propagation of updates has to be like DNS. > plus the constraint that its > convergence times are extremely short. There is no well-known technology for > running a global multi-master, cross trust boundary, database, with > appropriate caching for scale, and convergence times that are useful for > application failover. What would you call BGP then? Granted, it's not exactly a database, but it's certainly "multi-master" and "cross trust boundary" and it at least attempts to converge within a timeframe in which apps can fail over. I'm not claiming that defining this mapping infrastructure is an easy problem - certainly it is not. However it doesn't seem like a good idea to assume that it needs to look like DNS. If anything, it's precisely because we know the pitfalls of DNS, that we should look for a somewhat different solution. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
