Re: [MEXT] LMA behavior for HI status unknown (was Re: Binding Revocation almost ready for IESG)

[Julien Laganier <julien.laganier.ietf at googlemail.com>]

Hello Ahmad,

I think we'd be better with a new revision.

Thanks.

--julien

On Sat, May 23, 2009 at 2:22 PM, Ahmad Muhanna <amuhanna at nortel.com> wrote:
> Hi Vijay,
>
> Regards,
> Ahmad
>
>> -----Original Message-----
>> From: Vijay Devarapalli [mailto:vijay at wichorus.com]
>> Sent: Friday, May 22, 2009 12:56 PM
>> To: Muhanna, Ahmad (RICH1:2H10)
>> Cc: mext; Julien Laganier
>> Subject: LMA behavior for HI status unknown (was Re: Binding
>> Revocation almost ready for IESG)
>>
>> Hi Ahmad,
>>
>> I am going to split the emails into two, since we are dealing
>> with two issues.
>>
>> Ahmad Muhanna wrote:
>>
>> >>>> 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"
>> >> :) I mean,
>> >>> the MAG is supposed to check whether the mobile node is
>> attached or
>> >>> not and based on its finding, it should reply back either
>> >> success or
>> >>> failure, 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 a
>> > de-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.
>
> [Ahmad]
> Where in the revocation draft it said that the LMA must send a BRI with
> the trigger set to "handoff state unknown"?
>
>>
>> How can these two be compatible?
>>
> [Ahmad]
> We can debate this offlist, I guess:)
> Please see below.
>
>> 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.
>
> [Ahmad]
> Although, I still believe that these two cases compatible but I agree
> with the end result that you are proposing. I see your point when the
> LMA support Binding Revocation and at the same time already support
> RFC5213, we need to be clear on what the LMA needs to do if it decides
> to send a BRI message to the old MAG rather than waits for a
> de-registration to come.
>
> Will come up with some text which address this option, i.e., when the
> LMA uses BRI proactively to define if the MN is no longer attached to
> the old MAG or not to be able to handle the PBU with HI unknown coming
> from the new MAG.
>
> Do we need a new revision for this or we can add the text during the AD
> review and comments?
>
>>
>> Vijay
>>
>