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 protected]> wrote: >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 > > > >_______________________________________________ >Softwires mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
