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

[Behcet Sarikaya <[e-mail]>]

Hi Desire,

Ahmad is to add some text to his draft on Nemo support not for revoking MNPs but on how binding revocation can be used for Nemo. Let's see this new version and discuss.


Regards,

Behcet


________________________________
From: Desire Oulai <[e-mail]>
To: [e-mail]; Ahmad Muhanna <[e-mail]>
Cc: [e-mail]
Sent: Monday, December 8, 2008 11:48:05 AM
Subject: Re: [MEXT] MEXT Digest, Vol 18, Issue 5

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



      

_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext