Re: [multimob] Volunteers to review draft-ietf-multimob-fast-handover-01

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi Akbar,

I'm very sorry for our late response. Thank you very much for your in-deep review and valuable comments. We have included the majority of them. Please, see in line specific answers to your comments/suggestions

Thanks again,

Luis


De: [e-mail] [mailto:[e-mail]] En nombre de Rahman, Akbar
Enviado el: miércoles, 26 de septiembre de 2012 22:20
Para: [e-mail]; [e-mail]
Asunto: Re: [multimob] Volunteers to review draft-ietf-multimob-fast-handover-01


Hi,





As per my action, I have reviewed draft-ietf-multimob-fast-handover-01 and have the following feedback to the authors:





1.  In general, the I-D is well written and in pretty good technical shape.  However, I had the following comments that I suggest be incorporated into an update before the WGLC.



Detailed Comments:

2.  Section 1 (Introduction)

o    I find the last paragraph in this section ("The solution described in this document ...") to be ambiguous and hard to "prove".  How can you really demonstrate that the approach can be applied to "possible architectural evolutions"?  I would suggest removing this type of claim unless you can be more specific.

[Luis>>] This paragraph was written having in mind the architectural evolutions described in [I-D.ietf-multimob-pmipv6-ropt]. As this proposal is an add-on to the set of PMIPv6 protocols, and there is no compatibility issues identified with the solutions in [I-D.ietf-multimob-pmipv6-ropt], we think that this statement remains valid at least for the mentioned architectural evolutions. According to your suggestion we propose to modify the text in the following way: "The solution described in this document can be also applied to the solutions described in [I-D.ietf-multimob-pmipv6-ropt]".

o    The above comment also applies to the similar statement in the abstract, and section 6.

[Luis>>] Similar change applies to section 6. For the abstract we modify the text in the following way: "These extensions are not only applicable to the base solution for multicast support in

Proxy Mobile IPv6, but they can also be applied to other solutions being developed to avoid the tunnel convergence problem."

o    In paragraph 3, should it be "active multicast content delivery" instead of "active multicast subscription"?

[Luis>>] The sentence "active multicast subscription" appears twice in the paragraph, but our understanding is that in both cases it is the most appropriate concept. By now we have not changed it, but, please provide additional comments on this if you feel it is necessary to change that.

o    In paragraph 4, I was not really sure if the base [RFC5949] can perform the mechanism or not?  (I.E. Does it necessarily require modifications to [RFC5949] to perform the mechanism?)

[Luis>>] We propose to change the wording, by using "could potentially be accomplished by using some adaptation of [RFC5949] to multicast traffic" instead of "can be accomplished by using [RFC5949] or some evolution of it "



3.  Section 2 (Terminology)

o    The description of "Proactive handover" is confusing ("... the MN de-registration from the pMAG previously to receive the MN registration from the nMAG").

[Luis>>] As per your comment, we propose the following definition: "A proactive handover is a handover event where the MN is firstly de-registered on the LMA by the pMAG, and later on it is registered by the nMAG as consequence of changing the point of attachment."



4.  Section 3 (Overview)

o    It would help a lot for readability (and understandability) to have a high level architecture picture in this section.  Something along the lines of Figure 1 of RFC 6224 would be an obvious starting point.

[Luis>>] Done. We have included a high level figure showing the main idea of the solution.

o    The 2nd paragraph stresses that subscription info for an MN to the LMA is only updated after a handover event.  This may be true, but later sections (e.g. Fig. 1) do specify other new info being exchanged without a handover event.  So this should also be mentioned for balance.

[Luis>>] Agree. According to your suggestion we propose to include the following text: "However it should be noted that some signaling is needed to differentiate what MNs are maintaining active subscriptions in order to restrict the optimization procedure to them in case of handover."



5.  Section 4.2.1.1.2 (De-registration process)

o    In the S=1 description, it refers to the "IP addresses of the subscribed group and the source providing it".  I interpret the "source" to be referring to the Source-Specific Multicast (SSM) of [RFC4604].  But I understand that an MN can also do a non SSM Join (i.e. indicate only the subscribed group IP address and no source).  Is this supported in the draft?  (This comment applies to many places in the document).

