Noel,
Sorry for the delay.
Curtis
In message <200204172320.TAA05392@ginger.lcs.mit.edu>, "J. Noel Chiappa" writes
:
> > From: Curtis Villamizar <curtis@workhorse.fictitious.org>
>
> > When we talk about mobility, based on the discussions we've been
> > hearing on this list, we could be trying to solve one of three
> > practical problem
>
> I like this taxonomy. A couple of comments/questions:
>
>
> > 1. Very long time scale mobility. A prefix changes the provider
> > that they use.
>
> By "prefix" here, you mean "chunk of topology", right? (Since presumably as
> part of moving they wind up with a new prefix.)
No. They take their numbers with them. This is not what we'd like
them to do but small providers insist that they can't ask all of their
customers to simultaneously renumber and I they are correct in that
assertion.
> > 2. Medium time scale mobility. There are two flavors of this.
> > ...
> > 3. Short time scale mobility. Again two flavors.
>
> I don't see the difference between these two, at least on the time-scale
> axis.
The reason for the separation is that the solutions applicable to each
differ because the mechanisms available accommodate different time
scales.
> It seems like you have defined two orthagonal axes along which to measure:
> one is whether existing connections are required to stay up, and the other is
> whether the mobility is over limited topological scope or not. These are both
> interesting axes, I agree - but I don't think one can order them against each
> other.
>
> The two together define a 4-part space:
>
> - connections-up/limited-scope (which you dealt with as 3a)
> - connections-up/non-limited-scope (your 3b, but also 2b)
> - connections-down/limited-scope (which you didn't discuss, but it's
> not a very interesting case)
> - connections-down/non-limited-scope (which you dealt with as 3a)
Nice brief summary. The time scale just dictates which solutions from
the existing bag of tricks will work and which won't.
The point of the message though was aggrigation is broken by mobility
unless you accept the use of a home station that is fixed in the
topology.
> > b. Active TCP connections must remain up.
>
> This - as with much of mobility - turns out to present basically the same
> issues as the equivalent multi-homing case (where you want connections to
> stay up).
>
> It's amazing how similar the issues of the two things (mobility and
> multi-homing) are - one even has the same sort of breakdown of cases (whether
> one wants connections to stay up, over how wide a topological scope is the
> multi-homing, etc, etc). This would seem to me to argue for a single
> architectural approach...
With multi-homing you have one address space that is advertised though
two paths and therefore puts a small hole in an aggregate. The hole
can in principle be ignored outside some boundary of aggregation if
there were a means (that was in use) to coordinate disposal of the
hole outside boundary (or if it falls under a single administrative
domain and clue density is high enough).
> > Even simpler, use a fixed address on the loopback, use a PPP over
> > tunnel connection
>
> This is an interesting approach, one that more and more people seem to be
> using for a variety of problems, not just mobility. (One I hear a lot is for
> home offices, or road offices, where you have the issue that people want
> their remote site to be "within" the corporate firewall, etc.)
>
> Noel
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT