Subject: [multimob] Adoption of draft-asaeda-multimob-igmp-mld-optimization-05 as a wg document

From: Stig Venaas <[email-masked]>
Date: Thu, 05 May 2011 12:50:57 -0700

Hi

The draft draft-asaeda-multimob-igmp-mld-optimization-05 was presented
in the wg meeting in Prague. We were asking about adoption there. A few
people supported it, none were against.

To decide whether to adopt, we also need to check on the list.

Please read the document, and state whether you think it is ready for
adoption or not.

Note that we have in our charter to submit a document on how to tune
IGMPv3/MLDv2 for mobility.

Stig

---

From: Xiajinwei <[email-masked]>
Date: Tue, 10 May 2011 13:35:01 +0800

I support to adopt it as WG I-D.

BR
Jinwei

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stig Venaas
> Sent: Friday, May 06, 2011 3:51 AM
> To: [email-masked]
> Subject: [multimob] Adoption of 
> draft-asaeda-multimob-igmp-mld-optimization-05 as a wg document
> 
> Hi
> 
> The draft draft-asaeda-multimob-igmp-mld-optimization-05 was 
> presented in the wg meeting in Prague. We were asking about 
> adoption there. A few people supported it, none were against.
> 
> Please read the document, and state whether you think it is 
> ready for adoption or not.
> 
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

---

From: <[email-masked]>
Date: Tue, 10 May 2011 11:05:06 +0200

Dear all,
I confirm my attitude in Prague and opt for adoption as WG draft.

BTW some very minor nits may be corrected:
P.5:
may be potentially- => 'may be' or: 'is potentially'

P.6:
is reached to => 'reaches' or: 'actually reaches'

   wireless network to other wireless network managed by the different
=> 'wireless network to an other wireless network managed by a different'

 According to our experimental analysis
=> would it be possible to add an informational reference for that?

P.9:
 to each desired hosts => 'to all desired hosts'

P.10
and required to support => 'and is required to support'

being interoperate => 'being interoperable'

Thanks and best regards
Dirk

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 13 May 2011 13:29:53 +0900 (JST)

Hi Dirk,

Thanks for your careful review.
I'll address them in the revised draft.

Any other comments are also welcome.

Thank you,
--
Hitoshi Asaeda

---

From: Stig Venaas <[email-masked]>
Date: Mon, 16 May 2011 10:28:43 -0700

> Any other comments are also welcome.

I think we still need to hear from more people. Please let us know what
you think of the current version. Is it ready for adoption?

Any inputs that can help improve it are certainly very welcome as well.

Stig

---

From: Zhen Cao <[email-masked]>
Date: Thu, 19 May 2011 14:45:07 +0800

I support the adoption of this draft, and this version is a good
starting point.

-- 
Best regards,
Zhen

---

From: Stig Venaas <[email-masked]>
Date: Thu, 26 May 2011 12:13:48 -0700

It looks like we have sufficient support to adopt this. Quite a few in
favor and no one against.

Hitoshi, please resubmit as a wg document,

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 May 2011 13:03:08 -0700 (PDT)

I suggest naming the WG draft as

draft-multimob-igmp-mld-tuning

in line with the charter.

Regards,

Behcet

---

From: "Romdhani, Imed" <[email-masked]>
Date: Tue, 31 May 2011 17:50:02 +0100

Dear all,

I am sorry for not commenting earlier on this draft. I would like to share with all folks some comments that I have already sent to the authors.

I endorse the proposal and I do support it. However, I have some comments on the draft. Overall, there is still a need to clarify and to distinguish between two aspects in the operation of IGMP/MLD. A clear distinction between Router Operation and Host Operation should be discussed especially when it comes to tuning decision either to speed up or to slow down control signalling messages.

Another point that the authors have probably "missed" to discuss is the case where a Mobility Agent (Home Agent, Proxy or Anchor Point) is a Querier. In this case, the agent has to run multiple instances of the IGMP/MLD processes on physical network interfaces and on tunnel interfaces. The behaviour of IGMP/MLD should be naturally different as the awareness level of the multicast membership is different. In addition, the processes are not independent as one may affect the other. Fixed members may affect mobile devices that are away due to their join/leave activities.  

As the values of the different timers are concerned, I think there is no need to fix them. Authors have justified their choice based on analysis that they have done, but I think there should be a sort of variation (range that can be enlarged or shortened) depending on different circumstances and the layer 2 technology used.

