Re: [DMM] New DMM draft: draft-bernardos-dmm-distributed-anchoring-00.txt
Carlos, please see inline. -Original Message- From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] Sent: Sonntag, 18. März 2012 20:59 To: Marco Liebsch Cc: dmm@ietf.org Subject: RE: [DMM] New DMM draft: draft-bernardos-dmm-distributed- anchoring-00.txt Hi Marco, Thanks for your comment. Please see inline below. On Fri, 2012-03-16 at 10:00 +, Marco Liebsch wrote: Carlos, thanks for your feedback. Please see inline. -Original Message- From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] Sent: Freitag, 16. März 2012 09:51 To: Marco Liebsch Cc: dmm@ietf.org Subject: RE: [DMM] New DMM draft: draft-bernardos-dmm-distributed- anchoring-00.txt Hi Marco, Apologies for the late reply. Thanks for reading the draft. Please see some answers to your questions/comments inline below. On Fri, 2012-03-09 at 11:51 +, Marco Liebsch wrote: Hi Carlos, I have a few clarifying questions to your new draft. The draft proposes the distributed logical interface. I don't really get the advantage of virtualizing the previous LMA on the MN's current LMA if packets are routed through the previous LMA anyway. Why not using the current LMA to serve simply as MAG for forwarded traffic (which remains anchored at previous LMA) and using the new LMA to anchor the new address/prefix? What you just mention is exactly what the draft does. Additionally, the logical interface simplifies the interface between the MN and the access router that behaves as LMA/MAG. It does so because by interacting with the MN as different logical routers (one per anchoring LMA), you can make full use of the ND based features (e.g., RFC4191) in a very easy way. The draft writes that the idea hides the change of the anchor from the mobile node. The DGW2IF on the new LMA does not pretend to be LMA1, or? I don't see how the anchor change is kept transparent to the MN. The point is that from the point of view of the MN, it always sees as directly connected (1-hop away) each of the anchor LMAs. Every time the MN moves and attaches to a new access router, the only thing it notices is that a new (logical) router appears on the link, advertising a new prefix (and, in most use cases, the others start advertising the prefixes with lifetime=0 to deprecate them). The LMA function should be transparent to the MN anyway, so it does not matter whether the LMA, which serves as anchor, is on the previous AR or on the current one. Invalidating the previous HNP and validating the new HNP can be done independently of whether the responsible LMA instance is co-located with the local AR or the previous AR. But I must admit that I probably have to check that part of your draft again. If it just invalidating the prefix, this can be done, true. But the point is that the DLIF concept enables to do more that just invalidating a prefix. Besides, it makes easier to implement this prefix deprecation. Ok, I'll check the description to better understand the DLIF function. I somehow agree also to Pete's opinion that solving the packet routing after anchor relocation above the anchors is a good option. It simply allows more optimal routes. I have to read his draft, but unless you have control on the routing infrastructure (and this is not always possible, and it takes time to converge), I don't see many other options to ensure address continuity. I don't expect this to take long time, as the routing states are not to be enforced in all routers, at least not in our proposal. Intention is to keep the routing plane as it is and update states only is one dedicated router per data session, which translates the MN's IP address into a routable one to ensure that remaining routers in the network forward the downlink packet to the MN's current anchor point. The previous anchor point is released from any forwarding tasks. Further advantage is that routes are potentially more optimal compared to forwarding from a previous anchor. Which does not mean that both approaches cannot co-exist. A DMM solution could rely on forwarding while the state in the routing plane is established. I have to admit I haven't checked your proposal yet. No problem ;-) What you mention seems like a NAT-based approach, is it true? We propose NAT to save per-packet overhead and use the prefix/IP address being assigned and anchored at the new anchor as locator, which intrinsically has identifier information. So, reverse NAT on the new anchor is easily possible. But that's not the key of the approach, as NAT can be easily replaced by IP tunnels. The key approach is to solve DMM in the routing plane above anchors while using the existing routing plane. and if there is a dedicated router, isn't it a centralized entity? It's exactly
Re: [DMM] New DMM draft: draft-bernardos-dmm-distributed-anchoring-00.txt
Hi Marco, Apologies for the late reply. Thanks for reading the draft. Please see some answers to your questions/comments inline below. On Fri, 2012-03-09 at 11:51 +, Marco Liebsch wrote: Hi Carlos, I have a few clarifying questions to your new draft. The draft proposes the distributed logical interface. I don't really get the advantage of virtualizing the previous LMA on the MN's current LMA if packets are routed through the previous LMA anyway. Why not using the current LMA to serve simply as MAG for forwarded traffic (which remains anchored at previous LMA) and using the new LMA to anchor the new address/prefix? What you just mention is exactly what the draft does. Additionally, the logical interface simplifies the interface between the MN and the access router that behaves as LMA/MAG. It does so because by interacting with the MN as different logical routers (one per anchoring LMA), you can make full use of the ND based features (e.g., RFC4191) in a very easy way. The draft writes that the idea hides the change of the anchor from the mobile node. The DGW2IF on the new LMA does not pretend to be LMA1, or? I don't see how the anchor change is kept transparent to the MN. The point is that from the point of view of the MN, it always sees as directly connected (1-hop away) each of the anchor LMAs. Every time the MN moves and attaches to a new access router, the only thing it notices is that a new (logical) router appears on the link, advertising a new prefix (and, in most use cases, the others start advertising the prefixes with lifetime=0 to deprecate them). I somehow agree also to Pete's opinion that solving the packet routing after anchor relocation above the anchors is a good option. It simply allows more optimal routes. I have to read his draft, but unless you have control on the routing infrastructure (and this is not always possible, and it takes time to converge), I don't see many other options to ensure address continuity. Now I am deviating a bit, but into the direction of an important question: That's directly related to the question of how persistent we need to be about IP address continuity. Now, some proposals consider termination of an IP address prefix, which is anchored at a previously used anchor point, as soon as the IP session, which uses that address, terminates. New sessions can use the address being anchored at the new mobility anchor. My opinion is that we need to find a good choice about the lifetime of such an anchored IP address, as it may also be registered with other services, e.g. IMS, messaging, etc, and would require an updated registration after a change in the registered address. And even if such lifetime is short, we may not accept suboptimal routing paths via the previous anchor after anchor relocation. Session lifetime and prefix anchoring termination is a tricky and important issue. As I see it, DMM is compatible with a classical centralized approach (at least for the solutions that are basically extending currently standardized IP mobility protocols to operate in a more distributed way). For those applications that are known in advance to require very long address lifetime (compared to the anchoring mobility rate), I'd say that those sessions it might make sense to keep them centrally anchored (or to enable applications to be able to survive to an IP address change). Thanks, Carlos What do you think? Thanks, marco -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Carlos Jesús Bernardos Cano Sent: Montag, 5. März 2012 18:40 To: dmm@ietf.org Subject: [DMM] New DMM draft: draft-bernardos-dmm-distributed- anchoring-00.txt Dear all, We've just submitted a new I-D on the DMM space. The draft describes a network-based DMM approach extending PMIPv6, and focusing on the required extensions to effectively support simultaneously anchoring several flows at different distributed anchors. As usual, comments would be warmly welcomed! More info below: Title : PMIPv6-based distributed anchoring Author(s) : Carlos J. Bernardos Juan Carlos Zuniga Filename: draft-bernardos-dmm-distributed-anchoring-00.txt Pages : 23 Date: 2012-03-05 Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does not rely on centralized deployed anchors to provide IP mobility support. There are many different approaches to address Distributed Mobility Management, as for example extending network-based mobility protocols (like Proxy Mobile IPv6), or client-based mobility protocols (as Mobile IPv6), among others. This document follows the former approach, and proposes a solution based on Proxy Mobile IPv6 in which
