Keith Moore wrote: > ... > Default address selection doesn't work properly anyway, > partially because it favors SLs over globals, and partially > because the idea that you can > expect a default address selection rule to work in the > absence of information about the app's requirements, and to > do the right things with scoped > addresses, is naive.
You appear to be skipping past the word 'default'. When an app has explicit requirements, it should not expect some default behavior underneath it to do the right thing. The point is that the majority of simple apps don't need to worry about this, because the stack can do the right thing for them. For the complex app, it will need to exercise its own address management rules in any case. > > > and because of Keith's > > issue of distributed apps that do referrals - those apps > wouldn't be > > able to distinguish the two kinds of addresses to do the > right thing. > > sure they would be able to distinguish them, because the prefix would > be standardized. however "the right thing" is simply to favor > routable globals over non-routable globals but to try all of > them - that way, if two nodes don't manage to connect, it's > either because > the net is broken or the net is prohibiting the connection - > either way it's beyond the the app's control. the app is > able to do everything that can possibly be done and with > almost zero additional complexity. The only difference between the non-routable globals and SL is the need for sites without routable global prefixes to coordinate the SL space when they connect. In the end, any prefix that is not in the global Internet routing table could be used as you describe, but disconnected sites want a prefix without paying a service provider for one, and connected sites don't want to pay for a second one and have to worry about it mistakenly being routed at some point. If we had a PI address mechansim, we could avoid the payment issue, but that would not remove the routability issue. The only way to technically reduce that threat is for the table to contain an ambiguous value. Something a provider might even be willing to intentionally black-hole as a value-added service. There are other fundemental business reasons we need a PI space. To help us take the fear out of routing table bloat, Michel and I have taken different approaches to define a PI space. If we get there, that space would make more sense for the multi-party app than SL, since it would otherwise would appear to be just another global prefix. > > compare this to the SL case where the app either has to > > a) artifically limit connectivity by filtering SLs when it's not sure > that nodes could connect using them, OR > > b) include potentially SLs in referrals > define an addressing scheme for all nodes used by the app > whenever connecting to an SL address check to see whether you're > really connecting to the node you think you're connecting to > and perhaps implement routing across SL boundaries for the case > where the customer demands that the app support it > (which is quite often the case - people do expect apps to work > across site boundaries) As I said, this is the basis of a BCP. I know you don't like the idea that it is the best we can do today in practice, but that is reality so let's move on. Rather than waste time trying to prevent a network manager from doing what he insists on doing, why don't we put the effort into getting a workable PI address space established so we can show an alternative with greater value. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
