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