Re: [MBONED] An alternative to draft-ietf-mboned-64-multicast-address-format?

[Stig Venaas <[e-mail]>]

On 6/29/2012 12:35 PM, Manfredi, Albert E wrote:
>> -----Original Message-----
>
>
>> For multicast things are kind of reversed. From say PIM perspective,
>> you
>> can start out with someone joining an IPv6 group where the last 32 bits
>> form an IPv4 group address. When this IPv6 join reaches say a device on
>> the edge of the IPv4 network, it can based on configuration (or
>> hard-coded if a standardized prefix), or a flag in the group address,
>> or a join attribute (these are the solutions I think we have on the
>> table), know that it should extract those 32 bits, and join the IPv4
>> source. When it receives IPv4 data packets, it can based on its PIM
>> state know what IPv6 address to translate them to.
>>
>> There are other use-cases, this is maybe the easiest one.
>
> This seems similar yo what I had described, except that the 96-bit prefix is configurable (presumably there will be an OOB mechanism to indicate what the prefix should be), AND it also seems to depend on PIM.

I guess I could try to explain why I think a fixed well-defined prefix
is a bit too limiting. It could work in some cases though. When I say
configurable, it could in theory be passed via some other protocol.

> What about cases in which PIM isn't used? For example, where proxy IGMP or proxy MLD is used, to make multicasts traversing a network available to an egress router? Or are we saying that it's okay to have incompatible solutions depending on each use case?

For this new proposal, we're describing a flag that can be used in
IGMP/MLD messages, so not just PIM. Using a bit in the group address
also obviously works for IGMP/MLD.

Do you think we should have some discussion along these lines in the
next mboned meeting? I would be happy to try to present all the
alternatives.

Stig

> Bert
>