Keith Moore wrote: > ... > 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.
One address per interface doesn't solve all known problems either. > > > 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. Careful, you are arguing that 38 bits is inadequate space for an industry specific registry... Also, this argument amounts to a claim that the industry can't manage an internal registry, but would be glad to impose its needs on the public registries. > > 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. Didn't you notice the phrase: 'coordinate the SL space when they connect'? If the space is coordinated, it is unambiguous. > 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. This is more an argument for PI than it is against SL. First, routing across a site boundary can't happen if the address space is ambiguous, because the routing protocols don't know how to deal with that. So you are either talking about nat, or a coordinated address space with a boundary router keeping the IGPs separated (a layer 3 area if you will). We won't waste time with the former, and the later does not exibit the application ambiguity problems you are worried about. > the ability of the network > to provide > security in depth is decreased with SLs. Let's stick to technical arguments... > ... > I've already explained why that 'threat' isn't a problem. Yet most enterprise network managers still believe it is. > ... > 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... Shipping code will do more to change behavior than a few lines of text in an RFC. > ... > > 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. This refuses to accept the fact that Rich says they are using them on a connected network without problems. > ... > 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. For the kinds of apps you are interested in, yes PI is where we need to be headed. I doubt we will ever convince people that it is better for some things that SL will get used for. 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] --------------------------------------------------------------------
