Hi Pete, Sorry for the late reply. Please see inline below.
On Wed, 2012-03-07 at 18:58 +0000, Peter McCann wrote: > 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. I guess this very much depends on the operator's architecture and the mobility pattern of the MN. > > >> 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 The change is not hidden from the MAC layer, but from the IP layer. > P2P links and won't have MAC addresses visible to the upper layers > directly. Well, in this case the L2 change is "by default" hidden from the IP stack (if the new MAG shares the IP address from the old one). > > >> 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. Not sure I follow what you said here... > > >> 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? The tunnel is only used while you have ongoing sessions active. But you might want to still being able to start new sessions to that local prefix via the D-GW connected to it (because it is the only way to get connectivity to it). > > >> 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. For that case, seems to me that both PMIP and CMIP-based solutions could be appropriate, but it depends on the specific assumptions. I guess we would need to look further into the details. Thanks, Carlos > > >> Looking forward to continued discussion, > > > > So do we. Thanks for the good comments. > > > > Carlos > > -Pete > -- Carlos Jesús Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
