(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.
On 07/01/2011 3:49 PM, Lee, Yiu wrote:
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.
[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?
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?
[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.
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?
[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.
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
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
