Hi Behcet, Thanks for your comments, and sorry for the late response.
Please, find our answers in line Best regards, Luis De: [email protected] [mailto:[email protected]] En nombre de Behcet Sarikaya Enviado el: jueves, 31 de enero de 2013 0:28 Para: [email protected] Asunto: [multimob] draft-ietf-multimob-handover-optimization-01 Hi Carlos, authors, Some initial comments on your draft: Section 4.2 states that two new flags are defined but Flag A is not used in the line. [Luis>>] Actually section 4.2 covers the description of both flags, A and S. There is an specific section inside for any of them, being 4.2.1 devoted to flag S, and section 4.2.2 to flag A. We can improve the text explicitly mention this to help the reader. Subscription Query/Response messages: why not use the Update Notification message in draft-ietf-netext-update-notifications-00? [Luis>>] The mechanism described in draft-ietf-netext-update-notifications-00 focus on notifications triggered by the LMA. Despite the query from LMA to pMAG in the proactive handover case could be seen as one potential use case, the scope of the Subscription Query/Response messages is wider. These messages are also used by the nMAG for retrieving the multicast subscription information from the LMA in situations where the unicast binding is allowed to progress till the multicast information is ready, preventing large delays of the binding acknowledgement for unicast traffic (see section 5.2.4). In our opinion, a common mechanism should be used in both cases. Why is it necessary to define messages other than PBU/PBA from MAG to LMA, i.e. Act Ind? [Luis>>] The idea behind the new messages described in the WG draft is the use of specific and lightweight signaling methods for handling some flags in support of multicast handover optimization. For instance, the multicast activity indication represents the change in the multicast status state ( subscribed / not subscribed to any group) of one interface in the MAG. Strictly speaking, this event is not related to the purpose of PBU/PBA signaling. Regarding Figs 1 & 2, and also the Flag A, MLD Done is only in MLDv1 and has been removed from MLDv2, check Appendix B in RFC 3810. [Luis>>] That's correct, although the parts of the text where the reference to the MLD Done message appear are actually on Figure 3 and the first bullet below that figure. Our proposal is to change the text of the figure from "MLD Done" to "MLD Report" for brevity, and to change the text in the bullet from "MLD Done" to "MLD Report message (with a filter mode change record indicating EXCLUDE mode for the last subscribed multicast group)". MLD Done was mimicking IGMPv2 Leave message which is not mentioned in IPv4 support. The fact that MLD Done (or IGMP Leave) no longer available in SSM makes me question the A Flag. How could LMA sustain a valid value of the A Flag? OTOH, A Flag is only used for optimization, as shown in Figure 6. Would it be possible to not define A Flag and use S Flag? [Luis>>] Flag A helps to optimize the number of messages between PMIP entities by limiting the interrogation of the pMAG by the LMA in the case of reactive handover just to the case where the MN in the handover is maintaining an active multicast session. The proposed solution could work without using the flag A, but at the cost of delivering much more signaling messages than the strictly needed (all the messages for the MNs without multicast session does not need any supporting message for multicast handover optimization). Regards, Behcet ________________________________ 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
_______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
