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

From: Jong-Hyouk Lee <[email-masked]>
Date: Wed, 07 Dec 2011 00:20:13 +0100

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/

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 08 Dec 2011 12:32:27 +0100

Hi Jong-Hyouk,

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

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

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

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

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

> such things, but he will allow the data transmission continuously.

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

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

> problems/issues for your next draft.

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

Carlos

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