+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. -Woj. On 5 June 2012 15:09, Simon Perreault <[email protected]> wrote: > On 2012-06-04 22:13, Jacni Qin wrote: > >> Section 6.1 introduces IGMP/MLD translation, but I fear it is very >>> underspecified. Our own effort at specifying IGMP/MLD translation is >>> in draft-perreault-mboned-igmp-**mld-translation. I feel that DS-Lite >>> multicast would be better served by referencing our draft instead. >>> >>> Thanks for your comments, while as stated in the text, the Interworking >> function is a combination of proxying (RFC4605) and translation >> (draft-ietf-mboned-64-**multicast-address-format, sorry the reference was >> lost, we'll fix it). >> > > I understand that. But note that this is an important new function. AFAIK > IGMP/MLD translation doesn't exist in any other RFC. Your draft would be > underspecifying it IMHO, possibly leading to interoperability issues. > > I don't think it's up to SOFTWIRE to standardize IGMP/MLD translation. > > > The implementations vary, and we are trying to avoid deeply diving into >> that since it is sufficient for the implementers, and those should be >> detailed in some deployment document if needed. Anyway, please list what >> you think is missing, we can add more text to further clarify it. Thanks >> a lot! >> > > At IETF 83 I showed this list to the PIM working group to demonstrate that > IGMP/MLD translation is not as simple as people think it is. It's a list of > things our draft (draft-perreault-mboned-igmp-**mld-translation) > specifies: > > - Well-known multicast address equivalences between IPv4 and IPv6. > - Message type equivalences between IGMPv{1,2,3} and MLDv{1,2}. > - Translation needs to be performed logically on upstream interface of > proxy so as not to mess with Querier elections. > - Router Alert > - IPv4 option ↔ Hop-by-Hop IPv6 extension header > - Send on output IFF it was received on input. > - Set value to zero unconditionally. > - Reports with unspecified source address need to be handled differently > for IGMP vs MLD. > - Allocation of a “Translated” bit in IGMPv3 and MLDv2 Queries and Reports. > - Formulas for the conversion of MRD↔MRT with or without loss of precision. > - Preservation of Additional and Auxiliary Data. > - MTU considerations... sigh > - Data plane handled according to RFC6145. > > I don't want to argue this list in SOFTWIRE because I think it's the wrong > forum. My point is that IGMP/MLD translation needs to be correctly > specified, and it needs to be done in PIM. Any SOFTWIRE protocol that > requires IGMP/MLD translation needs to refer to something coming from PIM. > > > Simon > -- > DTN made easy, lean, and smart --> > http://postellation.viagenie.**ca<http://postellation.viagenie.ca> > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > ______________________________**_________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/**listinfo/softwires<https://www.ietf.org/mailman/listinfo/softwires> >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
