On Wed, May 8, 2013 at 1:52 PM, LUIS MIGUEL CONTRERAS MURILLO <[email protected]>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 > 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
