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]>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]] *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.* > > 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 >
_______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
