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

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 14 Jun 2009 09:34:32 -0500

Hi Julien and All,

A new revision (07) has been submitted with this change only.
Please let me know if you have any comments.

Regards,
Ahmad

++++

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title           : Binding Revocation for IPv6 Mobility
	Author(s)       : A. Muhanna, et al.
	Filename        : draft-ietf-mext-binding-revocation-07.txt
	Pages           : 39
	Date            : 2009-06-14

This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources.  These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions.  This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

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

---

From: Julien Laganier <[email-masked]>
Date: Mon, 15 Jun 2009 12:42:50 +0200

Folks,

You have 'til the end of the week to comment on the last version of
the draft after which we consider it is ready and will forward it to
IESG to request publication as RFC.

--julien & marcelo, MEXT chairs