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 protected]] Enviado el: lunes, 06 de mayo de 2013 21:22 Para: [email protected] CC: Behcet Sarikaya; LUIS MIGUEL CONTRERAS MURILLO; [email protected] Asunto: Re: [multimob] draft-ietf-multimob-handover-optimization-02.txt Hi On 5/1/2013 12:35 PM, Behcet Sarikaya wrote: > 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. > 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. > 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 protected] <mailto:[email protected]>> 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 protected] <mailto:[email protected]> > [mailto:[email protected] <mailto:[email protected]>] > Enviado el: lunes, 25 de febrero de 2013 23:11 > Para: LUIS MIGUEL CONTRERAS MURILLO > CC: [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > 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-optimiza > tion-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 protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/multimob > > > > > _______________________________________________ > multimob mailing list > [email protected] > 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 _______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
