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

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 10 Jun 2009 14:13:32 -0500

Hi All,
One minor update. The following sentence to be added as a Note to the last bullet in order to avoid some implementation to wait so long before creating a new BCE.

"
      Note that the local mobility anchor SHOULD use the recommended number
      of retransmissions for the Binding Revocation Indication message
      as described in Section 12 to avoid delaying the creation of a new
      binding cache entry for too long, if the mobile node is actually
      attaching to the new MAG with a different interface.
"

The last bullet will read as follows:

"
   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].  Note
      that the local mobility anchor SHOULD use the recommended number
      of retransmissions for the Binding Revocation Indication message
      as described in Section 12 to avoid delaying the creation of a new
      binding cache entry for too long, if the mobile node is actually
      attaching to the new MAG with a different interface.
"

Thanks Vijay!

Regards,
Ahmad

-----Original Message-----
From: Muhanna, Ahmad (RICH1:2H10) 
Sent: Wednesday, June 10, 2009 12:29 PM
To: mext
Cc: 'Julien Laganier'; Vijay Devarapalli; 'Sri Gundavelli'
Subject: RE: LMA behavior for HI status unknown (was Re: Binding Revocation 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

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].
"

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]]
> Sent: Tuesday, June 02, 2009 6:22 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Vijay Devarapalli; mext
> Subject: Re: LMA behavior for HI status unknown (was Re: 
> Binding Revocation almost ready for IESG)
> 
> 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
> >>
> >
>