Keith Moore wrote: > > > 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?)
You won't even accept my agreement that academic networks have a 'lack of need' in the same class as those with $M's at stake. > > > 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. I never said this was confined to a particular subnet, just that the addresses had to be stable independent of any events at the SP edge. I don't understand the point of changing the scenario. > > > 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?" That has happened, and the answer 'because it is the only current way to preserve n$M incoming cash flow' will always beat out other application failures. Give them a stable address independent of SP, and the arguments about application failure have a chance. > > 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. I never said delay working on alternatives. In fact the part you cut off was about the effort I have been putting in for awhile now. FUD like 'a lot of problems' is causing more delay than anything else. The problems you have raised in the past stem from multi-homing, so stop claiming that a limited range prefix causes them. > > 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. Which is the ultimate failure here, there is no single 'real problem'. The limited-range document describes a set of requirements (read that: real problems), and there are probably more. In keeping, there is no single 'real solution'. Manual configured filtering of PA meets one set of needs, auto-configuration of limited range prefixes meets another set of needs, PI meets yet another set of needs, and these sets of needs all overlap in different ways. Rather than persist with FUD to prevent one set of problems from being solved, we need to get on with defining and deploying the mechansims to solve each of them. 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] --------------------------------------------------------------------
