On 5/8/2013 11:52 AM, LUIS MIGUEL CONTRERAS MURILLO 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.
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
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
