Subject: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 8 Feb 2010 13:23:20 -0800 (PST)

This mail starts a WG adoption call on this draft.

The intended status for this document is BCP.
If adopted, the draft will be named:

draft-ietf-multimob-pmipv6-base-solution.

Please respond if you are for ADOPTING or

you are NOT for ADOPTING it by February 21, 2010.

Regards,

Behcet

----- Forwarded Message ----
> From: Thomas C. Schmidt <[email-masked]>
> To: [email-masked]
> Sent: Mon, February 8, 2010 3:02:03 PM
> Subject: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-04]
> 
> Hi,
> 
> we have submitted a revised version of the PMIPv6 deployment draft.
> This version includes all contributions from the extensive and fruitful 
> discussions since the last update in December.
> 
> From the Change Log
> 
>   The following changes have been made from
>   draft-schmidt-multimob-pmipv6-mcast-deployment-03.
> 
>   1.  Detailed outline of multicast reconfiguration steps on handovers
>       added in protocol overview (section 3).
> 
>   2.  Clarified the details of proxy operations at the MAG along with
>       the expected features of IGMP/MLD Proxy implementations (section
>       4.2).
> 
>   3.  Clarified querying in dual-stack scenarios (section 4.4).
> 
>   4.  Subsection added on the special case, where multicast is
>       available throughout the access network (section 4.5).
> 
>   5.  Appendix on IGMP/MLD behaviour added with test reports on current
>       Proxy implementations.
> 
> 
> We now believe the approach has been thoroughly discussed and the document is 
> mature enough to be considered as a WG item.
> 
> Best wishes,
> 
> Thomas
> 
> -------- Original Message --------
> Subject: New Version Notification for 
> draft-schmidt-multimob-pmipv6-mcast-deployment-04
> Date: Mon,  8 Feb 2010 12:53:11 -0800 (PST)
> From: IETF I-D Submission Tool 
> To: [email-masked]
> CC: 
> [email-masked],[email-masked],[email-masked]
> 
> 
> A new version of I-D, draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has 
> been successfuly submitted by Thomas Schmidt and posted to the IETF repository.
> 
> Filename:    draft-schmidt-multimob-pmipv6-mcast-deployment
> Revision:    04
> Title:        A Minimal Deployment Option for Multicast Listeners in PMIPv6 
> Domains
> Creation_date:    2010-02-08
> WG ID:        Independent Submission
> Number_of_pages: 19
> 
> Abstract:
> This document describes deployment options for activating multicast
> listener functions in Proxy Mobile IPv6 domains without modifying
> mobility and multicast protocol standards.  Similar to Home Agents in
> Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast
> subscription anchor points, while Mobile Access Gateways provide MLD
> proxy functions.  In this scenario, Mobile Nodes remain agnostic of
> multicast mobility operations.
> 
> 
> 
> 
> The IETF Secretariat.
> 
> 
> 
> -- 
> Prof. Dr. Thomas C. Schmidt
> ° Hamburg University of Applied Sciences                  Berliner Tor 7 °
> ° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
> ° http://www.haw-hamburg.de/inet                  Fon: +49-40-42875-8452 °
> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

---

From: "Romdhani, Imed" <[email-masked]>
Date: Tue, 9 Feb 2010 17:32:40 +0000

Dear all,

I am for ADOPTING this solution.

Regards,
Imed

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: 08 February 2010 21:23
To: [email-masked]
Subject: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04

Regards,

Behcet

----- Forwarded Message ----

On 25 February 2009, the University launched its new name, Edinburgh Napier University.  

For more information please visit our website.

Edinburgh Napier University is one of the top 10 universities in the UK for graduate employability (HESA 2009)

This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else out-with the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.

Edinburgh Napier University is a registered Scottish charity. Registration number SC018373

---

From: "Seil Jeon" <[email-masked]>
Date: Wed, 10 Feb 2010 11:59:12 +0900

Dear all,

I think that this draft is in accordance with this charter among tunneling mode approach.

