Subject: [multimob] Review of draft-ietf-multimob-handover-optimization-01

From: Stig Venaas <[email-masked]>
Date: Thu, 07 Feb 2013 15:44:32 -0800

Hi, please find below my comments on this draft.

Stig

In the draft it says

    receiving the corresponding MLD Report message.  This delay is caused
    by the time needed for the detection of the attachment in the new
    link and the re-establishment of the data plane after the handover,
    the radio transfer delays associated with the signaling to the mobile
    node, and the MLD query response interval time required by this
    procedure (whose default value is 10 seconds as defined in [RFC2710],
    or between 5 and 10 seconds as considered in the best case wireless
    link scenario in [RFC6636]).

Assuming there is a point-to-point link MAG-MN, can't this be set to a
minimal value, maybe even 0?

What happens if the subscription state doesn't fit in a single PBU/PBA?
Can multiple messages be sent?

In 4.3.1.2.2.  Message format
Do you need the I flag? Can't the receiver just check all the options
to see if there are any Active Multicast Subscription options?

Is it really worth having the optimization with the A flag if new
message types are required? May it be possible to make use of the PBU
message instead?

Note that there may be less signaling by needlessly querying the pMAG
on handover, instead of signaling the LMA each time a MN starts joining
or leaving multicast groups.

Do you need to allow Home Network Prefix in various messages? Don't
you just need the MNI option? E.g. in the MAI/MAIA messages.

In 5.1.2 figure 3. You need to write something other than MLD Done to
take care of MLDv2 that only has reports. I know what you are trying
to say though.

There should be some limit for how long the LMA keeps the information
in the proactive case, or rather, if there is not a new nMAG within
a reasonable time.

It should be made clear that the nMAG should still ASAP send MLD
a query to check the hosts subscription state. Maybe it is already
stated somewhere?

In section 7 about co-existence. I think the MAG should only tell
the LMA about the subscription information for the (S,G)s or Gs
where it decided to send IGMP reports/joins on the LMA tunnel.

A few Minor issues below.

Comments for section 1.  Introduction

    The base solution describing how continuous multicast service
    delivery can be provided in Proxy Mobile IPv6 domains is described in
    RFC 6224 [RFC6224].  This solution specifies the basic functionality
                        ^^^^^^

It's a bit unclear whether "This" refers to 6224 or this document.
Suggest writing "the base solution specifies", or maybe just "it
specifies".

    mobile node), there is no a generic standard solution for the
                             ^^^
remove "a".

    IGMP/MLD protocols.  Both protocols send multicast membership
    interrogation messages when a new link is up.  The response to such a
    ^^^^^^^^^^^^^

"query". Consider using "query" instead of "interrogation" other places too.

   o  The solution should not impact on existing multicast protocols.
                             ^^^^^^^^^^^
just "impact" or "have impact on".

   Present specification addresses all these requirements, as described
    in the following sections.

Start with "The present" I think.

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 18 Feb 2013 21:14:05 +0000

Hi Behcet,

Thanks for your comments, and sorry for the late response.

Please, find our answers in line

Best regards,

Luis

De: [email-masked] [mailto:[email-masked]] En nombre de Behcet Sarikaya
Enviado el: jueves, 31 de enero de 2013 0:28
Para: [email-masked]
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

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 18 Feb 2013 21:30:38 +0000

Hi Stig,

Thanks for your deep review, and excuse us for the delay in answering it.

Please, see our comments in-line.

Best regards,

Luis

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Stig Venaas
Enviado el: viernes, 08 de febrero de 2013 0:45
Para: [email-masked]
Asunto: [multimob] Review of draft-ietf-multimob-handover-optimization-01

Stig

In the draft it says

Assuming there is a point-to-point link MAG-MN, can't this be set to a minimal value, maybe even 0?

[Luis>>] Potentially yes. Even in that case, the expected performance obtained by using this optimization is better than the one experienced with the base solution, as described in Appendix A. However, it could be an option just in case the router where the MAG resides is used only for PMIPv6 mobile customers (i.e., it is not mutualized for both mobile and fixed users in fixed/mobile convergent scenarios, or the router also simultaneously provides other mobile services different from PMIPv6, in which the point-to-point link model is not followed/required), or in case the MLD configuration can be individually applied per interface (thus, per PMIPv6 MAG-to-MN point-to-point interface). Looking at existing state-of-the-art MAGs, this is not possible. For instance, the Cisco 8500 Wireless LAN Controller dos not allow a configuration of the query interval below 15 seconds, and the MLD configuration affects to the whole device. So, in practice, the potential configuration of the query interval to 0 sec. seems to be far from common.

