[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Re: Supposed impossibility of scaling for mobility
Robin,
I think that you are misunderstanding my point.
Let me try listing some items I take as givens. Others may disagree.
1) Solving problems that we don't need to solve is going to weaken a
solution. (Good solutions will, as Noel seems to like to put it,
unexpectedly solve additional problems. But that is different for
designing to solve a varied selection of problems all at once.)
2) "Mobility" is not a single problem. In the text I have elided, you
indicate that you specifically mean mobility over 100s or 1,000s of
kilometers. But other folks mean other things. Solving "Mobility" is
almost meaningless, given the range of problems.
2') My personal opinion is that the value in addressing the long range
mobility problem is extremely small. The end station rarely if ever
needs to preserve its connectivity when moving between arbitrary
connectivity points separated by 1,00s of km. There are cases where
special infrastructure and special needs require such, but you cope with
those in other ways. There are cases where local moves are not
topologically local. (And various groups have looked at properties that
help address those cases.)
2'') Yes, mobility can be thought of as just another change. But it has
very different characteristics than the changes caused either by
re-homing or by failure / recovery. So treating it as identical will,
in my opinion, likely hurt both the base solution and the mobility handling.
3) Every approach to a problem has limits. And we should assume that
those limits are going to be lower than we expect. As one member of
this community said to me on many occasions "The difference between
theory and practice is even larger in practice than it is in theory."
[1] And we know from experience which way that difference will go.
So, given that all the solutions will be less capable than we expect,
and given that reducing the problems to be addressed generally gives one
more head-room in any solution, it seems to me to be a really good idea
to NOT solve problems we don't need to solve.
That doesn't mean that we should refrain from looking at interesting
ideas, like your fast-push. It just means that we should evaluate them
against the alternatives for the problems that we need to solve, rather
than choosing a mechanism based on a problem we don't need to deal with.
We have all recognized that the rate*state (or churn, or whatever
characterization matters most) is an important factor in the complexity
of the problem. Mobility, even bounded subsets of the mobility problem,
adds to that measure. So unless there is some driving need, I would
prefer to keep those factors out.
Yours,
Joel M. Halpern
[1] Steve Crocker
Robin Whittle wrote:
Hi Dino and Joel,
In the RRG meeting (audio http://videolab.uoregon.edu/events/ietf/
where there should soon be an archive of Tuesday's meeting) you and
perhaps some other folks were extremely negative about the routing
system, in the form of map-encap, achieving mobility directly. So
much so, that I understand you want mobility not to be a goal.
Yet I believe that a fast-push hybrid push-pull system with reliable
notification from local query servers to ITRs will give users ~5
second latency real-time control over all the world's ITRs. Also,
this system doesn't have the delay or drop problems inherent in pure
pull (LISP-ALT and TRRP), so that's another thing we wouldn't need
to worry about when asking people to adopt it.
You seem very committed to the idea that mobility is impossible to
achieve with map-encap.
...
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg