Subject: Re: [Mipshop] Adoption ofdraft-liebsch-netlmm-transient-bce-pmipv6as a WG document

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 21 Oct 2008 14:44:57 +0900

Hi Rajeev,

On 2008/10/21, at 14:44, Koodli, Rajeev wrote:

>
>
>>> The issue only gets hot for PMIP. As long as the mobile terminal
>>> handles the signalling it can synchronise between the bindings. But
>>> once you delegate the signalling to (two different) MAGs we need the
>>> new functionality. Once operators start using PMIP they will ask for
>>> this optimisation ;-)
>>
>> You have to remember that MIP6 has FMIP to optimize HO.
>
> [RKo:>] I don't see why we would be doing things all over.. May be I  
> am missing something.
>
>> IMO, MIPSHOP should consider the relationship between PFMIP and tBCE
>> if both documents will be WG doc.
>
> [RKo:>] PFMIP is for providing handover solution for a) packet loss  
> (both uplink and downlink), b) delay, and c) context transfer. It is  
> meant for Standards Track, and is a dependency on Inter-HSGW  
> handovers in eHRPD.
> I don't know how you would compare it to tBCE.

The goal of PFMIP covers HO optimization (which is the goal of tBCE).

regards,
ryuji

>> I'm also worry about the conflicts between tBCE and multihoming
>> solutions.
>> There is no concrete multihoming solutions to PMIP yet.
>> My concern is that nobody can tell if there will be conflicts or not
>> at this point.
>
> [RKo:>] I agree. Multihoming needs more thought as we discussed in  
> NetExt, which would be a good place for further work.
>
> -Rajeev
>
>
>>
>> regards,
>> ryuji
>>
>>
>>>
>>>
>>> Oliver
>>>
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: [email-masked]
>>>> [mailto:[email-masked]] Im Auftrag von Ryuji Wakikawa
>>>> Gesendet: Montag, 20. Oktober 2008 11:38
>>>> An: Ahmad Muhanna
>>>> Cc: [email-masked]
>>>> Betreff: Re: [Mipshop] Adoption of
>>>> draft-liebsch-netlmm-transient-bce-pmipv6as a WG document
>>>>
>>>> Hello Ahmad,
>>>>
>>>> Sorry for responding late...
>>>>
>>>> At Wed, 15 Oct 2008 23:28:53 -0500,
>>>> Ahmad Muhanna wrote:
>>>>>
>>>>> Hello Ryuji,
>>>>> Sorry for responding a little late:) but let me add to the
>>>> discussion  > you had with Oliver and Marco. please see some
>>>> comments inline.
>>>>>
>>>>> Regards,
>>>>> Ahmad
>>>>>
>>>>>> Subject: Re: [Mipshop] Adoption of
>>>>>> draft-liebsch-netlmm-transient-bce-pmipv6 as a WG
>>>> document  > >  > > Hi Vijay,  > >  > > Some of issues
>>>> discussed in this document can be solved by  > > implementations.
>>>>>
>>>>> [Ahmad]
>>>>> As probably has been pointed out by Oliver and Marco, the
>>>> answer here is  > sure, you can design some implementation to
>>>> hopefully capture a solution  > for this issue; however, it
>>>> will be beneficial for us on this mailing  > list to examine
>>>> such implementation in order to evaluate if it really  > works
>>>> or NOT. Please explain what you have in mind.
>>>>
>>>> Do you want me to implement it and evaluate it?
>>>> I no longer work for University and don't have any students to  
>>>> ask;-<
>>>>
>>>> The idea is very simple, before removing a (proxy) binding,
>>>> LMA just hold it with certain pre-configured time.
>>>>
>>>>> In the meantime, I fundamentally disagree with handling
>>>> such issue using  > some arbitrary mechanism or solution other
>>>> than SECURE control  > signaling. This is clearly a change
>>>> that impacts the mobile node BCE at  > the LMA which was NOT
>>>> created in random BUT via a secure PMIPv6  > signaling and
>>>> MUST continue to be maintained via PMIPv6 protocol  >
>>>> specification as captured in RFC5213 or a new enhancement to
>>>> such  > signaling.
>>>>
>>>> Well, I agree the SECURE part.
>>>> I believe static configuration is most secured way in most of
>>>> scenarios;-)
>>>>
>>>>> Having said all of the above, please remember to make sure
>>>> that your  > implementation "tweak" or "kluge" :) is inline
>>>> with the above assumption  > which is applicable to any protocol.
>>>>>
>>>>>
>>>>>> For instance, the uplink issue (section 3.2.2) and others
>>>> are  > > also happened to Mobile IPv6 operation.
>>>>> [Ahmad]
>>>>> TRUE.
>>>>>
>>>>> Also, similar issue has been identified in the case of
>>>> MIPv4 too and  > there is a work in progress to address that
>>>> at MIP4. But what is the  > point you are trying to make here?
>>>>
>>>> OK. I wonder why nobody raise this issue at MIP6.
>>>> Maybe no operators yet? :-)
>>>>
>>>>
>>>>>> We had same problem, but we can use implementation trick
>>>> to  > > solve the issue (delaying the BC removal, etc).
>>>>>
>>>>> [Ahmad]
>>>>> Hmmmmm... Interesting approach.
>>>>> I may rephrase this as follows "yes we have a problem but
>>>> what about  > adopting a kluge to solve it"!
>>>>> Also, delaying the removal of which BC? Could you please
>>>> explain a  > little more.
>>>>>
>>>>> Thanks as always!
>>>>
>>>> - receiving deregistration BU
>>>> - the target BCE marked as old/dead/whatever-BCE
>>>> - receiving registration BU
>>>> - creating a new BCE
>>>> - removing old-BCE after certain time
>>>>
>>>> We can implement this in similar way of tBCE with no signaling.
>>>> tBCE only carries the lifetime, it's to be expected.
>>>>
>>>>
>>>>>> It looks too complicated to solve such transient issue.
>>>>>>
>>>>> [Ahmad]
>>>>> Why?
>>>>> Is there any defect in the proposed solution? If there is
>>>> one, please  > help us identify it to fix it.
>>>>> Thanks again.
>>>>
>>>> Maybe my question is do you really need dynamic lifetime
>>>> assignment (from MAG?) on this? How much different lifetime
>>>> (10msec, 1sec,
>>>> 10sec?) do you expect to configure at MAG depending on access
>>>> media or what metrics?!
>>>>
>>>>
>>>>>> In addition, this document deals with one part of
>>>> multihoming  > > support for PMIP (i.e. The use of multihoming
>>>> to improve the  > > inter-tech HO.) If we will extend PMIP to
>>>> support  > > multihoming, I would like to discuss this
>>>> document at the  > > same time of multihoming discussion.
>>>>>
>>>>> [Ahmad]
>>>>> Sure, it may be perceived as having a flavor of
>>>> multihoming, but it  > seems that you agree that multihoming
>>>> needs to be addressed via a  > protocol signaling mechanism
>>>> while at the same time for this "special  > case of
>>>> multihoming" you suggest using some implementation tricks!:)
>>>>
>>>> If this is "special case" of multihoming, why do we need to
>>>> have this item now?
>>>>
>>>> Multihoming related part in tBCE is the case of inter-tech HO
>>>> scenario (MBB). Other parts are just how to treat data from
>>>> oMAG in such short minutes...
>>>>
>>>> Is MBB the scope of this work -> chairs?
>>>>
>>>> regards,
>>>> ryuji
>>>>
>>>>
>>>>
>>>>
>>>>>>
>>>>>> regards,
>>>>>> ryuji
>>>>>>
>>>>>> On 2008/09/25, at 3:55, Vijay Devarapalli wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> At the MIPSHOP WG meeting at the last IETF, there was
>>>> sufficient  > > > support to adopt  > >
>>>> draft-liebsch-netlmm-transient-bce-pmipv6-01.txt as a  > > >
>>>> WG document. We would like to confirm that consensus on the
>>>> mailing  > > > list. You can find the latest document at  > >
>>>>>>>
>>>> http://www.ietf.org/internet-drafts/draft-liebsch-netlmm-transient-
>>>> bce
>>>>>>> -p
>>>>>>> mipv6-01.txt
>>>>>>>
>>>>>>> Please respond by October 10, if you support or do not
>>>> support  > > > adopting the document as a WG document. If you
>>>> have already  > > expressed  > > > your opinion in the WG
>>>> meeting, there is no need to send an  > > email on  > > > this.
>>>>>>>
>>>>>>> The intended status for this document is Experimental.
>>>>>>>
>>>>>>> Vijay
>>>>>>> _______________________________________________
>>>>>>> Mipshop mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/mipshop
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mipshop mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/mipshop
>>>>>>
>>>>
>>>> _______________________________________________
>>>> Mipshop mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mipshop
>>>>
>>
>> _______________________________________________
>> Mipshop mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mipshop
>
>
> This email and any attachments may contain legally privileged and/or  
> confidential information of Starent Networks, Corp. and is intended  
> only for the individual or entity named in the message.  The  
> information transmitted may not be used to create or change any  
> contractual obligations of Starent Networks, Corp.  Any review,  
> retransmission, dissemination or other use of, or taking of any  
> action in reliance upon this e-mail and its attachments by persons  
> or entities other than the intended recipient is prohibited. If you  
> are not the intended recipient, please notify the sender immediately  
> -- by replying to this message or by sending an email to [email-masked] 
>  -- and destroy all copies of this message and any attachments  
> without reading or disclosing their contents. Thank you.

