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

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

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