Re: [DMM] 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] tunnels-vs-host routes and other DMM components
Alper, On Nov 22, 2013, at 1:12 PM, 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)? > - 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 > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] tunnels-vs-host routes and other DMM components
Hello Alper, In this discussion, I may be missing the 'Mobile Router vs Host' dimension. We would use host-based routes if we need Mobile Hosts, but we'd use prefix-based routes if we needed Mobile Routers. The route convergence speed and domain size scalability aspects apply differently. Additionally, I would shape the question from the other point of view as well: is it reasonable for PMIP solution to use tunnels even if the mobile stays within the same domain? Alex Le 22/11/2013 12:12, Alper Yegin a écrit : 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. 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 dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Hi Pete, > This obviously wouldn't work for billions of MNs. But, with DMM people > are starting to realize that MNs don't need completely stable global addresses > that live forever. Most don't, but some do. We need to account for them as well. > So I think DMM should focus on localized mobility management. This is not sufficient. Think of the typical case where MN moves from cellular network of one operator to WiFi network of another operator. This can be a physically localized, but topologically a global handover. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
[DMM] tunnels-vs-host routes and other DMM components
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. 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 dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