Having a track record of mobile members may be easy to detect and maintain if the Home Agent is a Querier. In other cases, I don't see who we can distinguish the origin of an IGMP/MLD report message (i.e. coming from a mobile or stationary device). Routers are connected in general to Wireless Domain Systems or Access Points and they are not directly connected to mobile devices (design assumption and management issue).

Finally, a mobile device may need to speed up sending his IGMP/MLD report. As far as I know, in Mobile IP specification, a mobile device needs to wait first the reception of an IGMP/MLD query before being eligible to send a report (through the bidirectional tunnel), probably this is an implicit part of the Return Routability procedure (CoA needs to be validated before use).

Hope my comments help to improve the draft.

Kind Regards,
Imed
---------------------------------------------------
Imed Romdhani, PhD
IEEE Member, FHEA 
Lecturer in Networking
Room C 64
Edinburgh Napier University
School of Computing
10 Colinton Road
Edinburgh, EH10 5DT
UK
E-Mail:   [email-masked]
Home Page: http://www.dcs.napier.ac.uk/~cs244/
Telephone: +44(0)131 455 2726
Fax: +44(0)131 455 2727
---------------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: 26 May 2011 20:14
To: [email-masked]
Subject: Re: [multimob] Adoption of draft-asaeda-multimob-igmp-mld-optimization-05 as a wg document

Stig

Edinburgh Napier University is Edinburgh's top university for graduate employability (HESA 2010), and proud winner of the Queen's Anniversary Prize for Higher and Further Education 2009, awarded for innovative housing construction for environmental benefit and quality of life.

This message is intended for the addressee(s) only
and should not be read, copied or disclosed to anyone else outwith 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: Qin Wu <[email-masked]>
Date: Wed, 01 Jun 2011 12:29:07 +0800

Hi, Imed:
Thank for your feedback, please see my reply inline.

Regards!
-Qin
----- Original Message ----- 
From: "Romdhani, Imed" <[email-masked]>
To: "Stig Venaas" <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 01, 2011 12:50 AM
Subject: Re: [multimob] Adoption of draft-asaeda-multimob-igmp-mld-optimization-05 as a wg document

> I endorse the proposal and I do support it. However, I have some comments on the draft. Overall, there is still a need to clarify and to distinguish between two aspects in the operation of IGMP/MLD…

[Qin]: I agree it is more valuable to discuss how IGMP/tuning works in mobility usage scenario rather than limited tuning mechanism to the pure wireless cases.

> Another point that the authors have probably "missed" to discuss is the case where a Mobility Agent (Home Agent, Proxy or Anchor Point) is a Querier. In this case, the agent has to run multiple instances of the IGMP/MLD processes on physical network interfaces and on tunnel interfaces. The behaviour of IGMP/MLD should be naturally different as the awareness level of the multicast membership is different.

[Qin]: You are talking about how to differentiate between remote subscription case and home subscription case? 
As I said, I agree to discuss how IGMP/MLD tuning is used in mobility scenario.
However I am not sure what's the difference of the behavior  of IGMP/MLD in two different cases mentioned above?

BTW: what kind of agent you are talking about process the IGMP/MLD message?
I suspect the agent is not mobility agent.

 In addition, the processes are not independent as one may affect the other. Fixed members may affect mobile devices that are away due to their join/leave activities.  

[Qin]: How, can you clarify it more?

> As the values of the different timers are concerned, I think there is no need to fix them. Authors have justified their choice based on analysis that they have done, but I think there should be a s…

[Qin]: Agree. It is reasonable to allow parameters to be tuned vary from different circumstances.

> Having a track record of mobile members may be easy to detect and maintain if the Home Agent is a Querier.

[Qin]: Agree since home agent or other agent can maintain the record of each mobile members in the mobility scenario.

 In other cases, I don't see who we can distinguish the origin of an IGMP/MLD report message (i.e. coming from a mobile or stationary device). Routers are connected in general to Wireless Domain Systems or Access Points and they are not directly connected to mobile devices (design assumption and management issue).

[Qin]: Why should we need to distinguish whther IGMP/MLD report message is sent from mobile device or a fixed device?

> Finally, a mobile device may need to speed up sending his IGMP/MLD report. As far as I know, in Mobile IP specification, a mobile device needs to wait first the reception of an IGMP/MLD query befor…

[Qin]:As regarding to whether IGMP/MLD query is needed each time, I am afaid that I am not tending to agree. In some case, we need solicited 
 membership report, in some case, we use unsolicited membersip report. e.g., the first subscriber joins a multicast group, 
 or the last subscriber leaves a multicast group.