_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 21 Oct 2008 01:57:48 -0400

Hi Ryuji,

> The goal of PFMIP covers HO optimization (which is the goal of tBCE).

[RKo:>] That's a fairly broad goal, isn't it?

I tend to agree with you that what is being proposed by tBCE can be handled as an implementation at LMA, without a protocol.

Regards,

-Rajeev

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 21 Oct 2008 15:07:09 +0900

Hello Rajeev,

> [RKo:>] That's a fairly broad goal, isn't it?

right, it's fairly broad.

> I tend to agree with you that what is being proposed by tBCE can be  
> handled as an implementation at LMA, without a protocol.

:-)

IMO, it is enough for tBCE to write modifications to LMA internal  
process (no protocol).

regards,
ryuji

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 21 Oct 2008 02:15:13 -0400

> The goal of PFMIP covers HO optimization (which is the goal of tBCE).

[RKo:>] BTW, this is a good point for the WG, and the chairs. 
As I mentioned, PFMIP is providing Inter-GW handovers (packet loss, delay and context transfers), and there is an expressed need for it.

I guess the WG has to decide what problem is being addressed by tBCE that needs a protocol support. 

Thanks,

-Rajeev

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 21 Oct 2008 02:17:54 -0400

> IMO, it is enough for tBCE to write modifications to LMA internal

