Hi Med,
On Wed, Jun 13, 2012 at 1:54 AM, <[email protected]> wrote: > Behcet, > > If you are suggesting we need get rid of multicast capabilities and use > unicast between the AFTR and B4, I still claim this is a bad design choice. > The rationale for the design documented in the draft is as follows (excerpt > from the draft): > > " > If customers have to access IPv4 multicast-based services through DS- > Lite environment, Address Family Transition Router (AFTR) devices > will have to process all the IGMP Report messages [RFC2236] [RFC3376] > that have been forwarded by the CPE into the IPv4-in-IPv6 tunnels. > From that standpoint, AFTR devices are likely to behave as a > replication point for downstream multicast traffic. And the > multicast packets will be replicated for each tunnel endpoint where > IPv4 receivers are connected to. > > This kind of DS-Lite environment raises two major issues: > > 1. The IPv6 network loses the benefits of the multicast traffic > forwarding efficiency because it is unable to deterministically > replicate the data as close to the receivers as possible. As a > consequence, the downstream bandwidth in the IPv6 network will be > vastly consumed by sending multicast data over a unicast > infrastructure. > > 2. The AFTR is responsible for replicating multicast traffic and > forwarding it into each tunnel endpoint connecting IPv4 receivers > that have explicitly asked for the corresponding contents. This > process may greatly consume AFTR's resources and overload the > AFTR. > > This document specifies an extension to the DS-Lite model to deliver > IPv4 multicast services to IPv4 clients over an IPv6 multicast- > enabled network. > " > There is a price for this. Many operators are willing to deploy IPv6 unicast only. If they deploy both unicast multicast IPv6 then they prefer to deploy dual stack network in which case there is no transition problem, see the discussion on Mboned list. > For me, DS-Lite model is not only what is documented in RFC6333 but covers > also stateless A+P including MAP and 4rd. > Well, that is a different problem that requires a different solution. You are confirming again that your draft does not care about DS-Lite. You are looking at anything else but DS-Lite. > Hope this clarifies your concern. > If you don't like unicast DS-Lite solution, it is not the job of multicast DS-Lite solution to resolve it. Regards, Behcet > Cheers, > Med > >>-----Message d'origine----- >>De : [email protected] >>[mailto:[email protected]] De la part de Behcet Sarikaya >>Envoyé : mercredi 13 juin 2012 00:23 >>À : Lee, Yiu >>Cc : [email protected] >>Objet : Re: [Softwires] WG last call on >>draft-ietf-softwire-dslite-multicast-02 >> >>Hi Yiu, >> >>The solution in this draft is generic, it simply leaves DS-Lite aside >>and builds its own stuff. >>I think this fact has been alluded to by the co-authors. >> >>This should change. Saying that a solution that integrates with >>DS-Lite is technically poor solution is saying that DS-Lite is >>technically poor solution. >> >>Behcet >> >>On Tue, Jun 12, 2012 at 3:56 PM, Lee, Yiu >><[email protected]> wrote: >>> Hi Behect, >>> >>> You confuse me. 4.3 said this: >>> >>> "When the mAFTR receives an IPv4 multicast packet, it will >>encapsulate >>> the packet into an IPv6 multicast packet using the >>IPv4-embedded IPv6 >>> multicast address as the destination address and an IPv4-embedded >>> IPv6 unicast address as the source address." >>> >>> The data packets are tunneled over IPv6 hub by hub. That >>said, the tunnel >>> isn't end-to-end. >>> >>> Thanks, >>> Yiu >>> >>> >>> On 6/12/12 4:30 PM, "Behcet Sarikaya" <[email protected]> wrote: >>> >>>>It is not the case in the draft currently, check Sections 4.3 & 6.2. >>>> >>>>Behcet >>_______________________________________________ >>Softwires mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