[Luis>>] The solution encapsulates each individual multicast membership context in an independent TLV active multicast subscription mobility option, allowing to transmit a large subscription state in multiple messages if needed. The mechanism for doing that would not be different to whatever mechanism defined in PMIPv6 for any other option or set of options in case a single PBU/PBA message could not transfer all the required content in a single message.

In 4.3.1.2.2.  Message format
Do you need the I flag? Can't the receiver just check all the options to see if there are any Active Multicast Subscription options?

[Luis>>] The point is that in case the receiver just check the options and the Subscription Response message does not include any multicast subscription information, the receiver cannot clearly determine if there is not actually any on-going multicast subscription or if there is an error in the message. The flag I assists the receiver in correctly processing the message. In case there is no any on-going multicast subscription (with I=0) the receiver can avoid the processing of the rest of the message; otherwise (with I=1) the receiver realizes there was an error and can trigger some further action to solve it (e.g., raise an alarm).

Is it really worth having the optimization with the A flag if new message types are required? May it be possible to make use of the PBU message instead?

[Luis>>]  Despite the extension of PBU messages could have been a design option, in our opinion the use of specific purpose messages represents a more lightweight method for signaling this issue. The
PBU/PBA sequence is tightly related to location registration events while the multicast activity indication reflects a change in the (multicast status) state of the point-to-point link at the MAG. The use of PBU/PBA sequence to signal that seems artificial.

Note that there may be less signaling by needlessly querying the pMAG on handover, instead of signaling the LMA each time a MN starts joining or leaving multicast groups.

[Luis>>] The signaling of the multicast activity between MAG and LMA is proposed not per multicast group request from the MN, but for the duration of the multicast activity by the MN, in other words, the time while the MAG maintains a multicast status for the MN on the point-to-point links. The activity is signaled ON once the MN request a subscription to a multicast group, and it is signaled OFF when no more channels are requested (i.e., the last subscribed channel is left). In the meantime the MN can leave or join different multicast groups, but no signaling is triggered because the activity is maintained. So, it can be seen as a couple of messages for the duration of the multicast session. We can assume that the MN customer base simultaneously in active multicast mode is lower than the general MN customer base.

Do you need to allow Home Network Prefix in various messages? Don't you just need the MNI option? E.g. in the MAI/MAIA messages.

[Luis>>] The rationale for including the HNPs is for facilitating the management of the multicast subscription when the MN has different HNPs while attached to different networks (e.g., Internet and Intranet). There could be different criteria per network in terms of which content can be subscribed to or not (e.g., certain multicast groups could not be allowed to be received by the Intranet). Under these circumstances, there could be a handover process for one of that networks, but not for the other. In that case it is needed to track exactly what point of attachment is changing, to trigger or not the multicast handover optimization process (if there is no active subscription on that interface, then there is no need to apply any optimization).

In 5.1.2 figure 3. You need to write something other than MLD Done to take care of MLDv2 that only has reports. I know what you are trying to say though.

[Luis>>] Right. We propose to change it in Figure 3 by MLD Report, and in the text just below by "MLD Report message (with a filter mode change record indicating EXCLUDE mode for the last subscribed multicast group)".

There should be some limit for how long the LMA keeps the information in the proactive case, or rather, if there is not a new nMAG within a reasonable time.

[Luis>>] Since the information is kept in the binding cache, what we are proposing in 5.2.1.1 is that the multicast information is removed together with the rest of the binding database for the MN according to standard PMIPv6 procedures.

It should be made clear that the nMAG should still ASAP send MLD a query to check the hosts subscription state. Maybe it is already stated somewhere?

[Luis>>] This proposal is an optimization of the base solution but does not substitute the processes standardized in RFC6224. Then the proposal does not prevent the delivery of the MLD query once the MN attaches a nMAG, which is intrinsically part of the above RFC. We can include some text referring this.

In section 7 about co-existence. I think the MAG should only tell the LMA about the subscription information for the (S,G)s or Gs where it decided to send IGMP reports/joins on the LMA tunnel.