I am for ADOPTING this draft.

Best Regards,

Seil Jeon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Tuesday, February 09, 2010 6:23 AM
To: [email-masked]
Subject: [multimob] WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04

Regards,

Behcet

----- Forwarded Message ----
> Subject: [multimob] [Fwd: New Version Notification for 
> draft-schmidt-multimob-pmipv6-mcast-deployment-04]
> 
> Hi,
> 
> This version includes all contributions from the extensive and 
> fruitful discussions since the last update in December.
> 
> From the Change Log
> 
> We now believe the approach has been thoroughly discussed and the 
> document is mature enough to be considered as a WG item.
> 
> Best wishes,
> 
> Thomas
> 
> A new version of I-D, 
> draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has been successfuly submitted by Thomas Schmidt and posted to the IETF repository.
> 
> Title:        A Minimal Deployment Option for Multicast Listeners in 
> PMIPv6 Domains
> ° Hamburg University of Applied Sciences                  Berliner Tor 
> 7 ° ° Dept. Informatik, Internet Technologies Group    20099 Hamburg, 
> Germany ° ° http://www.haw-hamburg.de/inet                  Fon: 
> +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt    
> Fax: +49-40-42875-8409 °

---

From: <[email-masked]>
Date: Wed, 17 Feb 2010 13:16:08 +0100

Dear all,
Following the latest discussions on basic solutions for PMIP-multimob I am convinced that this draft will serve as a good basis for the further WG discussion, so I am in favour of adopting the document.

I also think the more detailed exlanations and Appendix on implementations is quite useful. 

Best regards
Dirk

PS: The only very minor nit I found was in Appendix B: 'encapsulated' instead of 'entcapsulated' ;-)

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Behcet Sarikaya
Gesendet: Montag, 8. Februar 2010 22:23
An: [email-masked]
Betreff: [multimob] WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04

Regards,

Behcet

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 18 Feb 2010 17:09:32 -0500

Behcet, Stig,

I'd like to understand if you believe the group has reached agreement that it is worth looking at optimizations on top of the base solution.

It has been discussed in the list that there are scenarios where the solution detailed in draft-schmidt could have limitations, for instance when different MNs using different LMAs join the same group. In such a case we can save bandwidth by having a dedicated multicast LMA. Also, another advantage of a dedicated LMA is to avoid the need for all LMAs to have multicast capability and connectivity.

I believe that draft-schmidt is a very good document and if it addresses the open comments sent on the list it can become the base solution. However, I also believe that we have enough interest in the group to pursue further enhancements on top of this base solution.

Please let me know your views.

Regards,

Juan Carlos

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Wednesday, 17 February, 2010 7:16 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [multimob] WG Adoption callondraft-schmidt-multimob-
> pmipv6-mcast-deployment-04
> 
> Dear all,
> Following the latest discussions on basic solutions for PMIP-multimob I
> am convinced that this draft will serve as a good basis for the further
> WG discussion, so I am in favour of adopting the document.
> 
> fruitful
> document is
> PMIPv6

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Feb 2010 16:45:40 -0800 (PST)

Hi Carlos,
  This current adoption call is aimed at establishing if there is consensus that this draft is the base solution. You are saying it is. 

  Let's discuss other issues next week.

Regards

----- Original Message ----
> From: "Zuniga, Juan Carlos" <[email-masked]>
> To: Stig Venaas <[email-masked]>; [email-masked]; [email-masked]
> Sent: Thu, February 18, 2010 4:09:32 PM
> Subject: RE: [multimob] WG Adoption callondraft-schmidt-multimob-pmipv6-mcast-deployment-04
> 
> Behcet, Stig,

I'd like to understand if you believe the group has reached 
> agreement that it is worth looking at optimizations on top of the base 
> solution.

It has been discussed in the list that there are scenarios 
> where the solution detailed in draft-schmidt could have limitations, for 
> instance when different MNs using different LMAs join the same group. In such a 
> case we can save bandwidth by having a dedicated multicast LMA. Also, another 
> advantage of a dedicated LMA is to avoid the need for all LMAs to have multicast 
> capability and connectivity.

