Re: [MEXT] MEXT Digest, Vol 18, Issue 5

["Desire Oulai" <[e-mail]>]

Hi Behcet,

  I did not undersstand your proposal. Do you agree that the HA must be
able to revoke a subset of the assigned MNPs using MNP options included
in BRI/BRA?

BR

Desire

> ------------------------------
> 
> Message: 6
> Date: Fri, 5 Dec 2008 08:18:47 -0800 (PST)
> From: Behcet Sarikaya <[e-mail]>
> Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports
> 	NEMOusecase
> To: Ahmad Muhanna <[e-mail]>
> Cc: [e-mail]
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi Ahmad,
>   Currently your draft does not talk about Nemo. If you wish 
> to include MR, I think it is easy: You can say that MIP6, 
> DSMIP6 cases apply to MR acting as MN.
> PMIP6 case also applies to MR acting as MR not as MAG.
> BRI sending entity has to make sure that MNPs are removed 
> from the binding cache before sending the revocation.
> 
>   Profiting the occasion, I found a few typos in your draft :
> 
> 
> typos: sends a BRA message to the LMA following the rules describes
> -->described
> 3.4.3.  Mobile Access Gateway Revoke Bulk PMIPv6 Bindings
> 
> -> Revokes
> 
> Regards,
> 
> Behcet
> 
> 
> 
> ________________________________
> From: Ahmad Muhanna <[e-mail]>
> To: Behcet Sarikaya <[e-mail]>rg>; fan zhao 
> <[e-mail]>
> Cc: [e-mail]
> Sent: Friday, December 5, 2008 9:02:10 AM
> Subject: RE: [MEXT] Binding Revocation for IPv6 Mobility 
> Supports NEMOusecase
> 
>  
> Hi 
> Behcet,
>  
> Just 
> to clarify one thing here. It seems that we overlooked this 
> use case by not 
> mentioning it in the draft.
> Looking at the presentation that we made at IETF-70 and IETF-71 it 
> clearly list HA->MR as one of the usecases.
> Since 
> that was the basis for this draft that was adopted as a wg 
> document, I believe 
> we need to include this in the draft.
>  
> Please 
> find the Binding Revocation slides for IETF-70 & 71 at the below 
> links:
>  
> http://www.ietf.org/proceedings/08mar/slides/mext-9.pdf
> http://www.ietf.org/proceedings/07dec/slides/mext-4.pdf
> Regards, 
> Ahmad 
>  
> 
> 
> ________________________________
>  From: [e-mail]  [mailto:[e-mail]] 
> On Behalf Of Behcet  Sarikaya
> Sent: Wednesday, December 03, 2008 12:00 PM
> To: fan zhao
> Cc: [e-mail]
> Subject: Re: [MEXT] Binding  Revocation for IPv6 Mobility 
> Supports NEMOusecase
> 
> 
> 
> 
> 
> 
> 
> ________________________________
>  From: fan zhao  <[e-mail]>
> To: Behcet Sarikaya  <[e-mail]>
> Cc: [e-mail]
> Sent: Tuesday,  December 2, 2008 5:47:35 PM
> Subject: Re: [MEXT] Binding Revocation  for IPv6 Mobility 
> Supports NEMO usecase
> 
> Hi Behcet,
> 
> There  is a difference between binding revocation for MNPs and
> MNP  release.
> When the binding revocation for MNPs is performed, the  MNP
> information stored in the binding cache entry for the MR is
> removed,  which means that the packets for such MNP will not
> be tunneled by the HA;  however, such MNP is not explicitly
> released by the binding revocation.  This is needed because
> the mobile network nodes connecting to the MR  before
> may handover to their home network (such as wimax) while
> the MR  still stays in its foreign link (since for example the MR
> does not have the  wimax interface); therefore, such MNP
> should still be made valid for such  mobile network nodes.
> 
> To release such MNP, the same method to allocate  the
> MNP should be used. For example, if the MNP is allocated
> by using  DHCP, then DHCP needs to be used again to remove
> such MNP. This is similar  to the MIPv6 case where the MN
> sends the BU with the lifetime=zero or the  HA sends the BRI
> to remove the binding, the home address on the other  hand
> needs to remove by deleting the IPsec SA if this is detach.
> 
> It  makes sense to me using the BR to remove the MNP from
> the BCE since such  MNP is registered by using BU and
> BR is the opposite way to  BU.
> 
> [behcet ] So it is the MR that knows  thesituation and MR 
> should  initiate MNP release. Doing it with BR would be 
> server-initiated which is  something to be considered for 
> prefix renumbering which has nothing to do with  the release. 
> 
> Sincerely,
> fan
> 
> On Tue, Dec 2, 2008 at  2:50 PM, Behcet Sarikaya
> <[e-mail]>  wrote:
> > Hi Fan,
> >  Prefix delegation/authorization function  should take care 
> of this. In DHCP
> > PD there is a way to release the  prefixes.
> >
> > Regards,
> >
> > Behcet
> >
> >  ________________________________
> > From: fan zhao <[e-mail]>
> > To:  Behcet Sarikaya <[e-mail]>
> > Cc: Ahmad  Muhanna <[e-mail]>om>; [e-mail]
> > Sent: Tuesday,  December 2, 2008 3:41:56 PM
> > Subject: Re: [MEXT] Binding Revocation for  IPv6 Mobility 
> Supports NEMO
> > usecase
> >
> > Hi  Behcet,
> >
> > The binding revocation is designed for DSMIPv6 and  DSMIPv6 supports
> > both mobile host
> > and mobile router. I do not  see any issue.
> >
> > Sincerely,
> > fan
> >
> > On Tue,  Dec 2, 2008 at 11:52 AM, Behcet Sarikaya
> > <[e-mail]>  wrote:
> >> Hi Ahmad,
> >>  Can you please explain how MNP  is related to your draft? 
> MNP is something
> >> that MR needs and is  specific to Nemo operation not to 
> MN-HA relationship
> >> and the  binding that comes with it.
> >>  So I don't see any binding to  revocate with MNPs?
> >>
> >> Regards,
> >>
> >>  Behcet
> >>
> >> ________________________________
> >>  From: Ahmad Muhanna <[e-mail]>
> >>  To: Desire Oulai <[e-mail]>om>; [e-mail]
> >> Sent: Monday,  December 1, 2008 9:22:35 PM
> >> Subject: Re: [MEXT] Binding Revocation  for IPv6 Mobility 
> Supports NEMO
> >> usecase
> >>
> >> Hi  Desire,
> >>
> >> Added a relative  subject.
> >>
> >> I guess the usecase is clear and it makes  sense to me.
> >> We can add some text similar to yours to capture this  
> functionality under
> >> the HA and MN operations after the conclusion  of the WGLC..
> >>
> >> BTW: Is there anyone who thinks that we  should not add 
> this usecase?
> >>
> >> Regards,
> >>  Ahmad
> >>
> >>
> >>
> >>  ________________________________
> >> From: Desire Oulai [mailto:[e-mail]]
> >>  Sent: Monday, December 01, 2008 2:46 PM
> >> To: [e-mail]
> >> Cc: Muhanna,  Ahmad (RICH1:2H10)
> >> Subject:
> >>
> >> Hi Ahmad,  All,
> >>
> >>  The Binding revocation draft does not  mention revocation 
> related to NEMO.
> >> If used as is, the BRI will  revoke the binding between 
> the MR's HoA and
> >> CoA.
> >> I  think it's woth adding another level of revocation: 
> revocation of  Mobile
> >> Network Prefixes. A HA may decide to stop forwarding data  
> to the CoA for
> >> certain MNPs and BR could be used for that. Here is  a 
> proposed text for a
> >> new section:
> >>
> >> "In  case of NEMO protocol, the HA follows the same 
> procedure as MIPv6  if
> >> the
> >> goal is to revoke the binding between the  Mobile Router's 
> HoA and CoA. It
> >> is
> >> also possible to  have finer granularity of revocation 
> targeting the Mobile
> >> Network  Prefixes assigned to the Mobile Router. In this 
> case, the HA sends
> >>  a
> >> BRI message including one or more MNP options with the A 
> bit set  and the
> >> Revocation Trigger set to a proper value, e.g.  
> Administrative Reasons.
> >> When
> >> receiving this BRI, the  MR deletes the MNP(s) from the 
> Prefix Information
> >> field in the  Binding Update List and responds with a BRA 
> message. The BRA
> >> MUST  include the MNP(s) contained in the BRI."
> >>
> >> Also, Mobile  network Prefix should be addes as valid 
> option in section
> >>  "6.2.
> >> Binding Revocation Acknowledgement  Message".
> >>
> >> BR
> >>  Desire
> >>
> >>  _______________________________________________
> >> MEXT mailing  list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mext
> >>
> >>
> >
> >
> 
> 
>       
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://www.ietf.org/pipermail/mext/attachments/20081205/2037f
> 5cb/attachment-0001.htm>
> 
> ------------------------------
> 
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
> 
> 
> End of MEXT Digest, Vol 18, Issue 5
> ***********************************
> 
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext