> > 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.
every solution requires some changes. the point is to find a deployable
path to a desirable end-state. whatever solution we come up with, we're going
to have to live with for quite awhile.
> > > 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.
Again, I don't see the inherent desirability of limiting change to transport
if it forces lots of pain on hosts, apps, and operations.
> > > 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.
I don't buy the requirements you've cited for limited-range. IMHO they still
presume too much.
> > > 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.
No, that's your interpretation of those arguments, and I've explained that on
more than one occasion.
> > > 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.
There are lots of problems and lots of circles. But so far I've seen no
compelling reason to separate the problem of providing address stability for
local apps from the problem of providing address stability in general.
> > 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.
Anything that involves ambiguous addresses will cause problems.
Anything that increases reliance on address selection will cause problems.
Anything that makes it easy for limited reach addresses to leak outside
of their routing scope will cause problems.
And the more different ways we have to provide address stability, the
more failure scenarios we're creating.
> > 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.
Well it's not clear that such requirements are valid. Somebody needs to make a
convincing case.
And even if one accepts the need for a separate local stability solution,
this still wouldn't necessarily justify ambiguous addresses or increased
reliance on address selection.
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]
--------------------------------------------------------------------