I believe that draft-schmidt is a very good 
> document and if it addresses the open comments sent on the list it can become 
> the base solution. However, I also believe that we have enough interest in the 
> group to pursue further enhancements on top of this base solution.

Please 
> let me know your views.

Regards,

Juan Carlos

---

From: "Luis M. Contreras" <[email-masked]>
Date: Fri, 19 Feb 2010 09:58:05 +0100

Hi all,

I vote for ADOPTING this draft as the base document for a basic solution.

However I have some further comments on it because I think some points 
need some clarification. I will send them to the list after adoption 
process deadline.

Regards,

Luis

Behcet Sarikaya <[email-masked]> dijo:

>> draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Luis M. Contreras
Profesor Asociado
Dpto. de Ingeniería Telemática
Universidad Carlos III de Madrid
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 22 Feb 2010 07:23:51 -0800 (PST)

Hi all,
  The call has ended and consensus has been established.

Authors, please submit your draft as draft-ietf-multimob-pmipv6-base-solution-00.txt.

Regards,

Chairs

----- Original Message ----
> From: Behcet Sarikaya <[email-masked]>
> To: [email-masked]
> Sent: Mon, February 8, 2010 3:23:20 PM

The intended status 
> for this document is BCP.
If adopted, the draft will be 
> named:

Please respond if 
> you are for ADOPTING or

you are NOT for ADOPTING it by February 21, 
> 2010.

Regards,

Behcet

----- Forwarded Message 
> ----
> From: Thomas C. Schmidt <> ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]>
> 
> To: > href="mailto:[email-masked]">[email-masked]
> Sent: Mon, 
> Subject: [multimob] [Fwd: New Version 
> Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-04]
> 
> 
> Hi,
> 
>   1.  
> Detailed outline of multicast reconfiguration steps on handovers
>       
>   2.  Clarified the 
> details of proxy operations at the MAG along with
>       the expected 
> features of IGMP/MLD Proxy implementations (section
>       4.2).
> 
> 
> We now believe the approach 
> has been thoroughly discussed and the document is 
> mature enough to be 
> considered as a WG item.
> 
> Best wishes,
> 
> 
> Thomas
> 
> To: > ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]
> 
> CC: 
> > href="mailto:[email-masked]">[email-masked],> ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked],> ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]
> 
> 
> 
> A new version of I-D, 
> been 
> successfuly submitted by Thomas Schmidt and posted to the IETF 
> repository.
> 
> Filename:    
> draft-schmidt-multimob-pmipv6-mcast-deployment
> Revision:    04
> 
> ° Dept. Informatik, Internet 
> Technologies Group    20099 Hamburg, Germany °
> ° 
> http://www.haw-hamburg.de/inet                  Fon: +49-40-42875-8452 °
> 
> multimob 
> mailing list
> > href="mailto:[email-masked]">[email-masked]
> > href="https://www.ietf.org/mailman/listinfo/multimob" target=_blank 

multimob mailing 
> list
> href="mailto:[email-masked]">[email-masked]
> href="https://www.ietf.org/mailman/listinfo/multimob" target=_blank

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Mon, 22 Feb 2010 11:28:46 -0500

Hi Behcet,

It is now "next week". 

While the base solution is cleaned up, I guess we are ready to discuss about protocol enhancements.

Do you agree?

Juan Carlos

> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: Thursday, 18 February, 2010 7:46 PM
> To: Zuniga, Juan Carlos; [email-masked]
> Subject: Re: [multimob] WG Adoption call on draft-schmidt-multimob-
>   This current adoption call is aimed at establishing if there is
> consensus that this draft is the base solution. You are saying it is.
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 22 Feb 2010 08:43:37 -0800 (PST)

Sure.

--b

