Subject: Re: [MEXT] Text to close issue #9 (Simultaneous Mobility)

From: Ashutosh Dutta <[email-masked]>
Date: Thu, 05 Mar 2009 22:08:09 -0500

Hesham,
        Thanks. I think the modified first sentence of the last 
paragraph makes it more clear. I am copying to mailing list.

Thanks
Ashutosh

Hesham Soliman wrote:
> 
> 
> On 6/03/09 1:53 PM, "Ashutosh Dutta" <[email-masked]> wrote:
> 
>> Hesham, I still do not understand, why RR will be triggered by movement
>> or loss of end-to-end communication.
> 
> => The idea is to handle both cases: a) simultaneous mobility and b) loss of
> BCE. So, perhaps the sentence should be:
> 
> "The return routability procedure may be triggered by movement of the mobile
> node or by sustained loss of end-to-end communication with a correspondent
> node (e.g. based on indications from upper-layers) that has a route
> optimised connection to the mobile node."
> 
> Hesham
> 
> 
> I think that is the standard MIPv6
>> procedure anyway, right?
>>
>> Also, what is the connection between the first sentence and second
>> sentence in this paragraph.
>>
>> Thanks
>> Ashutosh
>>
>>
>> Hesham Soliman wrote:
>>>
>>> On 6/03/09 6:19 AM, "Ashutosh Dutta" <[email-masked]> wrote:
>>>
>>>> Hesham, Raj,
>>>>
>>>>
>>>> I am Ok with the suggested text, and I also think it is probably good to
>>>> have this text in 3775bis version to cover the simultaneous mobility
>>>> scenario.
>>>>
>>>> Also, the following paragraph (first sentence) does not read well, there
>>>> is perhaps a typo.
>>>>
>>>> "The return routability procedure may be triggered but movement or
>>> => sorry s/but/by
>>>
>>> Hesham
>>>
>>>> sustained loss of end-to-end communication with the correspondent node
>>>> (e.g. based onindications from upper-layers). If such indications are
>>>> received, the mobile node may revert to bi-directional tunnelling while
>>>> re-starting the return routability procedure."
>>>>
>>>> Thanks
>>>> Ashutosh
>>>>
>>>> [email-masked] wrote:
>>>>> Hi Hesham,
>>>>>
>>>>> While your text does propose some corrective actions that the MN could take
>>>>> in the scenario where the MN and CN are mobile, I do not believe it is
>>>>> going
>>>>> to make the RO feature in the base spec any more usable. I am fine with
>>>>> having this text included in the 377bis version of the I-D if there is
>>>>> consensus that it covers a missing scenario and is useful to do so. I would
>>>>> also be okay if nothing is changed with the route optimization feature in
>>>>> the base spec and instead the WG decides to work on specifying this feature
>>>>> in a separate spec and address all scenarios.
>>>>>
>>>>> -Raj
>>>>>
>>>>>
>>>>> On 3/5/09 5:00 AM, "ext Hesham Soliman" <[email-masked]> wrote:
>>>>>
>>>>>> Hi Charlie,
>>>>>>
>>>>>> Please find a suggestion below.
>>>>>>
>>>>>> <text> In some scenarios, such as simultaneous mobility, where both
>>>>>> correspondent host and mobile host move at the same time, or in the case
>>>>>> where the correspondent node reboots and loses data, route optimization
>>>>>> may
>>>>>> not complete, or its data in the binding cache might be lost.
>>>>>>
>>>>>> To provide graceful recovery from those cases, the following should be
>>>>>> done:
>>>>>>
>>>>>> - Return Routability signalling MUST be sent to the correspondent node's
>>>>>> home address if it has one (i.e. If the correspondent node is also mobile)
>>>>>>
>>>>>> - If Return Routability signalling timed out after MAX_RO_FAILURE
>>>>>> attempts,
>>>>>> the mobile node MUST fallback to sending packets through its home agent,
>>>>>> to
>>>>>> the correspondent node's home address.
>>>>>>
>>>>>> The mobile node may run the bidirectional tunnelling in parallel with the
>>>>>> return routability procedure until it is successful. Exponential backoff
>>>>>> SHOULD be used for retransmission of return routability messages.
>>>>>>
>>>>>> The return routability procedure may be triggered but movement or
>>>>>> sustained
>>>>>> loss of end-to-end communication with the correspondent node (e.g. based
>>>>>> on
>>>>>> indications from upper-layers). If such indications are received, the
>>>>>> mobile
>>>>>> node may revert to bi-directional tunnelling while re-starting the return
>>>>>> routability procedure.
>>>>>>
>>>>>>
>>>>>> </text>
>>>>>>
>>>>>> MAX_RO_FAILURE = 3
>>>>>>
>>>>>>
>>>>>> I hope this is a good start. I tried to account for both simultaneous
>>>>>> mobility and loss of the BC entry.
>>>>>>
>>>>>> Hesham
>>>>>>
>>>>>>
>>>>>> On 28/02/09 4:50 AM, "Charles E. Perkins" <[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello Hesham,
>>>>>>>
>>>>>>> You are on the hook for some text to close issue #9.
>>>>>>> According to the minutes:
>>>>>>>> - issue #9, simultaneous mobility (defect)
>>>>>>>>   Nobody has observed this in practice, it may be a rare case that
>>>>>>>> doesn't
>>>>>>>>   require a solution.  There are multiple proposals and possibilities,
>>>>>>>> but
>>>>>>>>   none are clearly winners.
>>>>>>>>   Raj Patil thinks we should pull RO out and publish separately, fixing
>>>>>>>>     this problem there.
>>>>>>>>   Julien proposes to leave it as an implementation issue.
>>>>>>>>   Hesham says we can explain the tradeoffs.
>>>>>>>>   *HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING TRADEOFFS
>>>>>>>> OF
>>>>>>>>     DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE TUNNELLING*
>>>>>>>>  
>>>>>>> I looked, and I don't think I ever received anything from
>>>>>>> you about this.  Could you supply some text in the next
>>>>>>> few days?
>>>>>>>
>>>>>>> Thanks in advance for your consideration of my request!
>>>>>>>
>>>>>>> Regards,
>>>>>>> Charlie P.
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> MEXT mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>> _______________________________________________
>>>>> MEXT mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>
> 
>