Hi, Carlos, Just a couple of response points below...
Carlos Jesús Bernardos Cano wrote: > Hi Pete, > > Thanks for the comments. Please see some comments inline below. > > On Tue, 2012-03-06 at 20:55 +0000, Peter McCann wrote: >> Hi, Carlos, Juan-Carlos, >> >> I have read draft-bernardos-dmm-distributed-anchoring-00, and I have a >> few comments. >> >> First, I want to bring up something that I think is common to several >> of the DMM proposals, and that is sub-optimal use of the backhaul >> resources. It seems that when you use an AR as an anchor point, and >> move to a new AR, the traffic for that session has to traverse the >> backhaul 3 times in each direction, like this: >> >> >> ----- >> | Rtr | >> / ^ -----\ >> 1 / / 2 \ 3 >> v / v >> ---- ---- >> | AR | | AR | >> ---- ---- >> Although it may seem at odds with the goal of "distributing" mobility >> to use the crossover router as the point of traffic redirection, it >> would make for much more optimal use of the backhaul resources. I >> believe it is possible to route the traffic more optimally with a >> standard off-the-shelf router at the crossover point (using mechanisms >> detailed in draft-mccann-dmm- > flatarch-00). > > In our draft we don't make any assumption about the backhaul and access > architecture. ARs might be also directly connected (in which case no Rtr > would be traversed) if a network deployment allows that. In any case, > the traffic redirection is supposed to happen for relatively short > periods of time (otherwise the DMM advantages might vanish and it's just > better to go for a centralized approach). I suppose I have a different view of how long one might keep an address that has been assigned by a first access router. There might be quite a bit of overhead involved with getting an address assigned, and you might want to delay getting a new address until, say, every 4th AR that you encounter. While I think it might be reasonable in some environments for neighboring ARs to have a direct IP hop between them, I think it is less likely that the 4th neighbor over will have a direct connection. And even direct neighbors I think are likely to be connected in a star topology via expensive and slow backhaul links to a router one layer up in the aggregation hierarchy. >> Second, I like the idea of moving the prefix assigned to the MN from >> one AR to another. However, why do we need to keep the AR's MAC >> address the same? IPv6 should handle the failover of a first-hop router >> from one instance to another with no problems. You see the same prefix >> advertised from a different MAC address; what's the big deal? You can >> just keep using the prefix as you did before, addressing packets to the >> new access router. >> > > This is basically inherited from PMIPv6 basic operation, in which the MN > keeps "seeing" always the same router (i.e. same IPv6 link-local address > and MAC address) while moving within the PMIPv6 domain. This is so to > improve performance (there are no stale entries on the neigh cache) and > also to avoid triggering any movement detection mechanism on the MN > (changing the default router might be treated as such). We basically > follow the same approach. Besides, by using a logical interface per > anchoring router, it becomes easier to handle the prefix advertisement > on the network side. At some layer of the stack the MN will know that it changed ARs. I don't see any particular reason why we have to hide the movement from the MAC layer. Besides, most wide-area cellular technologies will use P2P links and won't have MAC addresses visible to the upper layers directly. >> Third, I don't like the idea of having to ship so much state around the >> network through the HSS. In your draft you talk about (out-of-scope) >> mechanisms to get the prefix and the anchor gateway address to the new >> D-GW. There is also the complication of knowing which prior prefixes >> the MN wants to keep at its new attachment point. It seems to me that >> we should avoid the behavior that a new prefix is always assigned at >> each new point of attachment; rather, we should force the MN to take >> some sort of affirmative action to acquire an address/prefix for its >> use, such as DHCP-PD. This would be done occasionally, not on every >> handover, and the MN could register its intent to keep an address >> through e.g., dynamic DNS update. Then the new D- GW could lookup the >> DNS name of the MN at the time it attaches, see the list of addresses >> that are currently assigned, and take steps to attract the packets for >> those prefixes. This could be a tunnel or it could be a BGP UPDATE as >> outlined in draft- > mccann-dmm-flatarch-00. > > I haven't had time to check your draft yet. Apologies for that, I'll do > it shortly. Great, would be glad to have your comments. > In any case, our draft does not specify how the info about > the active prefixes is obtained, and from where the require state is > retrieved. A centralized entity (such as the HSS, or a centralized LMA) > is just an example. Our draft also includes some PMIPv6 protocol > extensions to obtain that info from the previous router visited by the > MN (we call that D-GW), if the current router knows it. So basically the > defined mechanisms are not incompatible, IMHO, with the ones you > mentioned above. Sure. I guess it is necessary to get the old prefix that was assigned somehow; it just seems that the additional effort to map this to an anchoring D-GW might be too much. >> Finally, I don't quite understand the "Local Prefixes" concept >> presented in the draft. I understand how LIPA is supposed to work, but >> I don't understand why you need to treat such prefixes differently from >> any other prefix on the D-GW1 link. You are tunneling all the traffic >> back to the D-GW1 AR, correct? Wouldn't the traffic just naturally >> follow the proper path through to the D-GW1 and from there to the >> local CN? > > We are considering here prefixes that because of security or other > reasons are not normally reachable from the Internet, but only from > nodes directly attached to D-GW1 (e.g., in an enterprise network). For > that case, it might be useful to keep being able to reach those while > being attached to a different D-GW. This is the LIPA use case considered > by 3GPP. I understand the motivation, but wouldn't this use case be solved because of the fact you have a tunnel from the old D-GW to the new D-GW? Why does the new D-GW need to know that a particular prefix was local to the previous D-GW? Aren't you proposing to always use reverse tunneling back to the old D-GW for those packets that use the old logical interface? >> Personally, I think it might be better to use client-based Mobile IP >> for any scenario where the current AR cannot attract the packets for a >> given prefix, such as when the MN moves out of the domain of one >> operator. That situation is very similar to the LIPA case and could be >> solved with a single mechanism. > > Client-based DMM is a topic that deserves additional attention. In our > draft we have started to look at a network-based solution, but we can > discuss the implications of a client-based solution as well. I think the network based solution is a good match for the frequent, localized mobility within a given autonomous system. However, once you cross a boundary outside of which the network can't re-route your traffic, client MIP seems to be required. >> Looking forward to continued discussion, > > So do we. Thanks for the good comments. > > Carlos -Pete _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
