Re: [multimob] Fast Handover Solutions + Closing Multimob

[Stig Venaas <[e-mail]>]

Hi

On 15.11.2012 15:52, Thomas C. Schmidt wrote:
> 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.

Right, I remember we discussed about requirements. I don't
remember exactly about posting them, but it certainly is a
good idea.

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

OK. Ideally we should as a group evaluate the proposals and pick the
one that we believe best fits the requirements, or maybe another
solution. Coming up with 2 solutions is not that good, unless we
believe there really is a need for 2 solutions. But it may be an
option.

Stig

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