Re: tunnels-vs-host routes and other DMM components

Hi, Alper,

All good questions.  Some comments below.

Alper Yegin wrote:
> Hello folks,
> 
> Using tunnels vs. propagating host routes across a domain...
> 
> The former is proven to work. The latter appears to have attractive
> attributes (e.g., absence of tunneling overhead, fully distributed
> nature, etc.), but there are also aspects that need to be addressed,
> such as:
> - Can it scale (passing host-routes for millions of nodes even in
> single operator network)?

I think a better way to put this question is "over what scope does it
scale?"  Clearly it should work fine over a limited scope such as the
region spanned by one pool of route reflectors.  In some deployment 
cases (such as when the MN is able to release an old address fairly 
quickly) this may be enough.

> - Can it converge fast enough for seamless handovers?

I see no reason why it can't be just as fast as a tunnel setup, if not
moreso.  You just need to propagate an UPDATE message as far as the
crossover router, and install a route into the FIB.  There is no good
reason why this would take more time than installing a tunnel state.
Some BGP implementations may need to be tuned for proper performance.

> - Is it practical from charging, lawful intercept, DPI, policy
> enforcement point of view?

We shouldn't sacrifice fault tolerance and optimal routing on the
altar of these "features".  They won't be needed in every deployment,
and when they are needed, we can find ways to implement them without
forcing the traffic to a central location in an unscalable and
fault-intolerant way.

> - How do we deal with the case when the MN moves outside the domain?
> (probably we need to fall back to using a tunnel-based solution)

Yes, and I think that should be a client-based tunnel to handle the
likely situation where there is no relationship between the old and
new domains other than the fact that they are both connected to the
Internet.

> The host-route-based schemes need to overcome these challenges to
> appear as an alternative to tunnel-based solutions. I'm hoping the
> proponents of those scheme will show us how they handle these issues.

Agree further study is needed.

> Maybe it'll turn out that under certain conditions host-route-based
> solutions work just fine (Pete was pointing at local mobility). If so,
> we can recognize that and tell people they can use such solutions
> instead of tunnel-based solutions, where applicable.

Yes.

> For example: If the anchor is within an operator network it can be
> used (which can substitute for tunnel-based anchoring on a central HA
> and also on previous AR -- but not for anchoring near the
> corresponding network which works across the Internet).

True but anchoring at a CN requires cross-domain coordination for the
network-based mobility management case.

> 
> ...
> 
> But note that, that discussion is just about  one component of DMM
> solution set. There are other components, which are not impacted by
> that discussion. Such as:
> - The MN stack treating flows differently with respect to their
> mobility needs (assigning different types [colors/anchor type, etc] of
> IP addresses)

Yes we still need to have that discussion.  This can be worked out 
independently of the mechanism used by the network-based mobility
scheme.

> - The MN stack choosing anchors (i.e., selecting a specific anchor
> node based in the anchor type selection).

Yes the software in the MN still needs to handle multiple simultaneous
addresses, choosing among them, and managing their lifecycles.  The 
important feature of DMM is to enable a decoupling between the mobility
events and the address lifecycle, so that addresses can be maintained
for some time after a mobility event and new ones can be allocated when
it makes sense to do so (not forced at the time of mobility).

> ...
> 
> And whenever a component involves DP/CP, we should recognize that they
> are separable and take that into account.

Agree but with the caveat that DMM is not the right place to standardized
CP/DP interface protocols.

-Pete

> Alper