Hi Behcet, The central argument of your comments orbits around the no necessity of implementing the multicast activity indication process, as a way of simplifying the protocol. Actually, the multicast activity indication does not impact on the performance of the handover optimization, neither for the proactive nor the reactive cases. The timing for getting the multicast subscription information ready at the nMAG is the same. However, the presence of the multicast activity indication makes the protocol more efficient in terms of signaling messages in the network for the reactive case when the MN is not maintaining an active subscription. We believe it is worth using the multicast activity indication as compared to querying the pMAG every time an MN moves. This could become relevant in scenarios of high mobility or in scenarios where the percentage of multicast active MNs is significantly low. However, if the WG believes this should not be mandatory, a possibility could be to implement the multicast activity indication as an option of the protocol to improve the efficiency in certain scenarios. We would like to know your opinion and the opinion of the working group about such possibility.
Regards Luis De: Behcet Sarikaya [mailto:[email protected]] Enviado el: lunes, 18 de febrero de 2013 23:19 Para: LUIS MIGUEL CONTRERAS MURILLO CC: [email protected]; [email protected]; Ignacio Soto Campos ([email protected]) Asunto: Re: [multimob] draft-ietf-multimob-handover-optimization-01 Hi Luis, Please see my replies inline. Let's resolve these issues quickly. Regards, Behcet On Mon, Feb 18, 2013 at 3:14 PM, LUIS MIGUEL CONTRERAS MURILLO <[email protected]<mailto:[email protected]>> wrote: 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]> [mailto:[email protected]<mailto:[email protected]>] En nombre de Behcet Sarikaya Enviado el: jueves, 31 de enero de 2013 0:28 Para: [email protected]<mailto:[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. Here I meant to say that A flag is not sent/received in PBU/PBA or other messages you defined. 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. If you remove the A flag and do the activity checking only right after the handover, you are simplifying the protocol and not losing much. Remember that LMA can check the aggregated multicast state and find out that some multicast sessions are active. Please see more on this below. If we agree on this then only Subscription Request/Reply remains to be resolved. Since these are not generic notification messages we can not use draft-ietf-netext-update-notifications, which is OK. So you can keep Subscription Request/Reply. 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, MLD Report is too generic. 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)". Exclude mode is only for SSM. But if you remove the A flag, you don't really need any of these things, see below. 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. Well this information is already there in LMA as the aggregated multicast state. What you want to do is to make it MN specific. You seem to assume that LMA is unicast only. The resulting protocol is too heavy. The proposed solution could work without using the flag A, but at the cost of delivering much more signaling messages than the strictly needed Why? I think that using Fig. 5, steps 1-3 in case S=1 in all cases would be good enough. By removing the A flag, your protocol will be so much simplified, my guess is you can save 10 pages from the document. So I encourage you to remove the A flag. What you are losing is so little. (all the messages for the MNs without multicast session does not need any supporting message for multicast handover optimization). Yes but this is already indicated with S=0. 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 ________________________________ 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
