Subject: [multimob] draft-ietf-multimob-handover-optimization-02.txt

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 1 May 2013 14:35:05 -0500

Hi authors,

On page 21,

The MN1 will send an
       MLD Report message (containing an State Change Record for the
       last subscribed multicast group with a filter change record mode
       indicating INCLUDE mode and an empty source list) to the MAG to
       request the cease of the multicast traffic delivery.

In RFC 3810, on Page 22,

A MODE_IS_INCLUDE Record is never sent
             with an empty source list.

The API defined in RFC 3810 does allow the stop listening operation but the
above seems not the right way.
RFC 3810 defines soft leave which is based on timers.

As I raised during Orlando meeting, this stop listening operation seems to
be integrated into the source lists, i.e. not applicable to ASM.

>From the charter point of view, this may not be a problem because the scope
specifically mentions MLDv2/IGMPv3.

I repeat my suggestion on the A flag from Feb. 25:
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.

i.e. Option 3.

Behcet

On Mon, Feb 25, 2013 at 4:16 PM, LUIS MIGUEL CONTRERAS MURILLO
<[email-masked]>wrote:

> Dear all,
>
> We have just uploaded an updated version of
> draft-ietf-multimob-handover-optimization.
>
> This new version includes some clarification text according to the last
> comments received and minor editorial improvements.
>
> All the content related to the multicast activity indication procedure
> remains as in the previous version, waiting for the discussion results and
> the decisions of the next meeting in Orlando.
>
> Thanks, best regards,
>
> Luis
>
> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]
> Enviado el: lunes, 25 de febrero de 2013 23:11
> Para: LUIS MIGUEL CONTRERAS MURILLO
> CC: [email-masked]; [email-masked]
> Asunto: New Version Notification for
> draft-ietf-multimob-handover-optimization-02.txt
>
>
> A new version of I-D, draft-ietf-multimob-handover-optimization-02.txt
> has been successfully submitted by Luis M. Contreras and posted to the
> IETF repository.
>
> Filename:        draft-ietf-multimob-handover-optimization
> Revision:        02
> Title:           PMIPv6 multicast handover optimization by the
> Subscription Information Acquisition through the LMA (SIAL)
> Creation date:   2013-02-25
> Group:           multimob
> Number of pages: 47
> URL:
> http://www.ietf.org/internet-drafts/draft-ietf-multimob-handover-optimization-02.txt
> Status:
> http://datatracker.ietf.org/doc/draft-ietf-multimob-handover-optimization
> Htmlized:
> http://tools.ietf.org/html/draft-ietf-multimob-handover-optimization-02
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-handover-optimization-02
>
> Abstract:
>    This document specifies a multicast handover optimization mechanism
>    for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic
>    to mobile nodes after handovers.  The mechanism is based on speeding
>    up the acquisition of mobile nodes' multicast context by the mobile
>    access gateways.  To do that, extensions to the current Proxy Mobile
>    IPv6 protocol are proposed.  These extensions are not only applicable
>    to the base solution for multicast support in Proxy Mobile IPv6, but
>    they can also be applied to other solutions being developed to avoid
>    the tunnel convergence problem.  Furthermore, they are also
>    independent of the role played by the mobile access gateway within
>    the multicast network (either acting as multicast listener discovery
>    proxy or multicast router).
>
>
>
>
> The IETF Secretariat
>
>
> ________________________________
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/multimob
>

---

From: Stig Venaas <[email-masked]>
Date: Mon, 06 May 2013 12:21:57 -0700

Hi

>               with an empty source list.

MODE_IS_INCLUDE is used when there is no state change. It is not used
for a State Change Record. Here the state changes, and you would send
a State Change Record with "CHANGE_TO_INCLUDE_MODE" with no sources
if previously EXCLUDE, or if INCLUDE and all sources left, then a
Source List Change Record with BLOCK_OLD_SOURCES.

FYI, this text in RFC 3810 6.1 is relevant:

    the table below.  If no per-interface state existed for that
    multicast address before the change (i.e., the change consisted of
    creating a new per-interface record), or if no state exists after the
    change (i.e., the change consisted of deleting a per-interface
    record), then the "non-existent" state is considered to have an
    INCLUDE filter mode and an empty source list.

I think the text in the draft is fine. But it does specify more detail
than needed. Maybe it could just say that an MLD Report message is sent
to the MAG to request the cease of the multicast traffic delivery.

After all, what we're talking of, is the normal MLD behavior of a host
that is no longer interested. I don't see the need to go into further
detail.

Stig

