> Keith Moore wrote: > > ... > > Default address selection doesn't work properly anyway,=20 > > partially because it favors SLs over globals, and partially=20 > > because the idea that you can=20 > > expect a default address selection rule to work in the=20 > > absence of information about the app's requirements, and to=20 > > do the right things with scoped=20 > > 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.
maybe we need to define what is a 'simple app' then for which the 'default' behavior suffices - because it seems to me that far too much faith is being placed in 'default address selection' to address the burden that is imposed by requiring hosts/apps to do address selection in the first place. in other words, just because a set of default rules might work for some apps is not a justification for requiring all apps to implement address selection code that often cannot work well. > 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. first, you make that sound easier than it really is; second, that's not the only difference. its not as easy as you make it out to be because there are industries that involve hundreds or thousands of suppliers (hundreds or thousands of separate sites) that want to make extensive use of private interconnects. it's easier to use non-routable globals than to make coordination of SLs scale to that degree. another difference is that non-routable globals are unambiguous, so that apps that operate across site boundaries aren't required to deal with ambiguous addresses. another difference is that with non-routable globals the app can allow the network to do all of the routing and enforce policy about who can connect to whom - with SLs the app will often have to do routing as site boundaries will not always coincide with boundaries of the application, and therefore any policy about who can talk to whom can only be implemented in the app. the ability of the network to provide security in depth is decreased with SLs. > 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. I don't think paying for an address is a significant issue - the cost of getting an address (without connectivity) should be similar to that of getting a domain name - probably less, since trademark protection shouldn't be an issue for addresses. > 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. I've already explained why that 'threat' isn't a problem. > 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. we agree that a PI space is needed. now if we could just discourage use of SLs so that such apps would be able to run in most networks... > > compare this to the SL case where the app either has to=20 > >=20 > > a) artifically limit connectivity by filtering SLs when it's not sure > > that nodes could connect using them, OR=20 > >=20 > > b) include potentially SLs in referrals=20 > > 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)=20 > > 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. no, it's not even the best we can do in practice assuming we're stuck with SLs. as it is obvious that SLs present many difficulties on many levels of the stack, we really should declare consensus that they should be discouraged except in cases where we know they won't cause problems - like isolated networks - and 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. nobody is trying to 'prevent' the network manager from doing anything - but we would do well to provide such managers with the benefit of our understanding that SLs are not as good an idea as was originaly thought. and yes, let's get a workable PI space established. we seem to agree that this is a better alternative. 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] --------------------------------------------------------------------
