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

Hi Pete,

>>>> 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.
> 

A reference would be good.

>>>> - 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.
> 

OK, then this is positioning the solution to be a localized mobility solution
(not localized like "NETLMM" whose locality covered the whole Internet :-)
Your approach wedges in between the L2-based solutions and MIP-based solutions.



>>>> - 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.


Our draft describes the MN-controlled case, hence CN and VN don't need to have a relationship.
We also left network-controlled case as TBD in the I-D, and that one is likely to require such a relationship.

Cheers,

Alper


> 
>>>> 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
>