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 >> [email protected] >> 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 > [email protected] > 2013-09-25 > > _______________________________________________ > multimob mailing list > [email protected] > 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: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° _______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