> The API defined in RFC 3810 does allow the stop listening operation but
> the above seems not the right way.
> As I raised during Orlando meeting, this stop listening operation seems
> to be integrated into the source lists, i.e. not applicable to ASM.
>
>  From the charter point of view, this may not be a problem because the
> scope specifically mentions MLDv2/IGMPv3.
>
> 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.
>
> i.e. Option 3.
>
> Behcet
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Dear all,
>
>     This new version includes some clarification text according to the
>     last comments received and minor editorial improvements.
>
>     All the content related to the multicast activity indication
>     procedure remains as in the previous version, waiting for the
>     discussion results and the decisions of the next meeting in Orlando.
>
>     Thanks, best regards,
>
>     Luis
>
>     De: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     CC: [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     has been successfully submitted by Luis M. Contreras and posted to
>     the IETF repository.
>
>     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:
>     [email-masked] <mailto:[email-masked]>

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 08 May 2013 18:52:46 +0000

Hi Stig,

Indeed that's the point. We are just trying to describe the fact that a host explicitly unsubscribes from receiving a certain content. Of course we can simplify the text to avoid confusion.

Regarding next steps for this draft, we would like to request guidance to the chairs on how to progress this draft. According to the feedback received, it seems that the preferred option is to simplify WG draft by removing the content related to the flag A mechanism from the text. Then the draft would be focused on the signaling mechanism for transferring multicast context. Any further optimization (and the associated signaling) should be documented separately. Do you have any objection in following this way? If it is OK we will try to have a new version ready ASAP.

Best regards,

Luis

-----Mensaje original-----
De: Stig Venaas [mailto:[email-masked]]
Enviado el: lunes, 06 de mayo de 2013 21:22
Para: [email-masked]
CC: Behcet Sarikaya; LUIS MIGUEL CONTRERAS MURILLO; [email-masked]
Asunto: Re: [multimob] draft-ietf-multimob-handover-optimization-02.txt

Hi

>               with an empty source list.

MODE_IS_INCLUDE is used when there is no state change. It is not used for a State Change Record. Here the state changes, and you would send a State Change Record with "CHANGE_TO_INCLUDE_MODE" with no sources if previously EXCLUDE, or if INCLUDE and all sources left, then a Source List Change Record with BLOCK_OLD_SOURCES.

I think the text in the draft is fine. But it does specify more detail than needed. Maybe it could just say that an MLD Report message is sent to the MAG to request the cease of the multicast traffic delivery.

After all, what we're talking of, is the normal MLD behavior of a host that is no longer interested. I don't see the need to go into further detail.

Stig

> The API defined in RFC 3810 does allow the stop listening operation
> but the above seems not the right way.
> As I raised during Orlando meeting, this stop listening operation
> seems to be integrated into the source lists, i.e. not applicable to ASM.
>
> 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.
>
> i.e. Option 3.
>
> 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: Stig Venaas <[email-masked]>
Date: Wed, 08 May 2013 12:11:08 -0700

> Regarding next steps for this draft, we would like to request guidance to the chairs on how to progress this draft. According to the feedback received, it seems that the preferred option is to simp…

I think so. I was the one raising this issue though. We got responses
from a few people. It is hard to know what those that remained silent
think about this issue. I wish we had more responses, but none argued
for keeping the flag. Let's see what my co-chair thinks too.

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 13 May 2013 13:34:22 -0500

On Wed, May 8, 2013 at 1:52 PM, LUIS MIGUEL CONTRERAS MURILLO
<[email-masked]>wrote:

> Hi Stig,
>
> Indeed that's the point. We are just trying to describe the fact that a
> host explicitly unsubscribes from receiving a certain content. Of course we
> can simplify the text to avoid confusion.
>
> Regarding next steps for this draft, we would like to request guidance to
> the chairs on how to progress this draft. According to the feedback
> received, it seems that the preferred option is to simplify WG draft by
> removing the content related to the flag A mechanism from the text. Then
> the draft would be focused on the signaling mechanism for transferring
> multicast context. Any further optimization (and the associated signaling)
> should be documented separately. Do you have any objection in following
> this way? If it is OK we will try to have a new version ready ASAP.
>
>
This sounds good.

Regards,

Behcet

> MODE_IS_INCLUDE is used when there is no state change. It is not used for
> a State Change Record. Here the state changes, and you would send a State
> Change Record with "CHANGE_TO_INCLUDE_MODE" with no sources if previously
> EXCLUDE, or if INCLUDE and all sources left, then a Source List Change
> Record with BLOCK_OLD_SOURCES.
>
> than needed. Maybe it could just say that an MLD Report message is sent to
> the MAG to request the cease of the multicast traffic delivery.
>
> >     A new version of I-D,