[Luis>>] From our point of view, it is required in any case in the proactive case, since the handover optimization applies either if the MAG gets the multicast group from the LMA (remote subscription) of from the local multicast router (local subscription). The multicast context, kept in the binding cache, is a parameter of the communication service not bound to the way the multicast is served.

[Luis>>] Noted. We will upgrade next draft version accordingly.

It's a bit unclear whether "This" refers to 6224 or this document.
Suggest writing "the base solution specifies", or maybe just "it specifies".

   o  The solution should not impact on existing multicast protocols.
                             ^^^^^^^^^^^ just "impact" or "have impact on".

Start with "The present" I think.
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 18 Feb 2013 16:19:16 -0600

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-masked]>wrote:

> *De:* [email-masked] [mailto:[email-masked]] *En
> nombre de *Behcet Sarikaya
> *Enviado el:* jueves, 31 de enero de 2013 0:28
> *Para:* [email-masked]
> *Asunto:* [multimob] draft-ietf-multimob-handover-optimization-01
>
>
>
> Hi Carlos, authors,
>
> *[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.*
>
> *[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.

> 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?
> *[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:

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Fri, 22 Feb 2013 09:32:12 +0000

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-masked]]
Enviado el: lunes, 18 de febrero de 2013 23:19
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: [email-masked]; [email-masked]; Ignacio Soto Campos ([email-masked])
Asunto: Re: [multimob] draft-ietf-multimob-handover-optimization-01

Hi Luis,

Regards,

Behcet
On Mon, Feb 18, 2013 at 3:14 PM, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>> wrote:
Hi Behcet,

Best regards,

Luis

De: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] En nombre de Behcet Sarikaya
Enviado el: jueves, 31 de enero de 2013 0:28
Para: [email-masked]<mailto:[email-masked]>
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.

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.

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).

Regards,

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Mon, 25 Feb 2013 10:08:10 -0800

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-masked]]
> *Enviado el:* lunes, 18 de febrero de 2013 23:19
> *Para:* LUIS MIGUEL CONTRERAS MURILLO
> *CC:* [email-masked]; [email-masked]; Ignacio Soto Campos
> ([email-masked])
> *Asunto:* Re: [multimob] draft-ietf-multimob-handover-optimization-01
>
> Hi Luis,
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Hi Behcet,
>
> *De:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked] <mailto:[email-masked]>]
> *En nombre de *Behcet Sarikaya
> *Para:* [email-masked] <mailto:[email-masked]>
> */[Luis>>] Actually section 4.2 covers the description of both flags, A
> 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./*
>
>     */[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.
>     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)”./*
>
>     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?
>     */[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?
> By removing the A flag, your protocol will be so much simplified, my
> guess is you can save 10 pages from the document.
>     */(all the messages for the MNs without multicast session does not
>     need any supporting message for multicast handover optimization)./*
>
>     ------------------------------------------------------------------------
>
>
>     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:
> ------------------------------------------------------------------------
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 25 Feb 2013 13:02:48 -0600

> I think it might be worth making it optional, but I have no strong
 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-masked]**]
>> *Asunto:* Re: [multimob] draft-ietf-multimob-handover-**optimization-01
>>
>>
>> Hi Luis,
>>
>> *De:[email-masked] <mailto:multimob-bounces@ietf.**org<[email-masked]>
>> >
>> [mailto:multimob-bounces@ietf.**org <[email-masked]> <mailto:
>> multimob-bounces@ietf.**org <[email-masked]>>]
>> *Asunto:* [multimob] draft-ietf-multimob-handover-**optimization-01
>>
>>
>> Hi Carlos, authors,
>>
>>     Notification message in draft-ietf-netext-update-**notifications-00?
>>
>>     draft-ietf-netext-update-**notifications-00 focus on notifications
>> draft-ietf-netext-update-**notifications, which is OK.
>>     ------------------------------**------------------------------**
>> ------------
>>
>>
>>
>>     http://www.tid.es/ES/PAGINAS/**disclaimer.aspx<http://www.tid.es/ES/PAGINAS/disclaimer.aspx>
>>
>>
>> ------------------------------**------------------------------**
>> ------------
>>
>>
>> http://www.tid.es/ES/PAGINAS/**disclaimer.aspx<http://www.tid.es/ES/PAGINAS/disclaimer.aspx>
>>
>>
>> ______________________________**_________________
>> multimob mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob>
>>
>>
>