Hi Tina, Thank you very much for reviewing carefully this document.
Your editorial suggestions will be considered when we will generate the next revision of the I-D. As for the comment about the co-location of the MLD Querier and mAFTR, this is a deployment scenario among others. The I-D only discusses that case. Please keep in mind this I-D defines "functional elements" and not "nodes". Cheers, Med -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de Tina TSOU Envoyé : mardi 23 août 2011 03:58 À : [email protected] Objet : [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi all, In IETF-81, the chairs asked the authors of different drafts on multicast sit together to discuss and compromise. So we did. Here are some comments on draft-qin-softwire-dslite-multicast-04. Overall: if this is to be a Standards Track document, the whole document has to be reviewed, the normative parts identified, and requirements language substituted for the current descriptive language. Section 1: Editorial: at the end of the second paragraph, "vastly consumed" reads better in English as: "consumed in vast quantities". Substantive: add the following to the sentence making up the third paragraph: "..., which prevents these consequences by making use of the native multicast capabilities of the intervening IPv6 network." Section 2: Terminology: "Multicast AFTR" has connotations (IPv4 NAT) that simply aren't there. Suggestion: "Multicast Transitional Border Gateway (mTBG)". Substantive(?): In the description of the Multicast B4, it would make more sense to change "... which is able to enforce ..." to "... which implements ...". 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." 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." 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 ..." 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 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 ..." 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. No more comments up to section 7. Maybe more comments from section 7 onwards in a separate E-mail. Regards, Tina _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
