> > there is no justification for the idea that internal-use > > applications have a greater need for stability than other > > applications. > > Not in an academic environment, but when people's jobs are on the line they > tend to set the bar *much* higher.
(Should I counter with a comment about vendors that try to get their customers to invest in shortsighted and inflexible solutions?) > One example of an app that requires > stability is maintaining the multi-$M cash flow through the database backend > to a company's ecommerce app. Lots of apps require stability. The question is, are many of those apps inherently confined to a particular subnet? The answer is no. Now, if those apps are important enough and it turns out that you can make their network more stable by putting them all in the same subnet, you might do so, even if you have to do bridging, VPNs, or whatever to create that illusion. But you're only having to do that because the basic network technology didn't meet your needs. > The bar becomes 'did you do everything you > could with current technology to keep it running?' When the answer is 'no, I > could have put in a NAT to isolate those systems from any external prefix > change', what do you think will happen? It doesn't matter that the IETF > said'nat is bad & crashing applications during a renumber is not a problem', > they will do what they have to before they allow a failure. Yup, they'll do so, until someone with a clue points out that the NATs are actually causing failures and making the network harder to manage. Then the question will be "why did you install this technology which causes our networks to be brittle and inflexible and our applications to fail?" IETF's purpose is not to provide justification for shortsighted practices. > > actually, it's not clear that there is a significant class of > > inherently "internal-use applications". for most things that > > people put into that category (e.g. printing, file access), > > there are significant and valid use cases for running them > > across network boundaries. > > Running them across network boundaries does not invalidate the need for them > to be stable when run internally. Nor does it invalidate the need for them to be stable when running across a network boundary. What you seem to be saying is that (a) the "local apps that need stable addresses" case is so compelling that we need to adopt a solution which we know causes a lot of problems and (b) the requirements of other apps for stable addresses are by comparison so unimportant that we should delay working on that solution and meanwhile add special-case complexity to solve the problem for purely local apps. However if you can identify a significant class of apps that really is inherently local and really has a greater need for address stability than other apps, I can propose a solution to this problem with essentially no impact to apps (especially those that don't need this extra stability), with small impact to hosts and routers, and which doesn't impose the notion of a single "local" scope either. The reason I haven't proposed this yet is because IMHO it doesn't solve the real problem (we need a reasonable degree of address stability for ALL apps), it adds complexity that would be unnecessary if the real problem were solved, and because it would distract energy from efforts to solve the real problem. 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] --------------------------------------------------------------------
