> | okay, I now understand your use case for SLs, though I still think it > | would probably be better to solve that problem by assigning a unique, > | non-publically-routable prefix to each site that asks for one. > > Yes, that would be an alternative - and is much the same as > SL's with site ID's embedded.
right. but you don't have to deal with that extra frob. > Aside from the much touted (but really silly) objection of "who would > assign them" this method has other problems. > > Either way (SL's with ID's, or non-routable globals) gets rid of the > scoping problem. No need to pass scopes around any more - but they're > still needed for LL's. perhaps, but LLs really shouldn't be used except for some very odd cases - I see LL as mostly a way to avoid having to reinvent the same functionality differently for each L2 network. > The global addr model though makes apps lifes more difficult, in that > it is then no longer immediately obvious which addresses are stable, > and which are not. Given two addresses, which should I use if I want > a stable connection (assuming I somehow know that both work) ? I don't think stability is the issue. global addrs need to be reasonably stable (which is to say, on the order of MTBFs for reliable machines) whether or not the prefix is provider-based, topology-based, or assigned to the site. the idea that a prefix can be changed at a whim is just a fantasy. at the same time, apps that need stable connections that last for months really do need to work out mechanisms to recover from address changes, but they'd need to do this even if the addresses were permanent, because within that kind of timeframe, machines get moved, replaced, reassigned, etc anyway. the real issue is that a pre-site prefix is still a limited scope prefix. it might or might not work to reach a different site with a different per-site prefix, depending on whether you have a private connection to that site. so there's still trial-and-failure involved in knowing which address to use, and an app component cannot expect to advertise a single single global address to be reachable from all of its peers if any of those peers are at a site that relies on pre-site prefixes for connectivity (via private agreements). so it still complicates the model that apps have to be written to, though not quite as badly as SLs. but as long as we insist on provider- or topology-based addressing for the public network, I don't see a better way to solve the problem that isolated sites want to interconnect with other sites, than non-routable site-specific address prefixes. and since we cannot insist that everyone connect every host to the internet, distributed apps have to make a decision anyway - either they're only going to work on hosts that are connected to the public internet and have global addresses, or they're going to have to cope with multiple addresses and the possibility that the same address won't work everywhere. but at least we can avoid having addresses whose meaning varies from one place to another, and we can avoid having apps try to guess what addressing realm/scope they're in. > None of this is easy - there is no easy answer (or not that has been > proposed so far). indeed. Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
