Re-,
On 6/5/2012 Tuesday 9:09 PM, Simon Perreault 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.
To be honest, we've ever considered a separate draft to specify that
function, but we finally dropped it in the last moment before
submitting, since we realized during the preparation for the Demo in
Taipei that it's actually not a new function, nor needs to be
standardized anywhere, but more belongs to the scope of implementation.
The implements vary, one example could be: have both IPv4 and IPv6
membership database maintained, then just synchronize the two through
the address translation, all other things can be handled by the Proxying
functionality (RFC4605).
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.
You are doing a protocol translation, which is just one possible kind of
implementations, and it's true that what you list above are required if
you want to go this way, IMHO it is a complicated one.
As mentioned earlier, RFC4605 plus the address translation can also do
that. And most columns you list will be avoid.
While I'm happy to see a deployment document to discuss the issues of
implementations.
Cheers,
Jacni
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
