Re: [multimob] Fast Handover Solutions + Closing Multimob

[Stig Venaas <[e-mail]>]

Hi

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.

> 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.

> 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
>>
>