Re: tunnels-vs-host routes and other DMM components
Jouni Korhonen <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <[email protected]> |
Alper, On Nov 22, 2013, at 1:12 PM, Alper Yegin <[email protected]> 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)? > - Can it converge fast enough for seamless handovers? > - Is it practical from charging, lawful intercept, DPI, policy enforcement point of view? > - 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) > > 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. It might be worth looking into what SPRING is doing in this domain. The new work around source routing might have some useful assets for our use, specifically if source routes can be added by intermediate or border nodes. Maybe there is something "innovative" to do, which would allow us to go around host routes and related frequent IGP updates. Maybe the "innovative" thing just moves or renames the routing problem.. I do not know :) - Jouni > 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. > > 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). > > ... > > 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) > - The MN stack choosing anchors (i.e., selecting a specific anchor node based in the anchor type selection). > > … > > And whenever a component involves DP/CP, we should recognize that they are separable and take that into account. > > > Alper > > > > > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm