Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

From: Tina TSOU <[email-masked]>
Date: Fri, 26 Aug 2011 02:34:35 +0000

Hi Med,
In line with [TT2]...

Best Regards,
Tina

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 25, 2011 12:06 AM
To: Tina TSOU; Jacni Qin
Cc: [email-masked]
Subject: RE: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

Hi Tina,

Please see inline.

Cheers,
Med

________________________________
De : Tina TSOU [mailto:[email-masked]]
Envoyé : mercredi 24 août 2011 20:26
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Jacni Qin
Cc : [email-masked]
Objet : RE: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Bonjour Med,
Ca va? Thank you for your deep insight and reply.
When the IPv6 packet comes, how does mB4 know it should make encapsulation or translation if mPrefix64 and uPrefix64 are the same? As defined in section 6.3 of draft-boucadair-behave-64-multicast-address-format<http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#ref-I-D.boucadair-behave-64-multicast-address-format>, "there is no need to reserve a bit in the IPv6 multicast address to separate between the translation and the encapsulation schemes." So when mPrefix64 and uPrefix64 are the same for both encapsulation and translation, mB4 could not make decision which operation to make. In this case, the IPv6 header itself can be used to identify encapsulation or translation. For example, if the next header of IPv6 header is 4, mB4 should make de-capsulation because there is IPv4 packet inside. If it is other value, translation may be needed.
[Med] Using the same mPrefix64 for both encap and translation is not recommended in draft-boucadair-* as you can read in the following excerpt:
"   IPv4-IPv6 encapsulator and translator may be embedded in the same
   device or even implemented with the same software module.  In order
   to help the function whether an encapsulated IPv6 multicast packets
   or translated IPv6 ones are to be transferred.  It was tempting to
   define an S-bit for that purpose but this choice has been abandoned
   in favor of the recommendation to use distinct MPREFIX64 for each
   scheme."

I don't see an issue here.

[TT2] Since encapsulation and translation use different mPrefix64, it is not an issue in draft-qin-* now. But draft-boucadair-* does not specify how to make mPrefix64 different for encapsulation and translation. Do you think it is needed?

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, August 23, 2011 11:54 PM
To: Tina TSOU; Jacni Qin
Cc: [email-masked]
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Hi Tina,
Please see inline.
Cheers,
Med
________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Tina TSOU
Envoyé : mercredi 24 août 2011 04:21
À : Jacni Qin
Cc : [email-masked]
Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Hi Jacni,
Thank you for your early reply. Have a good day.
My replies are below.
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
From: Jacni Qin [mailto:[email-masked]]
Sent: Tuesday, August 23, 2011 6:09 PM
To: Tina TSOU
Cc: [email-masked]
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
hi,
On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,
Some more comments on draft-qin-softwire-dslite-multicast-04.
#1
General comment: is there any consideration of interaction with unicast solutions, e.g., potential collocation or reuse of functions? Do we need some mapping or interaction table of the function elements or tunnels (IP-in-IP or IP-in-non-IP) to show the relationship with DS-Lite unicast solution?
Jacni>: As Yiu mentioned in another email, the co-location with unicast DS-Lite elements is more deployment specific, and I'm ok to remove the section 4.5. From the protocol perspective, I don't see there is necessary interaction with the unicast solution.
[TT] Section 4.5 is good for the readers to understand the difference between unicast and multicast DS-Lite. I strongly suggest add some texts into this section like "the co-location of multicast elements with unicast DS-Lite elements is more deployment specific".

[Med] OK. We will do.
#2
Section 6.2
Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as "it checks whether the group address is in the range of mPrefix64, the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4."

Jacni>:Currently, we only employ the encapsulation for date forwarding in the main text.
[TT] I am not talking about translation solution in the main text. Even if in the encapsulation case, mB4 needs to determine whether to make de-capsulation or not.

[Med] This excerpt from Section 6.2 explains the rule to follow:

   When the mB4 receives an IPv6 multicast packet, it checks whether the

   group address is in the range of mPrefix64 and the source address is

   in the range of uPrefix64.

Does this answer your question?