Hi Tina, Thanks for the review. Comments below:
On 8/22/11 9:58 PM, "Tina TSOU" <[email protected]> wrote: > >Section 3.2: > >Bullet 1: the second sentence jams two unrelated ideas together. It >needs a little expansion to read properly. The next sentence doesn't >make sense within the stated scope of the bullet and shouldn't be there. >The suggested changed text is thus: > > "A viable scenario for this use case in DS-Lite environment: customers > with legacy receivers must continue to access the IPv4-enabled > multicast services. This means the traffic should be accessed > through IPv4 and additional functions are needed to traverse the > operator's IPv6- enabled network. It is the purpose of this > document to describe those functions. Refer to [I-D.jaclee-behave- > v4v6-mcast-ps] for the deployment considerations." [YL] I don't follow your argument saying "jams two unrelated ideas together". What we tried to say was an operator could use dual-stack. However, I would agree we should remove to discuss the dual-stack case because this is targeted for DS-lite. > >Final paragraph: don't you need a final sentence saying something like: >"Depending on the specific details of the contract, this may mean that >the specific framing of the content packets (as IPv4 packets) must be >preserved along with the content within that framing." [YL] We spoke the same thing. We can clarify in next revision. > >Section 4: > >First paragraph: the following sentences need to be added after the >first one to give a full picture of what is required for a solution: > >"For multicast, in contrast, separate mechanisms are required to process >the outgoing multicast signalling packets and the incoming packets of >content. The multicast signalling needs to be interworked to IPv6 and >processed as IPv6 signalling. For incoming multicast content, this >document defines ..." [YL] We will consider this. I would suggest to the following instead: "In the original DS-lite specification, an IPv4-in-IPv6 softwire is used to carry the bidirectional IPv4 unicast traffic between B4 and AFTR. This document defines an IPv4-in-IPv6 encapsulation scheme to deliver unidirectional multicast traffic from IPv4 multicast source behind AFTR to the IPv4 multicast receiver behind B4. This specification defines to interwork IPv4 multicast and IPv6 multicast protocols (e.g. IGMPv3 <-> MLDv2) and to deliver IPv4 multicast packets in IPv6 encapsulation." > >Middle paragraph: why doesn't it simply read: > >"See Section 4.3 for multicast distribution tree establishment and >Section 4.4 for multicast traffic forwarding." > >Section 4.2 > >Third paragraph typo: mPrefixe64 -> mPrefix64 [YL] Fixed > >Section 4.3 > >Bullets: it makes no sense to embed the mAFTR in the MLD Querier. That >would cause the native IPv6 multicast infrastructure to be bypassed. It >is also inconsistent with the architectural figure. Delete the first >bullet and merge the second one with the next paragraph, like this > >"The mAFTR should process the received PIMv6 Join message for the >IPv4-embedded IPv6 group and send the corresponding IPv4 PIM Join >message. It creates an entry for the IPv6 multicast group address in its >multicast Routing Information Base. This entry is used to forward ..." [YL] I don't follow this. How would mAFTR bypass native IPv6 multicast infrastructure? This is another deployment scenario which would allow an operator to deploy mAFTR in the CPE's default router. However, to eliminate confusion, we could move this in a different section. > >Section 4.5 > >It is not clear whether the final paragraph is talking about the mB4+B4 >or the mAFTR+AFTR or both. In fact, it makes good sense to combine the >mB4 and the B4, but combining the AFTR and mAFTR would be questionable >for reasons of scalability. There may be routing issues to sort out >regarding reachability of the IPv4 prefix that is shared by the source >-- the multicast routers should choose the path leading through the >mAFTR rather than the one going through the AFTR. [YL] We were talking mAFTR and AFTR, and mB4 and B4. All we were saying this was possible. We didn't enforce it. I would suggest to remove the entire section since this is a deployment option, not so much about specification. Regards, Yiu _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
