On Mon, Feb 25, 2013 at 12:08 PM, Stig Venaas <[email protected]> wrote:
> On 2/22/2013 1:32 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: > >> 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. >> > > Hi. This sounds like a great topic to discuss in the meeting. It would > be good if you spend some time on this in your presentation and we can > try to get people's opinion. > > I think it might be worth making it optional, but I have no strong > opinions on this. > > multicast activity indication signaling for individual MN's between MAG and LMA is the issue here. As I suggested, this should be taken out of this draft first. We can discuss if it there is a feasible solution? MLD Done is for ASM and it is a SHOULD in RFC 2710. What to do for SSM? Why do we need this additional signaling? Is there a strong justification? If a feasible solution emerges and WG believes that there is a need then a separate draft can be written and individual Handover drafts can use it. Behcet > Stig > > >> 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:multimob-bounces@ietf.**org<[email protected]> >> > >> [mailto:multimob-bounces@ietf.**org <[email protected]> <mailto: >> multimob-bounces@ietf.**org <[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<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<http://www.tid.es/ES/PAGINAS/disclaimer.aspx> >> >> >> ______________________________**_________________ >> multimob mailing list >> [email protected] >> https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob> >> >> >
_______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
