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