Keith Moore wrote:
> ...
> 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.
Nice goal, but requires changes to transport to pull it off. The point is to
deliver service long before that will happen.
>
> > 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.
To bound the problem space to something that can be accomplished without
changes to transport. Yes it has limited applicability, but that is not a
failure, and the problems only arise when the mechanism is used outside the
scenario. For those cases, there are other mechanisms.
> ...
> > I never said delay working on alternatives.
>
> No, but your insistence on SL is having that effect.
Clearly you are not reading the documents or the mail carefully. I am not
insisting on SL. The Hinden draft is not SL, and meets the requirements that
have been raised for limited-range.
>
> > 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.
>From my recollection, the ones that are not due to multi-homing are simply
wishes that filtering in the network would go away.
>
> > > 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.
Again you are looking for a single solution ('the circle'). There are
multiple options here and they solve different problem sets. If we really
were forced to come up with a single solution, we will be back at nat as the
lowest common denominator.
>
> > 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.
Nothing here conflicts with or prevents other solutions. The fact that a
limited range address space exists and is used in some networks does not at
all impact an individual network manager from using manual configuration
from a different prefix space. If a PI approach existed, it would not
preclude use (or meet the need) of another space that is known to be
excluded from the global routing tables. The only thing that is preventing
development of 'better' solutions is spending time trying to kill ones that
are achievable in realistic timeframes. If by some magic a killer solution
to all the problems showed up, it would easily push the complexity of
multiple solutions out of the market. We can't be sitting around waiting
until the magic happens.
>
> But again, we can solve the local stability problem if there
> really is a significant use case for it.
So solve the requirements and there will not be a need for other approaches.
Until then, this filibuster is delaying network managers from deploying IPv6
in a way that will meet their requirements.
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]
--------------------------------------------------------------------
