Subject: Re: [DMM] I-D Action: draft-bernardos-dmm-pmip-02.txt

From: Alper Yegin <[email-masked]>
Date: Mon, 22 Jul 2013 15:27:53 +0300

Hello folks,

Few comments on this I-D:

   For next MN's movements the process is repeated except for the number
   of P-MAARs involved, that rises accordingly to the number of prefixes
   that the MN wishes to maintain.  Indeed, once the CMD receives the
   first PBU from the new S-MAAR, it forwards copies of the PBU to all
   the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR
   prior to handover) and in the P-MAARs list.  They reply with a PBA to
   the CMD, which aggregates them into a single one to notify the
   S-MAAR, that finally can establish the tunnels with the P-MAARs.

Why not let the CMD send PBAs as it receives them from P-MAARs?
That way a delayed (or even dead!) P-MAAR would not be holding up other P-MAAR operations.

In "CMD as MAAR locator" case, the P-MAAR sends PBAs to CMD and S-MAAR separately. This could lead to some state inconsistency issue, right? S-MAAR and CMD may land on a different state if the result of their processing is different.

In "CMD as MAAR proxy" case, CMD responds to S-MAAR before P-MAAR processes and responds to the CMD. If the P-MAAR rejects the PBU, then this would lead to state inconsistency in the system.

Cheers,

Alper

---

From: "Fabio Giust" <[email-masked]>
Date: Mon, 22 Jul 2013 19:36:51 +0200

Hi Alper and all,

Thanks for your feedback on the draft. Please see some considerations
inline.

Best,

Fabio

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alper
Yegin
Sent: lunes, 22 de julio de 2013 14:28
To: dmm
Subject: Re: [DMM] I-D Action: draft-bernardos-dmm-pmip-02.txt

Hello folks,

 

 

That way a delayed (or even dead!) P-MAAR would not be holding up other
P-MAAR operations.

[FG:] This observation was indeed raised in the -00 draft version, and then
removed to keep the document simpler. The fastest way to proceed would be
what you suggest: the CMD sends the PBAs as it receives them from the
P-MAARs.

However, this method incurs in additional control messages. A possible
solution that mitigates the number of control messages could be saving the
PBAs in a buffer and then sending them in a batch at regular (or
incremental) intervals

In "CMD as MAAR locator" case, the P-MAAR sends PBAs to CMD and S-MAAR
separately. This could lead to some state inconsistency issue, right? S-MAAR
and CMD may land on a different state if the result of their processing is
different.

[FG:] In general by breaking the classic update/ack scheme we can have
inconsistent states in the CMD and MAARs. The draft at the moment does not
deal with how to recover from such situation. However, the periodic
signaling sent by the S-MAAR to refresh the binding state can be exploited
to detect and fix such problem.

In "CMD as MAAR proxy" case, CMD responds to S-MAAR before P-MAAR processes
and responds to the CMD. If the P-MAAR rejects the PBU, then this would lead
to state inconsistency in the system.

[FG:] The CMD waits for a PBA from the P-MAAR, so if the PBU is rejected,
the CMD eventually  finds out the inconsistency and can take the appropriate
action. The draft could be extended defining such action (for instance a PBU
to the S-MAAR to notify the correct state). In all cases, if a P-MAAR
rejects the PBU, then no mobility support can be provided to the MN's old
sessions, both if the states in the MAARs are consistent or not.

Cheers,

Alper