Hi, Carlos, Carlos Jesús Bernardos Cano wrote: > 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.
Indeed it does, but I do not think we should require the MN to get a new IP address upon every attachment to an AR. Address allocation should be decoupled from mobility management. >>>> 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. Ok, I guess the MAC layer sees the link change below it even though the MAC address of the AR is preserved. >> 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). Right, I guess I am wondering why we can't just see the new router with a new IP address still advertising the old prefix. IPv6 stacks should be able to handle this. >>>> 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... You need to find the anchoring D-GW in order to establish a tunnel to it and find out its MAC address. Assuming you found the assigned prefix, it is an extra step to map this to an anchor D-GW. Certain other proposals don't need to actually find the D-GW (for example, they can just send a BGP UPDATE to a route reflector). >>>> 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). Sure, but wouldn't you always do this for sessions that use the old prefix (whether they were established before or after the handover)? Regardless of whether the prefix was "Local" or not? >>>> 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. Ok. -Pete > > Thanks, > > Carlos > >> >>>> Looking forward to continued discussion, >>> >>> So do we. Thanks for the good comments. >>> >>> Carlos >> >> -Pete >> > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
