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

[Jong-Hyouk Lee <[e-mail]>]

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. ;)

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.

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?

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.

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.

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.

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

Cheers.

-- 
IMARA Team, INRIA, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: hurryon (at) gmail.com || jong-hyouk.lee (at) inria.fr
#webpage: http://sites.google.com/site/hurryon/