----- Original Message ----
> To: Behcet Sarikaya <[email-masked]>; [email-masked]
> Sent: Mon, February 22, 2010 10:28:46 AM
> Subject: RE: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04
> 
> Hi Behcet,

It is now "next week". 

While the base solution is 
> cleaned up, I guess we are ready to discuss about protocol 
> enhancements.

Do you agree?

Juan Carlos

> -----Original 
> Message-----
> From: Behcet Sarikaya [mailto:> ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]]
> 
> To: Zuniga, Juan Carlos; > ymailto="mailto:[email-masked]" 
> Subject: Re: 
> [multimob] WG Adoption call on draft-schmidt-multimob-
> 
>   This current 
> adoption call is aimed at establishing if there is
> consensus that this 
> draft is the base solution. You are saying it is.
> 
>   Let's 
> > From: "Zuniga, Juan 
> Carlos" <> href="mailto:[email-masked]">[email-masked]>
> 
> > To: Stig Venaas <> href="mailto:[email-masked]">[email-masked]>; > ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked];
> > ymailto="mailto:[email-masked]" 
> > Subject: RE: [multimob] WG Adoption 
> callondraft-schmidt-multimob-
> > agreement that it is worth looking at 
> optimizations on top of the
> base
> > solution.
> 
> 
> > where 
> the solution detailed in draft-schmidt could have limitations,
> 
> for
> > instance when different MNs using different LMAs join the same 
> group.
> In such a
> > case we can save bandwidth by having a 
> dedicated multicast LMA. Also,
> another
> > advantage of a 
> dedicated LMA is to avoid the need for all LMAs to
> have 
> multicast
> > document and if it addresses the 
> open comments sent on the list it
> can become
> > the base 
> solution. However, I also believe that we have enough
> interest in 
> the

---

From: "Luis M. Contreras" <[email-masked]>
Date: Mon, 22 Feb 2010 18:01:37 +0100

Hi all,

Here are the comments I promised once finished the draft adoption process.

Thomas et al., on page 6 and 7 of your draft you describe the steps to 
be followed in case of MN handover. I include here such list for 
rerence:
------
1. The MAG-MN link comes up and the MAG discovers the new MN.

2. Unicast address configuration and PMIPv6 binding are performed,the 
MAG can determine the corresponding LMA.

3. Following IPv6 address configuration, the MAG SHOULD send an (early) 
MLD General Query to the new downstream link as part of its standard 
multicast-enabled router operations.

4. The MAG SHOULD determine whether the MN is admissible to multicast 
services, and stop here otherwise.

5. The MAG adds the new downstream link to the MLD proxy instance with 
up-link to the corresponding LMA.

6. The corresponding Proxy instance triggers an MLD General Query on 
the new downstream link.

7. The MN Membership Reports arrive at the MAG, either in response to 
the early Query or to that of the Proxy instance.

8. The Proxy processes the MLD Report, updates states and reports 
upstream if necessary.
-----

Comment number 1
================
The step number 4 states that "The MAG SHOULD determine whether the MN 
is admissible to multicast services, and stop here otherwise". How can 
the MAG determine if the MN is allowed to subscribe to multicast 
contents? At this stage, with current charter definition, it is not 
possible to handle or keep multicast specific information in binding 
cache nor signaling messages, so I think that the only way to know this 
is by means of receiving an MLD Report message to the MLD Query sent in 
step 3.

If so, I suggest to change the text in order to highlighht this 
dependency at this stage (for instance, something like: <<The MAG 
SHOULD determine whether the MN is admissible to multicast services 
""if an MLD Report is received as response to the previously sent MLD 
General Query"", and stop here otherwise>>). This would force to wait 
for the reception of the MLD report before adding the downstream 
interface to the corresponding proxy instance.

