On Wed, Jun 6, 2012 at 8:43 AM, Wojciech Dec <[email protected]> wrote: > +1 > The IGMP/MLD translation is the key piece of this draft and needs to be > thorough. > > In addition a general observation: This draft appears to have very little in > common with DS-Lite (nothing except use of IPinIP on my reading), and using > that reference and the AFTR terms is confusing. The fact that technically it > features an address family mapped multicast transport, which alongside with > the IGMP/MLD translation makes it anything but transparent tunneling. A > change of title would be also useful, as well as general decoupling from the > ds-lite architecture: The mAFTR device can, and likely will be a often a > dedicated multicast device that plays no part in unicast forwarding. >
You mean, in order to be DS-Lite related it has to be tunneling based? Actually, I did have a draft with such a solution. Some people argued that we should not go for a tunneling solution because there is already an inherent tunneling. So this draft was chosen as the solution approach. The philosophical question here is why do we have DS-Lite which does tunneling on top of the inherent tunnel? Behcet _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
