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/
_______________________________________________
MEXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mext