[RKo:>] I think this could be useful as an Informational document. 

Regards,

-Rajeev

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 21 Oct 2008 10:53:31 +0200

Hi Rajeev,

sorry to intervene your discussion with Ryuji, but please let me
refer to the MIPSHOP WG meeting at IETF72, where
we discussed clearly distinguished use cases between tBCE and
PFMIP and how the approaches can complement each other.
I don't think we need to turn into cycle mode here.

As a result from the consensus call, it was the right decision
to include tBCE to the charter as experimental document first.

Thanks,
marco

Koodli, Rajeev wrote:
>>>>> -- by replying to this message or by sending an email to
>>>>>           
>>>> [email-masked]
>>>>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 21 Oct 2008 14:09:43 -0400

Yes, we did discuss it. And, I made the same point then.
I think it would be useful to document the LMA behavior. 
The need for a protocol is not clear, as also observed by others.

Regards,

-Rajeev

> -----Original Message-----
> From: Marco Liebsch [mailto:[email-masked]]
> Sent: Tuesday, October 21, 2008 1:54 AM
> To: Koodli, Rajeev
> Cc: Ryuji Wakikawa; [email-masked]
> Subject: Re: [Mipshop] Adoption ofdraft-liebsch-netlmm-transient-bce-
> pmipv6as a WG document
> 
> Hi Rajeev,
>

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 22 Oct 2008 09:59:02 +0200

> I think it would be useful to document the LMA behavior.
Yes, we took your comment into account and that's what the specification 
does.
> The need for a protocol is not clear, as also observed by others.
We clarified that and explained why the PBU to terminate the transient 
state is useful.
However, that's optional.

marco
>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-liebsch-netlmm-
>>>>>>>>>>                     
>> transient-
>>     
>>>>>>>>>> bce
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>>>> -p
>>>>>>>>>>>>> mipv6-01.txt
>>>>>>>>>>>>>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 22 Oct 2008 17:17:30 -0400

> Yes, we took your comment into account and that's what the specification

[RKo:>] Okay. 

> However, that's optional.

[RKo:>] So, if I understand it right, the protocol is optional, and the intention is to describe the recommended LMA behavior?

Thanks,

-Rajeev