Re: [Mipshop] Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

[Vijay Devarapalli <[e-mail]>]

On 9/13/10 6:46 AM, Marco Liebsch wrote:
> Hi Vijay,
>
> please find some text for a revived section 4.7 MN Operation below.
> Text in section 4.3.1 could then refer to this new section 4.7 to
> link context.
>
> 4.7. MN operation
>
> For single-radio handover, this specification does not require any
> extended mode of operation on the MN when compared to [RFC5213].

Replace the above with

   For a single-radio handover, this specification does not require
   any additional functionality on the mobile node, when compared to
   [RFC 5213].

> During dual-radio handover, the MN benefits most from the transient
> BCE extension to PMIPv6 when it is able to keep communication on the
> previous interface while it is setting up its handover target
> interface with the configuration context which has been received as a
> result of the new interface's attachment to the nMAG. Various
> techniques enable support for such operation, e.g. the use of a
> virtual interface on top of physical radio interfaces or
> implementation specific extensions to the MN's protocol stack.
> Details about how to enable such make-before-break support on the MN
> are out of scope of this document.

Looks ok. BTW, I think its ok to include the reference to the NETEXT 
draft for the virtual interface (see Julien's email).

Vijay

>
>
> marco
>
>
> Vijay Devarapalli wrote:
>> On 9/10/10 3:59 AM, Jari Arkko wrote:
>>> Is some document change needed?
>>
>> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE
>> only if it knows the MN supports transient BCE. Two issues with this.
>>
>> 1. If its a single radio handover, nothing needs to be supported on
>> the MN. Just whatever is needed according to RFC 5213.
>>
>> 2. For a dual radio handover, to get the true benefit from transient
>> BCE, the MN needs to be able to receive packets on two interfaces at
>> the same time for a short while. If it does not do this, transient BCE
>> would still work, and the MN does benefit, but there will be some
>> packet loss.
>>
>> This is not really captured in the draft.
>>
>> For the actual text changes, it is going to be hard for me to suggest
>> text changes since its been a year since I read the draft. I have to
>> go through it again. Marco would probably be able to come up with text
>> changes much more quickly.
>>
>> Perhaps we should add a section on the mobile node support for
>> transient BCE and explain clearly what needs to be supported on the
>> mobile node.
>>
>> Vijay
>