Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt

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

Hi Shuai,

many thanks for your earlier review and sorry that we picked up work on
this late.

We're now catching up and try to finalize the document (as it had been
struck by an unexpected last call ;) ).

Please see answers inline:

On 25.09.2013 09:49, Shuai Gao wrote:

> As promised at IETF-87, I have reviewed the Fast Handover draft. Overall the I-D is in very good shape. I have a few comments for your consideration.
> 
> 1)	P3: improve these handover delays for unicast communication to the order of the maximum delay needed for link switching and signaling between Access Routers (ARs) or Mobile Access Gateways (MAGs) [FMIPv6-Analysis]. ==> improve the performance of handover delays…… Also, what does “to the order” mean in this sentence?

You're right, this sentence is a bit imprecise. We changed to

   Mobile IPv6
   Fast Handovers (FMIPv6) [RFC5568], and Fast Handovers for Proxy
   Mobile IPv6 (PFMIPv6) [RFC5949] improve the performance of these
   handover delays for unicast communication to the order of the maximum
   of the delays needed for link switching and signaling between Access
   Routers (ARs) or Mobile Access Gateways (MAGs) [FMIPv6-Analysis].

"to the order" means that the delay is approximately as stated (plus
noise). In this reference, the indicated delays were identified as the
leading terms in a series of delays.

> 
> 2)	P5: The specified mechanisms apply when a mobile node has joined and maintains… ==> The specified mechanisms apply when a mobile node has joined and maintained…

I don't think so: The sentence basically says that handover mechanisms
apply to active group membership ... this is "has joined and maintains"
or "continues to maintain".

On the contrary, if group membership is not maintained anymore, i.e.,
lost, no multicast handover is required.

> 
> 3)	P6: Depending on the specific network topology though, multicast traffic for some groups … ==> delete the word “though” in this sentence.

O.K.

> 
> 4)	P6: that make it undesirable to forward the multicast traffic.The PAR can… ==> that make it undesirable to forward the multicast traffic. The PAR can…

Thanks, fixed.

> 
> 5)	P7: The NAR implements an MLD proxy [RFC4605] providing host-side behaviour on behalf of the upstream PAR. ==>  Here, “on behalf of the upstream PAR” is little confusing. I suggest to modify to ” towards the upstream PAR.”

Yes, good suggestion - done.

> 
> 6)	P9: In figure 3, FBU has contained the Multicast Option, and thereby both PAR and NAR have known the related multicast information. So the question is whether it’s necessary to include Multicast Option in the HI message here?

As inherited from unicast, FBU is tunneled to PAR and NAR is not
intercepting messages. HI/HACk with MobOpts is performed to keep the
access router in sync. It may be that native multicast traffic arrives
quickly from the local join after handover, but then membership transfer
is terminated from NAR (explicitly without timeout). If native routing
is slow, the tunneling of multicast traffic will be appreciated.

Does this address your comments exhaustively?

If yes, it would be good to hear your opinion on the WG last call.

Best regards,

Thomas


> ======= 2013-02-26 07:44:10 您在来信中写道：=======
> 
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Multicast Mobility Working Group of the IETF.
>>
>> 	Title           : Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers
>> 	Author(s)       : Thomas C. Schmidt
>>                           Matthias Waehlisch
>>                           Rajeev Koodli
>>                           Godred Fairhurst
>>                           Dapeng Liu
>> 	Filename        : draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt
>> 	Pages           : 27
>> 	Date            : 2013-02-25
>>
>> Abstract:
>>    Fast handover protocols for MIPv6 and PMIPv6 define mobility
>>    management procedures that support unicast communication at reduced
>>    handover latency.  Fast handover base operations do not affect
>>    multicast communication, and hence do not accelerate handover
>>    management for native multicast listeners.  Many multicast
>>    applications like IPTV or conferencing, though, are comprised of
>>    delay-sensitive real-time traffic and will benefit from fast handover
>>    execution.  This document specifies extension of the Mobile IPv6 Fast
>>    Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6
>>    (PFMIPv6) protocols to include multicast traffic management in fast
>>    handover operations.  This multicast support is provided first at the
>>    control plane by a management of rapid context transfer between
>>    access routers, second at the data plane by an optional fast traffic
>>    forwarding that may include buffering.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-multimob-fmipv6-pfmipv6-multicast
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-01
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-fmipv6-pfmipv6-multicast-01
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> multimob mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/multimob
> 
> = = = = = = = = = = = = = = = = = = = =
> 			
> 
> 　　　　　　　　致
> 礼！
>   
> 				
> Shuai Gao
> Associate Professor
> National Engineering Lab for Next Generation Internet Interconnection Devices
> Beijing Jiaotong University
> Beijing, China, 100044
> [e-mail]
> 2013-09-25
> 
> _______________________________________________
> 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] °