[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fourth alternative [was Re: Moving forward ....]



On Tue, 19 Aug 2003 18:04:05 -0700
"Tony Hain" <alh-ietf@tndh.net> 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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------