Re: [multimob] Fast Handover Solutions

[John William Atwood <[e-mail]>]

As an aside, while the draft name does not appear in the RFC, it _will_
appear in the datatracker entry for the RFC (once the RFC is published).
 I support Rajeev's suggestion to fix the name of the draft (even though
the draft is already at the -03 level).

  Bill

On 11/27/2012 2:23 PM, Rajeev Koodli (rkoodli) wrote:
> 
> Hi Stig,
> 
> 
> On 11/27/12 10:53 AM, "Stig Venaas" <[e-mail]> wrote:
> 
>> On 11/27/2012 10:19 AM, Rajeev Koodli (rkoodli) wrote:
>>>
>>> Thanks for checking.
>>>
>>> To avoid the confusion, kindly rename the draft appropriately.
>>> The draft title and the draft name should be consistent, and not
>>> mislead,
>>> as it does now.
>>
>> It's a bit misleading, but the name does not matter much. The RFC won't
>> have the draft name mentioned anywhere.
> 
> IMHO, that's not a reason to be sloppy and misleading.
> You didn't say what's the issue with using the appropriate draft name?
> 
> 
>>
>> Can't we rather discuss how the two real fast handover drafts meet
>> the requirements?
> 
> I admit I am not on this alias much.
> 
> I don't understand what is considered "fast handover" here.
> Based on what I have read, it's supposed to be a closed issue, and the WG
> is moving on with the WG ID that is called "*-fast-handover-*".
> And, I have an issue with this misleading naming suggested/adopted by the
> chairs.
> Please fix the name.
> 
> That's it! :-)
> 
> -Rajeev
> 
> 
> 
> 
>>
>> Stig
>>
>>>
>>> -Rajeev
>>>
>>>
>>> On 11/27/12 9:24 AM, "Behcet Sarikaya" <[e-mail]> wrote:
>>>
>>>> Hi Rajeev,
>>>>
>>>> I checked again.
>>>> The charter item is about PMIPv6 handover optimizations, not on fast
>>>> handover.
>>>>
>>>> The draft name should have been handover-optimizations not
>>>> fast-handover.
>>>>
>>>> Sorry about that because I had suggested this draft name.
>>>>
>>>> Without realizing that it would cause so much trouble.
>>>>
>>>> I repeat here again, the draft title did not change and the draft
>>>> content is reflected in the title. This is the most important thing.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Behcet
>>>>
>>>> On Mon, Nov 26, 2012 at 6:07 PM, Rajeev Koodli (rkoodli)
>>>> <[e-mail]> wrote:
>>>>>
>>>>>
>>>>> Hi Behcet,
>>>>>
>>>>> On 11/26/12 1:46 PM, "Behcet Sarikaya" <[e-mail]> wrote:
>>>>>
>>>>>> On Mon, Nov 19, 2012 at 6:27 PM, Thomas C. Schmidt
>>>>>> <[e-mail]> wrote:
>>>>>>> Hi Behcet,
>>>>>>>
>>>>>>> these requirements are for a fast handover solution, i.e., a
>>>>>>> protocol
>>>>>>> that
>>>>>>> operates a *handover* in a *fast* manner.
>>>>>>>
>>>>>>> I agree that draft-ietf-multimob-fast-handover does not meet the
>>>>>>> requirements, but had written earlier on the list that the name of
>>>>>>> this
>>>>>>> draft is misleading in two ways: (i)
>>>>>>> draft-ietf-multimob-fast-handover
>>>>>>> is
>>>>>>> not a fast handover solution, and (ii) the name "fast handover" is
>>>>>>> tied
>>>>>>> to
>>>>>>> RFC5568/RFC5949-like schemes for good reasons.
>>>>>>>
>>>>>>
>>>>>> The draft title contains ... handover optimization ... and it
>>>>>> reflects
>>>>>> its content.
>>>>>> We asked for this WG draft name because of the charter item to which
>>>>>> it corresponds.
>>>>>
>>>>> Sorry, which charter item has "fast-handover"?
>>>>> Could you clarify?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> -Rajeev
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> I think this clarifies your confusion.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Behcet
>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>>
>>>>>>> On 20.11.2012 00:09, Behcet Sarikaya wrote:
>>>>>>>>
>>>>>>>> Hi Thomas,
>>>>>>>>
>>>>>>>> It seems that these requirements are for
>>>>>>>>
>>>>>>>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast
>>>>>>>>
>>>>>>>> and not for
>>>>>>>> draft-ietf-multimob-fast-handover.
>>>>>>>>
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Behcet
>>>>>>>>
>>>>>>>> On Mon, Nov 12, 2012 at 4:28 PM, Thomas C. Schmidt
>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> after the - somewhat uninformed discussion at IETF85 - chairs
>>>>>>>>> asked
>>>>>>>>> me to
>>>>>>>>> restate requirements of a "fast handover solution" for Multicast
>>>>>>>>> Mobility.
>>>>>>>>>
>>>>>>>>> Here they are:
>>>>>>>>>
>>>>>>>>>    (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-mu
>>>>>>>>> lt
>>>>>>>>> ic
>>>>>>>>> ast).
>>>>>>>>>
>>>>>>>>>    (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).
>>>>>>>>>
>>>>>>>>>    (iii) Multicast handover solutions should tightly integrate
>>>>>>>>> with
>>>>>>>>> unicast
>>>>>>>>> handover (only
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mu
>>>>>>>>> lt
>>>>>>>>> ic
>>>>>>>>> ast
>>>>>>>>> integrates with PFMIPv6 and FMIPv6).
>>>>>>>>>
>>>>>>>>>    (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-m
>>>>>>>>> ul
>>>>>>>>> ti
>>>>>>>>> cast
>>>>>>>>> introduced the use of standard IGMP/MLD records for context
>>>>>>>>> description
>>>>>>>>> in
>>>>>>>>> transfer, which has been copied several times).
>>>>>>>>>
>>>>>>>>>    (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-mu
>>>>>>>>> lt
>>>>>>>>> ic
>>>>>>>>> ast.
>>>>>>>>>
>>>>>>>>> Based on these facts, chairs and AD proclaimed to re-decide on
>>>>>>>>> future
>>>>>>>>> paths
>>>>>>>>> for Multimob fast handover solutions.
>>>>>>>>>
>>>>>>>>> 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]
>>>>>>>>> °
>>>>>>>>> _______________________________________________
>>>>>>>>> multimob mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/multimob
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> 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] °
>>>>>> _______________________________________________
>>>>>> multimob mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/multimob
>>>>>
>>>
>>> _______________________________________________
>>> multimob mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/multimob
>>>
>>
> 
> _______________________________________________
> multimob mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multimob
> 

-- 
Dr. J.W. Atwood, Eng.             tel:   [phone] x3046
Distinguished Professor Emeritus  fax:   [phone]
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[e-mail]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8