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

From: Julien Laganier <[email-masked]>
Date: Tue, 2 Jun 2009 13:21:34 +0200

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 <[email-masked]> wrote:
> Hi Vijay,
>
> Regards,
> Ahmad
>
>> -----Original Message-----
>> From: Vijay Devarapalli [mailto:[email-masked]]
>> 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
>>
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 2 Jun 2009 06:56:45 -0500

Hi Julien,

Sure, will spin a new revision, hopefully quickly. 

Regards,
Ahmad

> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Tuesday, June 02, 2009 6:22 AM
> Cc: Vijay Devarapalli; mext
> Subject: Re: LMA behavior for HI status unknown (was Re: 
> Binding Revocation almost ready for IESG)
> 
> Hello Ahmad,
> 
> >> I am going to split the emails into two, since we are dealing with 
> >> two issues.
> >>
> >> Ahmad Muhanna wrote:
> >>
> >> > think it is necessary to add anything, but we could add 
> a pointer 
> >> > to
> >> 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"?
> >
> >>
> 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]
> > Do we need a new revision for this or we can add the text 
> during the 
> > AD review and comments?
> >
> >>
> >> Vijay
> >>
> >
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 10 Jun 2009 12:28:46 -0500

Hello All,

We discussed this offline and we have the following agreed upon text. Please take a look and let us know if you have any comment, issue or concern. We are planning for spinning a new revision by the end of the coming weekend.

Many thanks in advance!
Ahmad

Under section 9.1.1., the following text will be added:

"
   According to Proxy Mobile IPv6 specification [RFC5213], if the local
   mobility anchor receives a Proxy Binding Update message from a new
   mobile access gateway for extending the binding lifetime of the only
   BCE of this mobile node with the Handoff Indicator value is set to
   "Inter-MAG Handover - Unknown", the local mobility anchor waits a
   period of MaxDelayBeforeNewBCEAssign to receive a de-registration
   message from the previous mobile access gateway before updating the
   mobile node's BCE with the new point of attachment.  Otherwise, the
   local mobility anchor considers the received Proxy Binding Update
   message as a request for a new BCE and if processed successfully, the
   local mobility anchor assigns a different HNP for the new BCE.

   This document updates the local mobility anchor's behavior in this
   case.  If the local mobility anchor supports the binding revocation
   mechanism as described in this document, it SHOULD proactively send a
   Binding Revocation Indication message to the previous mobile access
   gateway instead of waiting for a de-registration from the previous
   mobile access gateway.  In the Binding Revocation Indication message,
   the (A) bit MUST be set and the Revocation Trigger MUST be set to
   "Inter-MAG Handover - Unkown".

   If the local mobility anchor sent a Binding Revocation Indication
   message with the Revocation Trigger field set to "Inter-MAG Handover
   - Unknown" and while waiting for a Binding Revocation Acknowledgement
   response, the following are possible conditions that the local
   mobility anchor MUST handle as specified below:

   o  If the local mobility anchor receives a successful Binding
      Revocation Acknowledgement message or a de-registration message
      from the previous mobile access gateway, the local mobility anchor
      MUST update the mobile node BCE in a similar way as if it received
      a de-registration message as described in [RFC5213].

   o  If the local mobility anchor receives a Binding Revocation
      Acknowledgement message with the status field set to "Revocation
      Failed - MN is Attached", the local mobility anchor SHOULD
      update the mobile node BCE in a similar way as if it did NOT
      receive a de-registration before the MaxDelayBeforeNewBCEAssign
      timer expires by creating a new BCE as described in [RFC5213].

   o  If the local mobility anchor did not receive a Binding Revocation
      Acknowledgement message nor a de-registration Proxy Binding Update
      from the previous mobile access gateway after it exhausted all of
      the Binding Revocation Indication message retransmissions as
      described in Section 7.3, the local mobility anchor SHOULD
      update the mobile node's BCE in a similar way as if it did NOT
      receive a de-registration before the MaxDelayBeforeNewBCEAssign
      timer expires by creating a new BCE as described in [RFC5213].
"

---

From: "Robert Marks" <[email-masked]>
Date: Thu, 11 Jun 2009 01:11:01 -0500

Hi,

When reading the new text for section 9.1.1, I was a little confused by the 
"Otherwise" beginning the second sentence. Ahmad explained the logic to me, 
and I think a small change might clarify the intent for other readers.

I suggest replacing "Otherwise," with "If a de-registration message is not 
received," so that the text becomes

  According to Proxy Mobile IPv6 specification [RFC5213], if the local
  mobility anchor receives a Proxy Binding Update message from a new
  mobile access gateway for extending the binding lifetime of the only
  BCE of this mobile node with the Handoff Indicator value is set to
  "Inter-MAG Handover - Unknown", the local mobility anchor waits a
  period of MaxDelayBeforeNewBCEAssign to receive a de-registration
  message from the previous mobile access gateway before updating the
  mobile node's BCE with the new point of attachment.  If a de-registration
  message is not received, the local mobility anchor considers the received
  Proxy Binding Update message as a request for a new BCE and if
  processed successfully, the local mobility anchor assigns a different HNP
  for the new BCE.

Bob

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "mext" <[email-masked]>
Cc: "Julien Laganier" <[email-masked]>
Sent: Wednesday, June 10, 2009 12:28 PM
Subject: Re: [MEXT] LMA behavior for HI status unknown (was Re: 
BindingRevocation almost ready for IESG)

Hello All,

We discussed this offline and we have the following agreed upon text. Please 
take a look and let us know if you have any comment, issue or concern. We 
are planning for spinning a new revision by the end of the coming weekend.

Many thanks in advance!
Ahmad

"

> > Do we need a new revision for this or we can add the text
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 11 Jun 2009 02:47:33 -0500

Hi Bob,

Thanks. That looks good.

Regards,
Ahmad

> From: Robert Marks [mailto:[email-masked]] 
> Sent: Thursday, June 11, 2009 1:11 AM
> To: Muhanna, Ahmad (RICH1:2H10); mext
> Cc: Julien Laganier
> Subject: Re: [MEXT] LMA behavior for HI status unknown (was 
> Re: BindingRevocation almost ready for IESG)
> 
> Hi,
> 
> When reading the new text for section 9.1.1, I was a little 
> confused by the "Otherwise" beginning the second sentence. 
> Ahmad explained the logic to me, and I think a small change 
> might clarify the intent for other readers.
> 
> I suggest replacing "Otherwise," with "If a de-registration 
> message is not received," so that the text becomes
>