Comment number 2
==============
As far as I understand from your proposal, the MLD General Query in 
step number 3 is automatically sent by the MAG kernel. In this way the 
kernel expects to receive an MLD Report answering that Query. 
Nevertheless, if the MLD report sent by the MN arrives once the MAG-MN 
point-to-point has been added to the MLD proxy instance, that MLD 
Report is directly passed to the proxy instance, not to the kernel, 
according to step 7. In that case, Could the kernel assume that the 
first Query was lost (because the Report has not been delivered to it) 
and, in consequence, send Queries repeatedly (governed by the MLD's 
timers)? (the MLD reports to that queries would be continuosly passed 
to the proxy instance, not to the kernel which originates such messages)

If so, again, it is needed to add the MAG-MN point-to-point to the 
proxy instance once the MAG receives the first MLD report coming from 
the MN, not before.

Thanks in advance for clarification on these doubts,

Regards,

Luis

---

From: <[email-masked]>
Date: Tue, 23 Feb 2010 09:29:21 +0100

Dear Carlos, all,

Following the agreed adoption of the basic Multimob protocol we can and should revive and extend the discussion on further enhancements for protocol optimization as you suggested, Carlos. For that we have submitted the next version of the "future work" draft to exchange on potential range for those issues. Although by far not all possible topics have been covered we would like to base the design on this document.
The I-D can be found at http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-future-work-01.txt

What do you think?
Please feel free to comment!

Best regards
Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Behcet Sarikaya
Gesendet: Montag, 22. Februar 2010 17:44
An: Zuniga, Juan Carlos; [email-masked]
Betreff: Re: [multimob] WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04

Sure.

--b

----- Original Message ----

It is now "next week". 

Do you agree?

Juan Carlos

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 24 Feb 2010 22:52:58 +0100

Hi Luis,

thanks again for your critical comments: this is highly appreciated!

Please see my answers inline:

Luis M. Contreras wrote:
> be followed in case of MN handover. I include here such list for rerence:
> ------
> 6. The corresponding Proxy instance triggers an MLD General Query on the 
> new downstream link.
> 
> dependency at this stage (for instance, something like: <<The MAG SHOULD 
> determine whether the MN is admissible to multicast services ""if an MLD 
> Report is received as response to the previously sent MLD General 
> Query"", and stop here otherwise>>). This would force to wait for the 
> reception of the MLD report before adding the downstream interface to 
> the corresponding proxy instance.
> 

The part of "Multicast group allowance" is typically included in AAA, 
which indeed is out of scope of the current charter. However, the option 
that certain services are rejected will confirm to the charter. So it is 
fair to mention this issue, even though it remains out of scope how this 
knowledge reaches the entities (such as MAGs).

> Comment number 2
> ==============
> As far as I understand from your proposal, the MLD General Query in step 
> number 3 is automatically sent by the MAG kernel. In this way the kernel 
> expects to receive an MLD Report answering that Query. Nevertheless, if 
> the MLD report sent by the MN arrives once the MAG-MN point-to-point has 
> been added to the MLD proxy instance, that MLD Report is directly passed 
> to the proxy instance, not to the kernel, according to step 7. In that 
> case, Could the kernel assume that the first Query was lost (because the 
> Report has not been delivered to it) and, in consequence, send Queries 
> repeatedly (governed by the MLD's timers)? (the MLD reports to that 
> queries would be continuosly passed to the proxy instance, not to the 
> kernel which originates such messages)
> 
> If so, again, it is needed to add the MAG-MN point-to-point to the proxy 
> instance once the MAG receives the first MLD report coming from the MN, 
> not before.
> 
Yes and no: Indeed, the kernel does initiate the general queries (at 
least in the test cases we examined), but MLD messaging is not 
transactional. So even if a kernel query was issued, the reply could be 
interpreted by an additional process like an MLD proxy. As stated in the 
draft, it would be desirable to have the proxy downstream link 
configured at the time the MLD report arrives as an answer to the 
general query. However, the proxy would query by itself, so downlink 
configurations would sooner or later become part of the distribution tree.

Best regards,

Thomas

---

From: "Lu, Guang" <[email-masked]>
Date: Wed, 24 Feb 2010 17:52:24 -0500

