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). > > > 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. > > 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. 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. > > > 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. > > 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. > > Looking forward to continued discussion, So do we. Thanks for the good comments. Carlos > > -Pete > > -- > Peter J. McCann > Huawei Technologies (USA) > [email protected] > +1 908 541 3563 > Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 USA > > -- 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
