hi, On Fri, Aug 26, 2011 at 10:31 AM, Tina TSOU <[email protected]>wrote:
> Bonjour Med, > Thank you for your comments. > What Yiu said is not reflected in figure 3. In the current figure, mAFTR > can receive (PIMv6 Join, PIMv6 Routers in between). However, if the IPv6 > network is layer 2 network, mAFTR should be able to receive MLD report as > well. mAFTR also performs MLD/PIMv4 interworking in this case. So I propose > update figure 3 to be complete. Section 8 does not mention how mAFTR acts in > this case. > > Jacni>: Figure 3 illustrates the functional elements, not layer 2 multicast things, while the "IPv6 Network" in the figure can be layer 2 if you want to understand it that way, no problem. What you said concerning two different things, * The layer 2 multicast mechanisms, like MLD Snooping, this approach is totally compatible with it. That's what Section 8 is talking about. Please see Yiu and Med's comments. * The MLD/PIMv4 is one of the scenarios, as we explained in previous emails. Also in the figure3, if there are "PIMv6 Routers in between", the AFTR will receive PIMv6 join then do PIMv6/PIMv4, otherwise it will receive MLD messages then do MLD/PIMv4. Cheers, Jacni > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of [email protected] > Sent: Thursday, August 25, 2011 1:11 AM > To: Lee, Yiu; [email protected] > Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 > > Hi Tina, > > I agree with Yiu. FYI, we had a discussion between co-authors of the draft > whether we maintain > http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#section-8or > remove it. > > You can read in that section: > > " Additionally, > mechanisms such as MLD Snooping, MLD Proxying, etc., can be > introduced into the distributed Access Network Nodes (e.g., > Aggregation Switches, xPON devices) which then could behave as MLD > Querier and replicate multicast flows as appropriate. Thus, the > multicast replication point is moved downward closer to the > receivers, so that bandwidth consumption is optimized." > > What do you think is missing in that text? > > Cheers, > Med > > ________________________________ > > De : [email protected] [mailto:[email protected]] De la > part de Lee, Yiu > Envoyé : jeudi 25 août 2011 05:31 > À : [email protected] > Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 > > > Hi Tina, > > What do you see new here in this scenario? mAFTR is a logical function, it > would perform MLD PIMv4-Join interworking. This has been captured. If a > vendor wants to make mAFTR also a L2 device, it would perform standard MLD > snooping. What else is missing? > > Thanks, > Yiu > > From: Tina TSOU <[email protected]> > Date: Thu, 25 Aug 2011 02:11:18 +0000 > To: "[email protected]" <[email protected]> > Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 > > > > Hi all, > > One more comment on Section 7.4.2. > > This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need > to consider the scenario where it is layer 2 network between mAFTR and mB4. > The architecture is as below: > _______________________________________________ > 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
