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

Hi, Alper,

Alper Yegin wrote:
> Hi Pete,
> 
>> 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.
> 
> I presume you are talking about even a subset of an operator network.
> Sure, OK, whatever it is if we can get some description of it, that'd
> help us understand the applicability of these approaches.

Agreed.

>>> - 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.
>> 
> 
> We know BGP is not designed for handling many rapid changes (after all
> non-mobile prefixes are much more stable compared to a moving MN).
> But of source that does not necessarily mean BGP cannot handle it.
> I'm not a BGP expert to confirm. It may be worth running this by the
> routing related WGs and collect some feedback.

There have been studies of the basic propagation time of an UPDATE
through a BGP router.  It can be done in as little as 2.4ms if the
timers and batching are configured properly.

>>> - 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.
>> 
> 
> Sounds good. We just need to see the details.
> 
> I'm not claiming any of these points are show-stoppers. But these are
> points that need to be addressed in order for people to feel confident
> about this alternative. After all, this whole tunneling-based MIP
> business was created at the beginning because we couldn't propagate host
> routes across the Internet. Now if we are going to go back to host
> routes, then we need to understand what changed since then or what we
> missed at the time and decided to go down the tunneling path.

We will still need (client-based) tunnels across the Internet.  We are
just trying to buy a little time for the old address (and the current
CoA) so we don't have to have over-the-air tunnel signaling on every 
change of base station.

>>> - 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.
>> 
> 
> This sounds plausible too. It'd be good to see the details.

I think we will need some new mechanisms to enable quick establishment
of a security association with a local HA at the time a local address
is assigned.  I don't want to require RADIUS round-trips (ugh).  Other
than that this is standard MIP.

>>> 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.
>> 
> 
> Can you elaborate on that?

Maybe you didn't propose this, but a network-controlled CN-based anchor
would imply some kind of relationship between the visited and correspondent
networks.

>>> 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.
>> 
> 
> Yes.
> 
> Cheers,
> 
> Alper

-Pete