Subject: Re: [multrans] Updated version of the multicast PS draft

From: <[email-masked]>
Date: Thu, 9 Jun 2011 15:31:56 +0800

Hello all,
 
I echo Tina's suggestion to edit and share a discussion between Problem Statement draft authors and me to multrans list.
 
Xiaohong: Comment #1 on section 2.2
To be more consistent with section 3, IMHO, it is also worth mention that when receiver and source are of different IP address family, in particular, IPv6 receiver and IPv4 source in NAT64 case, issues raise. For this purpose, propose add something like this:
"For the sake of good use of scared IPv4 address recourses,it is also likely, 
 during transion period, that terminal devices are only provisioned 
 with an IPv6 prefix, but the multicast content is still IPv4-formatted.
 As a result, IPv6 receivers need ways to receive IPv4-formatted multicast
  content."
 Christian: Re comment #1, I propose the following additional sentence in section 2.2: "Likewise, the global IPv4 address depletion encourages the development of IPv6 receivers while contents may very well remain IPv4-formatted. There is therefore a need to make sure such IPv6 receivers can access IPv4-formatted contents during the transition period."
 Jacni>: It's good! :-)
 
Xiaohong: Comment #2 on section 3.1.
Propose to change the wording of:  "this scenario is prioritized by service providers, *including* those that are deploying or will deploy DS-Lite CGN capabilities for the sake of IPv4 service continuity. " to " this scenario is prioritized by service providers, *especially* those that are deploying or will deploy DS-Lite CGN capabilities for the sake of IPv4 service continuity. " , because IMHO, other operators, for example, who are deploying NAT444,  may not prioritize this use case.
Christian: Re your comment #2, I'm not sure we need that subtlety ("especially" instead of "including") as we don't make any specific assumption about the various situations that may arise. I therefore suggest to leave the text as is. But I'll wait for the feedback of my fellow co-authors before posting an updated version of the draft based upon your comments.

Cheers,
Xiaohong
opensource A+P: http://opensourceaplusp.weebly.com/

________________________________

	发件人: Tina Tsou [mailto:[email-masked]] 
	发送时间: 2011年6月9日 1:22
	收件人: 'Jacni Qin'; JACQUENET Christian OLNC-NAD-TIP
	抄送: DENG Xiaohong ESP/PEK; 'Lee, Yiu'; BOUCADAIR Mohamed OLNC-NAD-TIP
	主题: RE: RE:Updated version of the multicast PS draft

	Friends,
	Would you send your technical comments to the multrans list, and then broader audience can listen to?
	 
	We keep our promises with one another – no matter what!
	 
	Best Regards,
	Tina TSOU
	http://tinatsou.weebly.com/contact.html
	 
	From: Jacni Qin [mailto:[email-masked]] 
	Sent: Wednesday, June 08, 2011 2:09 AM
	To: [email-masked]
	Cc: DENG Xiaohong ESP/PEK; Tina Tsou; Lee, Yiu; BOUCADAIR Mohamed OLNC/NAD/TIP
	Subject: Re: RE:Updated version of the multicast PS draft
	 
	Re-,
	
	Thanks Xiaohong for the comments,
	On Tue, Jun 7, 2011 at 5:44 PM, <[email-masked]> wrote:
	Hello Xiaohong,
	 
	Thanks for both your kind words and your feedback :-)
	 
	Re: your comment #1, I propose the following additional sentence in section 2.2: "Likewise, the global IPv4 address depletion encourages the development of IPv6 receivers while contents may very well remain IPv4-formatted. There is therefore a need to make sure such IPv6 receivers can access IPv4-formatted contents during the transition period."
	
	Jacni>: It's good! :-)

	Cheers,
	Jacni
		 
		Re: your comment #2, I'm not sure we need that subtlety ("especially" instead of "including") as we don't make any specific assumption about the various situations that may arise. I therefore suggest to leave the text as is.
		 
		But I'll wait for the feedback of my fellow co-authors before posting an updated version of the draft based upon your comments.
		 
		Thanks again!
		 
		Cheers,
		 
		Christian.

---

From: Tina Tsou <[email-masked]>
Date: Thu, 09 Jun 2011 12:56:31 -0700

Hi Jacni,
I bring it to the list, hope you don’t mind.

Best Regards,
Tina TSOU
 
Sent: Thursday, June 09, 2011 2:07 AM
 
hi all,

I wrote some text for the IGMP-MLD mode, to clarify the IGMPv2-MLDv2 issue.

-------------------------------------------------------
4.4.1.1. IGMP-MLD

In this mode, the IWF element performs the router portion on its
interface facing hosts, and the host portion on its interface facing
the Querier, as below:

 +------+    +-----+    +---------+
 | Host | -- | IWF | -- | Querier |
 +------+    +-----+    +---------+

IPv4 receivers

When receivers are IPv4, they can be connected to MLD Querier by IWF
as below:

 +----------+    +-----+    +---------+
 |   IPv4   | -- | IWF | -- |   MLD   |
 | Reciever |    +-----+    | Querier |
 +----------+               +---------+

If IGMPv2 operates in the IPv4 domain while MLDv2 operates on the MLD
Querier, or if IGMPv3 operates in the IPv4 domain while MLDv1 operates
on the MLD Querier, the issue mentioned above will be encountered. To
solve this problem, the IWF should perform the router portion of IGMP
which is of the same version operating in the IPv4 domain, and convert
the IGMP message to MLD format accordingly (i.e. IGMPv2 to MLDv1, or
IGMPv3 to MLDv2). Then the IWF can use the protocol interaction
approach specified in Section 8 of [RFC3810] to exchange signaling
messages with the MLD Querier on which the different version of MLD is
operating.

IPv6 receivers

When receivers are IPv6, they can be connected to IGMP Querier by IWF
as below:

 +----------+    +-----+    +---------+
 |   IPv6   | -- | IWF | -- |  IGMP   |
 | Reciever |    +-----+    | Querier |
 +----------+               +---------+

If MLDv1 operates in the IPv6 domain while IGMPv3 operates on the IGMP
Querier, or if MLDv2 operates in the IPv6 domain while IGMPv2 operates
on the IGMP Querier, the issue mentioned above will be encountered. To
solve this problem, the IWF should perform the router portion of MLD
which is of the same version operating in the IPv6 domain, and convert
the MLD message to IGMP format accordingly (i.e. MLDv1 to IGMPv2, or
MLDv2 to IGMPv3). Then the IWF can use the protocol interaction
approach specified in Section 7 of [RFC3376] to exchange signaling
messages with the IGMP Querier on which the different version of IGMP
is operating.
------------------------------------------------------

Comments?

Cheers,
Jacni