Thanks for the comments, inline please. On Tue, Aug 23, 2011 at 9:58 AM, Tina TSOU <[email protected]>wrote:
> 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. > Jacni>: I don't see it, while you can post comments. > Section 1: > > Editorial: at the end of the second paragraph, "vastly consumed" reads > better in English as: "consumed in vast quantities". > > Jacni>: Sorry, EN is not my first language. Maybe we need the help from a native guy. > 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." > > Jacni>: No objection to add a sentence, but modified as "which preserves the efficiency of using multicast for traffics forwarding." > Section 2: > > Terminology: "Multicast AFTR" has connotations (IPv4 NAT) that simply > aren't there. Suggestion: "Multicast Transitional Border Gateway (mTBG)". > > Jacni>: I think the AFTR is a general item, see the similar comments raised in another thread about 4rd. > 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: > > Jacni>: Sorry, I don't agree. I think text in the paragraph following the bullet explains the scope clearly. > "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." > > Jacni>:That's what the current text means. > 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 ..." > Jacni>: The signalling things will be detailed in the signalling section. This is just a general description here. > > 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 > Jacni>: Oops, got it, thank you. > > 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: > Jacni>: Actually, this is one of the typical cases. The mAFTR can be embedded in the MLD Querier, which will not bapass the IPv6 multicast infrastructure. > > "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. Jacni>: We don't see the problems so far. > 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. > Jacni>: Sorry, I don't understand the ".. IPv4 prefix that is shared by the source.." For multicast routing, multicast routers including mAFTR will deal with that based on converged unicast routing. You can learn more about it in the following sections. > > No more comments up to section 7. Maybe more comments from section 7 > onwards in a separate E-mail. > Jacni>: Thank again for your comments. Cheers, Jacni > > 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
