Re: [MEXT] Comments on "draft-bernardos-mext-dmm-pmip-01"

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Jong-Hyouk,

Thanks a lot for your comments. Please see some comments inline below.

On Wed, 2011-12-07 at 00:20 +0100, Jong-Hyouk Lee wrote:
> Hi Carlos,
> 
> I read the draft "draft-bernardos-mext-dmm-pmip-01" and have 
> comments/questions:
> 
> 1. I'd like to avoid non-technical comments, but I should mention it. In 
> Section 3, the following sentence "The purpose of Distributed Mobility 
> Management approaches is to overcome the limitations of the traditional 
> centralized mobility management by bringing the mobility anchor closer 
> to the MN." should be revised. Brining the mobility anchor closer to MNs 
> is to form a flattened architecture, not for DMM. ;)

Well, please allow me to disagree here :D. I think that "bringing
mobility anchors closer to the MN", so the MN can change anchor
dynamically and traffic is not always managed by the same centralized
entity is exactly one way of DMM. Maybe the writing was not the best
one, and we will revise it.

> 
> 2. In Section 3.2, even if you didn't explicitly describe, the proposed 
> one could avoid a conflict over ingress filtering at MAARs. For 
> instance, in Figure 2, MAAR2 updates its routing information after it 
> receives the PBA message containing prefixes associated with the mobile 
> node. Then, for addressing ingress filtering issues with the prefixes, 
> MAAR2 is required to update its ingress filtering list (e.g., of a 
> firewall) with the prefixes. With this way (as an example), the conflict 
> over ingress filtering is solved.

Well, sure MAARs have to update their ingress filtering rules, but it
exactly the same case of PMIPv6: MAAR2 plays the role of MAG, and
therefore has to allow and forward traffic with source addresses
belonging to a prefix assigned by the LMA (MAAR1).

> 
> 3. In Section 3.2, you gave the following sentence "The drawback can be 
> mitigated introducing a timeout at the CMD, by which, after its 
> expiration, all the PBAs so far collected are transmitted, and the 
> remaining are sent later upon their arrival." Hummm...actually, it does 
> not help to mitigate the problem; it makes a bigger problem. Suppose 
> that a mobile node has five prefixes, i.e., P1 (the prefix obtained from 
> the first MAAR), P2, P3, P4, and P5 (the prefix obtained from the 
> serving MAAR). Let t denotes the timer value at the CMD. Now...suppose 
> that the transmission times of PBAs containing P1 and P2 are bigger than 
> t. The CMD thus closes its waiting and sends out the PBA message 
> containing only P3 and P4. Then, what are you expecting at the serving 
> MAAR (MAAR5)? Since this guy now updates its routing table for the 
> mobile node with only P3, P4, and P5, incoming packets associated with 
> P1 and P2 to the mobile node are lost and outgoing packets with P1 and 
> P2 are also definitely filtered (due to no ingress filtering list 
> update). Those are happened during the time gap between the arrival of 
> PBA (P3 and P4) and the arrival of PBA (P1 and P2) sent from the CMD to 
> the serving MAAR. In addition, you didn't give a detail of handling of 
> the late arrivals; shall the CMD wait another t for collecting and wait 
> again for collecting rest all? Moreover, why does the CMD wait to 
> collect all PBAs from other MAARs?

Details are definitely missing and we will provide more in a subsequent
revision. Regarding your comments, short answer is: you always lose
packets while the signaling is taking place (either that or you buffer
them and then once is completed deliver the packets). Therefore,
anything that avoids to wait to collect all PBAs is actually reducing
the time packets are lost for those prefixes that you could process
before all the PBAs are received.

> 
> 4. In addition, the approach of "CMD as PBU/PBA relay" described in 
> Section 3.2 must cause long registration latency as the mobile node 
> continuously moves around the domain consisted of MAARs. Moreover, I'm 
> also concern about the routing loop as the mobile node moves around the 
> domain and visits its previous locations again; special treatments for 
> eliminating the routing loop are required at the CMD.

I think the speed of movement to require that loops to appear is faster
than the usual one for a mobile node. Sure there might be temporal and
short periods of time with loops, but this is not exclusive of this kind
of solution (ping-pong effects are well known).

> 
> 5. In Section 3.3, you introduce the approach of "CMD as MAAR locator" 
> that seems for reducing latency compared to the approach of "CMD as 
> PBU/PBA relay". However, I have doubt about the approach of "CMD as MAAR 
> locator". Look at Figure 3. As shown, MAAR2 will allow any data 
> transmission associated with P1 (i.e., mobile node's prefix assigned in 
> MAAR1) at his access network without any confirmation from the CMD. 
> Hummm...don't we need to check P1's validation? Without involvement of 
> the CMD, it's hard to check prefix (or previous binding information)'s 
> validation; revoked? expired? Hummm...at Figure 3, MAAR2 does not know 
> such things, but he will allow the data transmission continuously.

The confirmation comes from MAAR1 (PBA), instead from CMD as in the
previous case.

> 
> 6. The approach "CMD as PBU/PBA proxy" introduced in Section 3.4 also 
> brings an issue. In short, look at Figure 4, without any confirmation 
> from MAAR1, MAAR2 updates its routing information for P1. How about if 
> MAAR1 does not properly work at the moment? Even MAAR1 sends its message 
> to the CMD, but there is no way to provide it to MAAR2.

If MAAR1 does not work properly, there is nothing you can do to ensure
traffic anchored at MAAR1 is forwarded to the MN, no matter what you
do :D. Since CMD knows the prefixes MAAR1 anchors, this approach allows
to speed the process by doing things in parallel.

> 
> I hope...my comments help you to figure out ways to overtime these 
> problems/issues for your next draft.

Sure they help. We'll try to explain things better in the next version.
Thanks!

Carlos

> 
> Cheers.
> 

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67