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

From: Tina TSOU <[email-masked]>
Date: Wed, 24 Aug 2011 00:02:49 +0000

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?

#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."

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

---

From: Jacni Qin <[email-masked]>
Date: Wed, 24 Aug 2011 09:09:10 +0800

hi,

On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU <[email-masked]>wrote:

> 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.

> #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.

Cheers,
Jacni

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Tina TSOU <[email-masked]>
Date: Wed, 24 Aug 2011 02:21:13 +0000

Hi Jacni,
Thank you for your early reply. Have a good day.
My replies are below.

Best Regards,
Tina TSOU

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".

#2
Section 6.2

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.

Cheers,
Jacni

Best Regards,
Tina TSOU

_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: Jacni Qin <[email-masked]>
Date: Wed, 24 Aug 2011 10:32:47 +0800

hi,

On Wed, Aug 24, 2011 at 10:21 AM, Tina TSOU <[email-masked]>wrote:

> ...
> uPrefix64 and whether the next header of IPv6 header is 4."****
>
>
> [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.
>
> Jacni>: In the case of encapsulation, the mB4 can determine that by
checking whether the group address is within the mPrefix64 and the source
address is within the uPrefix64, as what the 6.2 says.

Cheers,
Jacni

---

From: <[email-masked]>
Date: Wed, 24 Aug 2011 08:54:23 +0200

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,

Best Regards,
Tina TSOU

hi,

[Med] OK. We will do.
#2
Section 6.2

[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?

---

From: Tina TSOU <[email-masked]>
Date: Wed, 24 Aug 2011 18:25:39 +0000

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.

Best Regards,
Tina TSOU

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

Best Regards,
Tina TSOU

hi,

[Med] OK. We will do.
#2
Section 6.2

---

From: Tina TSOU <[email-masked]>
Date: Wed, 24 Aug 2011 19:16:58 +0000

Dear Jacni,
Please see in line...

Best Regards,
Tina TSOU

From: Jacni Qin [mailto:[email-masked]]
Sent: Tuesday, August 23, 2011 7:33 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 10:21 AM, Tina TSOU <[email-masked]<mailto:[email-masked]>> wrote:
...
#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.
Jacni>: In the case of encapsulation, the mB4 can determine that by checking whether the group address is within the mPrefix64 and the source address is within the uPrefix64, as what the 6.2 says.
[TT1] When the packet comes, how does mB4 know it should make encapsulation or translation if mPrefix64 and uPrefix64 are the same?  In this case, the next header of IPv6 header could be used for mB4 to determine.

Cheers,
Jacni

---

From: Jacni Qin <[email-masked]>
Date: Thu, 25 Aug 2011 08:46:38 +0800

On Thu, Aug 25, 2011 at 3:16 AM, Tina TSOU <[email-masked]>wrote:

> [TT1] When the packet comes, how does mB4 know it should make encapsulation
> or translation if mPrefix64 and uPrefix64 are the same?  In this case, the
> next header of IPv6 header could be used for mB4 to determine.
>
> Jacni>: Please see again my comments above, also your own. Thanks.

Cheers,
Jacni

---

From: <[email-masked]>
Date: Fri, 26 Aug 2011 08:48:24 +0200

Hi Tina,
 
Please see inline.

Cheers
Med 

De : Tina TSOU [mailto:[email-masked]] 
Envoyé : vendredi 26 août 2011 04:35
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Jacni Qin
Cc : [email-masked]
Objet : RE: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

Hi Med,

In line with [TT2].

Best Regards,

[SNIP]

[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?

Med: I confirm this is not an issue for draft-qin. In draft-boucadair, we can for sure clarify more and state "the operator of the v4/v6 multicast intercinnection nodes configures two distinct mPREFIX64, ..."