Hi Thomas, 

We posted some comments on
draft-schmidt-multimob-pmipv6-mcast-deployment-04. 

http://www.ietf.org/mail-archive/web/multimob/current/msg00774.html

Have you got a chance to look at them? Please let us know your opinions.

Best Regards,
Guang

> Behalf Of Thomas C. Schmidt
> Sent: Wednesday, February 24, 2010 4:53 PM
> To: Luis M. Contreras
> Cc: [email-masked]
> Subject: Re: [multimob] WG Adoptioncall on draft-schmidt-multimob-
> SHOULD
> step
> proxy

---

From: Greg Daley <[email-masked]>
Date: Thu, 25 Feb 2010 14:17:20 +1100

Hi Thomas and Luis, 

> Please see my answers inline:
...
> > 
> > 3. Following IPv6 address configuration, the MAG SHOULD send an
> > (early) MLD General Query to the new downstream link as part of
> > its standard multicast-enabled router operations.

Forgive me for my long hiatus, and perhaps the scope of the PMIPv6
system precludes this being an issue.

Does anyone have an idea of the impact that a downstream multicast
General Query would have on an 802.11 Network each time a device
arrives on the cell?

The message transmitted unacknowledged on one of the rates in the
BasicRatesSet.  BasicRatesSet defines the common rates all devices
accessible by an AP must support.

Past behaviour on Wireless LAN defaults this to be low throughput
rates, and on  2.4GHz systems, this has typically been either 1Mbps,
or 2Mbps (or 3Mbps for 5GHz).  This takes potentially 54 times as
long for transmission of the data component than a comparable packet
delivered over MAC unicast.

With General Queries, there is no Robustness value (transmissions
occur once), so there's a possibility that a downstream multicast 
could also be lost, and no report received from the Listener.

Given that there is a MAG which is keeping track of unicast addressing
and configuration, would it not be appropriate to direct the General Query
to a unicast address of the arriving device in compliance with S5.1.15 of
RFC3810?

This would allow unicast packet delivery at Link-Layer, which incorporates
higher data rates, and MAC retransmission.

This may also be useful for other media.

(You could readily determine if it is better to send a Multicast or 
multiple unicasts based on the outstanding number of devices which are
Unicast configured, but not MLD Reporters).  The unicast/multicast
ratio could be configured on a per-interface basis.

Sincerely,

Greg Daley

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 25 Feb 2010 09:06:25 +0100

Hi Greg,

good to hear from you!

The issue you are raising is under debate in "the other" core objective 
of Multimob, the MLD tuning. Actually, Hitoshi Asaeda has proposed to 
use MLD by unicast in his presentation at the last IETF (Hiroshima), I 
believe for the exact same arguments you follow.

In the basic PMIPv6 context, this is not so much an issue, as RFC5213 
restricts downstream links to be point-to-point. In case of 802.11 
wireless access, this would lead to unicast tunnels anyway (possibly GRE 
- see http://tools.ietf.org/html/draft-ietf-netlmm-grekey-option-09).

So in brief: we agree, but the issue seems more related to the MLD 
tuning in wireless domains rather than to PMIP at its current spec.

Cheers,

Thomas

--

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 25 Feb 2010 17:56:53 +0900 (JST)

Hi Greg,

> General Query would have on an 802.11 Network each time a device

I think your question is related to my IGMP/MLD optimization draft.
Please take a look at;
http://tools.ietf.org/html/draft-asaeda-multimob-igmp-mld-optimization-01

> higher data rates, and MAC retransmission.

As you said it is difficult for coordinating the timing of general
query because each wireless link MAC has its different signaling
mechanism.
Unicast query discussed in the above draft is not perfect for every
condition.

Our draft aims to clarify the issues for mobile multicast and
describe the considerable way of tuning protocol timers and behavior.

I've been revising the draft. (I hope I finish it before this cut-off
date)
If you have comments, please tell me. Your input would be valuable.

Regards,
--
Hitoshi Asaeda