Hi Ahmad,I am going to split the emails into two, since we are dealing with two issues.
Ahmad Muhanna wrote:
:) I mean,But what should the MAG behavior be when it receives the following trigger?5 Inter-MAG Handover - Unknown[Ahmad]The MAG will reject the BRI with code "MN still attached"the MAG is supposed to check whether the mobile node is attached or not and based on its finding, it should reply back eithersuccess orfailure, e.g., "MN still attached".Ok.So what does the LMA do now? The new MAG is saying the MN attached to it and the handoff state is "unknown". The old MAG is saying the MN is still attached? Shouldn't this result in a new mobility session being setup for the attachment through the new MAG? It won't be treated as a handover anymore. This probably needs to be explained.[Ahmad]The LMA does nothing other than what is documented in RFC5213. This is exactly the same case as if the LMA did not receive ade-registration from the previous MAG and the timer expired. I do not think it is necessary to add anything, but we could add a pointer to RFC5213 for this specific case when handling the AD comments.
This doesn't make sense. RFC 5213 says if the LMA receives a PBU with HI set to "handoff state unknown", it should wait for MaxDelayBeforeNewBCEAssign amount of time for a deregistration PBU from the old MAG. If there is no such deregistration message from the old MAG, it would create a new mobility session.
The Binding revocation document suggests that the LMA must send a binding revocation message with the trigger set to "handoff state unknown". If the MN is still attached, the old MAG would reject the binding revocation. Then the LMA would proceed with creating a new mobility session.
How can these two be compatible?IMO, the binding revocation document should say that it is updating RFC 5213 when it comes to the LMA behavior when it receives a PBU with HI set to "handoff state unknown". If the LMA and the MAG implement binding revocation, they should follow the mechanism described in the binding revocation document rather than the one in RFC 5213.
Vijay