[Luis>>] Certainly, it seems more appropriate to refer to the "multicast context" or "multicast status information" rather than "IP addresses of the subscribed group and the source providing it". This last sentence is out-of-date once we have introduced in version -01 the new format for the Active Multicast Subscription mobility option (in section 4.1.1.2) including the Multicast Address record inherited from RFC3810, as suggested by Hitoshi Asaeda in a previous review of the document. So, I agree we have to re-write these kind of sentences in the sense I mention at the beginning. We have updated the document accordingly.



6.  Section 5.1.1 (Multicast Activity set to ON)

o    In Figure 1 and the corresponding text it indicates that the "Act Ind(start)" for the particular MN is sent by the MAG to the LMA as soon as the MLD Report is sent.  I understand that this message will be sent for each similar MN that attaches to the MAG (along with a corresponding ACK).  What are the signaling load implications for this between the MAG and the LMA?

[Luis>>] This signaling message is used to allow the LMA to distinguish among MNs with on-going multicast subscription, and MN without active multicast status. This differentiation further allows to apply the optimization procedure only to those MNs with active multicast subscription (no actions are taken for MN without active multicast subscription). The signaling load of the multicast activity represents one message (and the corresponding ack) once the MN firstly subscribes to a multicast group, and another message (and the corresponding ack) when the MN terminates the multicast subscription at all. So, it can be seen as two pair of messages for the duration of the multicast session. This mechanism is intended to avoid the unnecessary application of this optimization procedure for MNs not having an active multicast subscription during a handover event, then preventing the LMA and the MAGs to implement unnecessary actions in case of no active multicast session during handover. In order to clarify this we have included the motivation of this signaling in the document in section 5.1.

o    (My understanding is that in Fig. 1 the flag "A=1" is sent in a PBU which normally would not have been sent at this point for unicast.  Please correct me if I am wrong).

[Luis>>] Not actually. We define specific purpose messages for this in sections 4.3.2.1 and 4.3.2.2. Using the regular PBU/BPA signaling exchange could have been adopted instead, but in our opinion the use of specific purpose messages represents a more lightweight method for signaling this issue.



7.  Section 7 (Benefits of layer-2 triggers for fast handover)

o    It was unclear what the main point of this section is (i.e. what is the standards text)?  I especially found the last sentence confusing ("... and that not all the multicast applications could take benefit of it, that functionality could be seen as optional for multicast handover optimization.")

[Luis>>] We agree on removing this section.



8.  Section 8 (Security Considerations)

o    You obviously need to complete this section before WGLC.

[Luis>>] Agree. We have completed this section.



9.  Section 10 (Contributors)

o    Somehow the phrase ".. has largely contributed.." does not read well (perhaps just change "largely" to "extensively").

[Luis>>] Done.



10.General: I recall that the authors mentioned that they would do some simulations to prove the benefit of this approach vs the baseline [RFC6224] approach.  I think that will be very useful so that the WG can trade the complexity vs. performance benefits of this approach.  I did in general find the complexity of even understanding all the different options (reactive vs. proactive, Flag setting, prevention of unicast traffic delays, etc.) to be a bit daunting.  I had to go back to your PPT presentations from the IETF meetings to piece everything together (as those slides nicely captured the high level flow).  If we had the simulations then we could justify all the complexity.  Or even better perhaps support fewer options that give the majority of the benefits?  This to me is a key open issue.

[Luis>>] For the sake of simplicity we have included a performance comparison analysis between this proposal and the base protocol focusing on the delay reduction that this method achieves.





That's all.





/Akbar



-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Behcet Sarikaya
Sent: Tuesday, September 25, 2012 4:38 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [multimob] Volunteers to review draft-ietf-multimob-fast-handover-01



Hi all,



In IETF84, three people volunteered to review

draft-ietf-multimob-fast-handover-01,



Thomas, Akbar and Costas.



The volunteers, thanks for volunteering and please post your reviews

on the list soon.



Regards,



Behcet

_______________________________________________

multimob mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/multimob


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx