Re: I-D Action: draft-bernardos-dmm-pmip-02.txt

Hi Alper and all,

 

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

 

Best,

Fabio

 

From: [email protected] [mailto:[email protected]] 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,

 

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.

 

[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

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm