Subject: [Softwires] 6rd multicast

From: Tina Tsou <[email-masked]>
Date: Thu, 06 Jan 2011 15:32:01 -0800

Hi all,

http://datatracker.ietf.org/doc/draft-tsou-softwire-6rd-multicast/

is available.

This document describes how IPv6 multicast can be extended across an
   IPv4 network to an IPv6 host, using the native multicast capabilities
   of the IPv4 network.

This is a first draft, and definitely needs more work.

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

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 7 Jan 2011 20:49:56 +0000

Hi Tina,

I read the draft and I got few comments. Generally, it contains some
interesting ideas and thanks for writing the draft. However, it also
misses few key components that we must address to make it work:

1. IPv6 Mcast group -> IPv4 Mcast group. By design and pointed out in the
mesh-mcast draft, v6 mcast group has much larger space than v4 mcast
group, how do you foresee the mapping being done? This is the key part
before describing the mechanism.

2. If I read the draft correctly, the 6rd CE will send a message (TBD) to
the Translator Function (TF) to ask the 6rd BR to join the v6 mcast tree
and give the mapping to the 6rd CE. Then 6rd CE will send a PIMv4-Join to
the upstream mcast router. My question is why not ask the 6rd CE to
translate the MLDv2 to IGMP directly? What is the benefit of defining a
new protocol?

3. Section 3 mentioned that IGMPv3 is used. What is S? The 6rd BR?

4. I am not clear how Section 4 works. I assume 6rd-BR is a mcast router,
so you are saying it will ask TR for a mapping when it receives a
PIM-Join? How does 6rd-BR know which v4 grouds are meant for translation
and which aren't?

These are my comments so far.

Regards,
Yiu

On 1/6/11 6:32 PM, "Tina Tsou" <[email-masked]> wrote:

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

---

From: Tom Taylor <[email-masked]>
Date: Fri, 07 Jan 2011 18:39:19 -0500

(I've already sent this to my co-authors and Yiu, but forgot that the 
IETF lists are currently rejecting my posts from my normal address.)

Thanks for your comments. Responses below. BTW, we are going to follow a 
suggestion to write this draft as a more general mechanism, to cover any 
case where the host and the target network speak IPvx and the access 
network between speaks IPvy. We'll try to frame it so the host-end 
function (still trying to think of a name) can reside either in the CPE 
or in the provider IP edge.

> before describing the mechanism.

[PTT] You don't need a mapping for every v6 multicast group, only the 
ones that someone in your network wants to join. So it's an engineering 
issue -- how many addresses do you set aside in the address pool to 
handle your demand?
> translate the MLDv2 to IGMP directly? What is the benefit of defining a

[PTT] No, the new protocol is used only to request a mapping from <S,G> 
in the target network to <S',G'> in the access network. The 6rd CE does 
indeed translate the MLDv2 to IGMP directly (you must have missed a step 
in your reading), but it needs to know the access network view of the 
address pair (i.e., <S',G'>) before doing so.
> 3. Section 3 mentioned that IGMPv3 is used. What is S? The 6rd BR?

[PTT] Let's start with the <S,G> in the target network (IPv6 network, in 
our current draft). S is wild-carded if the multicast session is 
any-source (ASM). If the multicast session is specific-source (SSM), 
then S in the target network is a unicast IPv6 address. The translator 
maps that to an IPv4 unicast address S' from its pool, and the 6rd CE 
uses S' in its IGMP request.
> PIM-Join? How does 6rd-BR know which v4 grouds are meant for translation

[PTT] That's a point we hadn't thought of -- one of the details that 
have to be sorted out, along with the question of how the PIM-Join finds 
the 6rd-BR in the first place. For SSM, the answer is fairly simple: the 
translator sets S' to the unicast address of the 6rd-BR, as you 
suggested in an earlier comment. This doesn't work for ASM.
> On 1/6/11 6:32 PM, "Tina Tsou"<[email-masked]>  wrote:
>
>> Hi all,
>>

---

From: Jacni Qin <[email-masked]>
Date: Mon, 17 Jan 2011 14:53:36 +0800

Dear Authors,

A quick question,
I read 2.1 and the section 6 of 2.2, It seems that, for the multicast data
traffic, the IPv6 multicast packets are translated to native IPv4 packets on
BR then translated back on 6rd CE?
Or they are encapsulated over IPv4 and de-capsulated on 6rd CE?

Cheers,
Jacni

---

From: Tom Taylor <[email-masked]>
Date: Mon, 17 Jan 2011 08:54:24 -0500

It can go either way. Over the way we submitted a translation-based 
version to Behave: draft-tsou-behave-translated-multicast-00.txt. We 
will submit an encapsulation-based version to softwires shortly.

On 17/01/2011 1:53 AM, Jacni Qin wrote:
> On Fri, Jan 7, 2011 at 7:32 AM, Tina Tsou<[email-masked]>  wrote:
>
>> Hi all,
>>