Re: [multimob] Fast Handover Solutions + Closing Multimob

["Thomas C. Schmidt" <[e-mail]>]

Hi Stig,

On 16.11.2012 00:43, Stig Venaas wrote:

> On 11/15/2012 11:10 AM, Thomas C. Schmidt wrote:
>> Hi Carlos,
>>
>> just a short answer: Chairs asked me in personal communication to send
>> these requirements.
>
> I don't recall that, but happy to see them posted here.
>

Well, this was you in Atlanta in an oral discussion with Gorry.

>> For the rest:
>>
>> We have had lengthy discussions over months on all the subjects, on-list
>> and off-list, mentioning all types of pro's and con's. I don't want to
>> repeat this.
>>
>> We finally agreed (with chairs) off-list to adopt both drafts as
>> experimental ... but then some people behaved differently from what they
>> had said earlier.
>
> I don't recall that either.
>

This was Behcet in an Email discussion with Marco, Carlos & Carlos.

Cheers,

Thomas

>> My view on the general situation is that there are two kinds of
>> reasonable work for Multimob
>>
>>   (i) Basic enabling of PMIP multicast
>>   (ii) Convincing coverage of the solution space in relevant scenarios
>>
>> (i) will be done by Multimob with the Base + MLD RFCs and the source
>> solution.
>>
>> Ad (ii), my impression is that Multimob is not really doing a decent
>> job. In fact, I have severe doubts that any of the work on track will be
>> of any value to anyone.
>>
>> So I believe we should start thinking about closing Multimob.
>
> We should finish the existing charter items, but I also think we need to
> consider seriously whether it is worth adding new charter items. I feel
> when we've completed the current items we've pretty much solved the more
> obvious issues. Once PMIP with multicast gets more deployment it can be
> reconsidered whether more IETF work is needed. I think it's best to do
> the DMM multicast work in DMM. I'm not necessarily saying that multimob
> should be closed any time soon, but we do need to at least have this
> discussion. It is a natural part of the rechartering discussion.
>
> Stig
>
>> Cheers,
>>
>> Thomas
>>
>>
>> On 15.11.2012 18:56, Carlos Jesús Bernardos Cano wrote:
>>> Hi Thomas, all,
>>>
>>> Please see some comments inline below.
>>>
>>> On Mon, 2012-11-12 at 23:28 +0100, Thomas C. Schmidt wrote:
>>>> Hi all,
>>>>
>>>> after the - somewhat uninformed discussion at IETF85 - chairs asked me
>>>> to restate requirements of a "fast handover solution" for Multicast
>>>> Mobility.
>>>
>>> I don't recall the chairs asking you to restate the requirements of a
>>> "fast handover solution", and the minutes do not reflect that either.
>>> Our AD asked the WG to document the requirements of the different
>>> solutions the WG is working on, as well as the feedback obtained from
>>> operators interested in multimob work.
>>>
>>> Actually, the WG already has a WG document for the fast handover
>>> solution milestone, and during initial discussions and the adoption
>>> process, we did have discussions on different aspects of how a fast
>>> handover solution should operate and the different requirements it
>>> should meet. There have been several reviews of the WG document and it
>>> captures feedback from the WG.
>>>
>>>>
>>>> Here they are:
>>>
>>> This list, IMHO, is not complete. For example, one critical aspect that
>>> has been discussed several times is how generic the solution is and what
>>> requirements it imposes on the different involved entities, as for
>>> example the need of layer-2 triggers on the mobile node.
>>>
>>>>
>>>>    (i) Handover should be fast (this is only true for a direct
>>>> pMAG/AR to
>>>> nMAG/AR solution such as
>>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast).
>>>>
>>>>
>>>
>>> The handover speed will highly depend on the network topology in place.
>>> It cannot be generally stated that direct communication will always be
>>> faster than MAG to LMA communication. In fact, taking into account
>>> typical operative networks, an strict hierarchical topology is commonly
>>> deployed where the communication among different elements located in
>>> different access networks pass through central elements, using an star
>>> topology. Considering that a MAG could be able to serve a huge number of
>>> radio accesses, the more logical trend could be to deploy separated
>>> MAGs, without direct connectivity capabilities. Additionally, as
>>> previously discussed on this mailing list, you should note that the
>>> reactive case for FPMIPv6 is extremely harmful from the multicast
>>> handover delay perspective, as it needs to firstly register the MN and
>>> resolve the MLD Query process of RFC6224 to trigger the reactive
>>> mechanism afterwards. There is for sure no improvement regarding
>>> RFC6224. Furthermore, the dependency on the radio part (for layer-2
>>> trigger capabilities) definitely limits the potential benefits that your
>>> proposal could provide.
>>>
>>>>
>>>>    (ii) Multicast handover should be fully synchronized with unicast
>>>> handover (otherwise unicast and multicast states diverge as is a
>>>> well-known issue for the RAMS-approach, i.e.,
>>>> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover).
>>>>
>>>
>>> The adopted WG document draft-ietf-multimob-fast-handover (previously
>>> aka RAMS, now SIAL) is totally synchronized with the unicast handover,
>>> up to the point that it is triggered by the registration and/or
>>> de-registration messages of the unicast handover. It is difficult to
>>> achieve a better integration. In the proactive case, the de-registration
>>> message for unicast handover sent by the pMAG conveys the multicast
>>> membership subscription context for the moving MN. In the reactive case,
>>> the registration message for the MN attaching to the nMAG triggers the
>>> process, and the response to the registration PBU conveys the multicast
>>> membership subscription context. Do you really think these are not
>>> synchronized processes?
>>>
>>> BTW, what is the "well-known" issue you refer to?
>>>
>>>>    (iii) Multicast handover solutions should tightly integrate with
>>>> unicast handover (only
>>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast
>>>>
>>>>
>>>> integrates with PFMIPv6 and FMIPv6).
>>>>
>>>
>>> The key point here is to be *integrated* with PMIPv6 in a *general* way.
>>> The integration of SIAL with PMIPv6 is ensured as described above.
>>> Furthermore, it is general because it does not impose the necessity of
>>> additional layer-2 capabilities in the MN to work. This does not happen
>>> with other solutions, including yours.
>>>
>>> Additionally, this has been discussed already in the WG. Several
>>> individuals, such as Marco, expressed that unicast and multicast
>>> handovers have different considerations. The WG consensus was to not to
>>> specify in the adopted document a solution bound to a unicast handover
>>> optimization solution.
>>>
>>>>    (iv) Handover management should reuse standard mobility and
>>>> multicast
>>>> protocol operations for easy implementation and deployment
>>>> (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast
>>>>
>>>>
>>>> introduced the use of standard IGMP/MLD records for context description
>>>> in transfer, which has been copied several times).
>>>
>>> draft-ietf-multimob-fast-handover incorporated the use of the standard
>>> multicast address record format as result of the WG feedback.
>>>
>>>>
>>>>    (v) Multicast handover management should integrate ASM and SSM, as
>>>> well as IPv4 (IGMP) and IPv6 (MLD), which is only provided by
>>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast.
>>>>
>>>>
>>>
>>> Since the SIAL solution deals with multicast membership subscription
>>> context transfer, no issues relate to ASM and SSM. Regarding the IPv4
>>> treatment, we thank you for pointing this out and this is going to be
>>> addressed in the next revision of the document, as we discussed during
>>> the Atlanta meeting. We don't foresee any significant issue on adding
>>> that support, and we of course welcome any contribution from you or any
>>> other WG member on this aspect.
>>>
>>>>
>>>> Based on these facts, chairs and AD proclaimed to re-decide on future
>>>> paths for Multimob fast handover solutions.
>>>
>>> Again, based on what I recall, that seems to match what is captured in
>>> the minutes, what was discussed is that the AD would check with the
>>> chairs the process of the adoption call of
>>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast. I don't quite see how a
>>> formal process revision (decision of the chairs on a WG adoption
>>> document) relates with your e-mail.
>>>
>>> Thanks,
>>>
>>> Carlos
>>>
>>>>
>>>> Cheers,
>>>>
>>>> Thomas
>>>
>>
>

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °