> >example 1: Process A sends the addresses of process B to process C. > >Processes B and C are in different scopes. (Either one might or might > >not share a scope with A.) Process C cannot communicate with process > >B using SLs that it has received from A. > > > >example 2: A sends the addresses of B to C. This time B and C are in > >the same scope, but A does not have access to that scope. If A sends > >the SL addresses of B to C, C can talk to B. However A has no way of > >knowing whether this is the case. If on the other hand A filters SLs > >in addresses that it sends to C (as some have suggested is appropriate), > >C may be unable to talk to B for lack of an address that works, even > >though B and C share an address scope. > > These are generic examples. Please provide me with the name of one of > these apps.
PVM. NetSolve. SNIPE. probably Globus and Legion also. SIP. and for that matter, HTTP if it uses address literals in "moved temporarily" referrals and same-site image loading (which would make page loading *much* faster and more reliable) > * why is A sending the B's IP address to C, why not send the FQDN or some > other name and let C look up the address? because for some cases DNS is inherently too slow, too unreliable, too ambiguous, and/or not widely supported enough to use. DNS query times of several seconds are not unusual, failure rates are much worse than direct use of IP. DNS names are often ambiguous, one name mapping to multiple hosts. DNS names are sometimes scoped so that the same name doesn't have the same meaning everywhere. summary: it's unreasonable to expect all apps to use DNS all of the time. also, pushing the problem to DNS doesn't actually solve the problem, it just defines the solution in terms of another unsolvable problem. > * How is this scenario different from the case where a filter blocks the B > to C communications channel? Wouldn't the app 'see' the same failure > mode? In this case the use of global addresses doesn't help does it? example 2 illustrates why just having nodes refuse to use SLs in referrals does not work in the absence of globals. the app cannot support communication between B and C even though the network permits it, because it has used this filtering rule. > > > I don't mean that it may be hard to for the app to decide which address to > > > use. Yes that's a hard problem, and we don't have a solution to it yet, > > > but that doesn't seem a good enough reason to kill site locals to me. > > > >Standards-track protocols are supposed to have no known technical omissions > >with respect to the requirements placed on them, and are supposed to have > >resolved known issues. An addressing architecture that expects apps to > >solve an unsolved problem that is acknowledged to be difficult doesn't > >seem like it meets either of those criteria. > > Standards track documents are suppose to describe the protocol operation in > enough detail that inter-operable implementations can be written. Where > are the bake-off results that show that scoped addresses present an > unsolvable problem? you've got it wrong. we know there are problems. the burden is on those who think that scoped addresses don't cause problems to demonstrate that they're easily solved. otherwise we don't meet the requirements in 2026. > > > I also don't mean that an app can get confused and it will fail to > > connect to > > > the correct proper destination if it uses a scoped address at the wrong > > > time. Yes this can happen, but it's still part of the address selection > > > problem, not a basic problem with an app. > > > >Address selection doesn't solve this problem. Basically what the app has > >to do is implement its own addressing (so it can disambiguate hosts using > >the same address) and routing (so it can operate across site boundaries - > >because this will be necessary for many apps). > > I don't grog this answer. Address selection policies is precisely the > problem I think you're talking about. no, address selection doesn't solve the problems introduced by SLs. and it can't possibly do so, because the information needed to make the right choice about which address to use is not in general available to the host that is making the selection. > If an app gets a list of addresses > back from a name lookup query it somehow has to order these addresses and > decide which ones to try and in what order. Since a v6 host can have > multiple globally unique addresses or a set of scoped addresses, the app > must have some way of determining which address to use. I would think that > having a know set of scoped prefixes (Global, SL, LL) would make it easier, > instead of harder for the app to start the sorting process. it makes it easier to get incorrect or suboptimal results, yes. it doesn't make it easier to get the right result for that app. 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] --------------------------------------------------------------------
