> > > 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.
You appear to be trying to make an implication that my arguments are specific to, or focused on, academic networks, and so therefore are narrow and/or less relevant. You're wrong on both counts. > > Lots of apps require stability. The question is, are many of > > those apps inherently confined to a particular subnet? The > > answer is no. > > 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 think the requirement is better stated that apps (not just local apps) continue to operate independent of any normal address change events, whether or not at the SP edge. > I don't understand the point of changing the scenario. I don't understand the point of stating the scenario in narrow terms in order to argue for a problematic solution with limited applicability. > > 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. except when those failures prevent that cash flow. > > > 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. No, but your insistence on SL is having that effect. > The problems you have > raised in the past stem from multi-homing, so stop claiming that a limited > range prefix causes them. I've raised lots of problems regarding scoped addresses, only some of which have to do with multi-homing. Since scoped addresses are being used to justify forcing hosts and apps to rely on address selection (with its inherent problems) to a much greater degree than would otherwise be necessary, it makes sense to focus attention on the dubious assumptions behind scoped addresses. > > 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'. True enough - it's just a question on how large you want to draw the circle. The trick is to draw the circle in such a way that the solutions are inexpensive and work well. Usually this happens somewhere near (though not precisely at) a complexity minimum. > 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. No, it doesn't follow. What you suggest would be reasonable if the various mechanisms were not too costly, did not conflict with one another, and did not preclude development of better solutions. But again, we can solve the local stability problem if there really is a significant use case for it. 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] --------------------------------------------------------------------
