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

[Stig Venaas <[e-mail]>]

Hi, a few comments here on the responses below.

On 7/1/2012 1:58 AM, Nagendra Kumar (naikumar) wrote:
> Hi Tina,
>
> Thanks for your thoughts. For 6-4-6 scenarios, I think it may not require to signal if or not v4 address is embedded as IPv4 cloud will be transit here. I guess Tunneling, AMT or MVPN kind of solution might be apt here.
>
> Regarding the attribute in IPv4 only network, even if there is a requirement to transparently transfer attribute via v4 cloud, per my understanding, it still can be done by setting the F bit. So just the ingress and egress devices are required to understand the content of attribute.

Just one thought here. I'm not aware of scenarios where we need to mark
an IPv4 address now (to somehow get some particular behavior for
transition), but I want to point out that the technique of using PIM
join attributes (or IGMP aux data) as specified in this draft, could
in theory be used for some kind of marking of IPv4 groups too. While
we of course never could reserve a bit in the IPv4 address. I can't
think of any uses right now though.

More below.

> Regards,
> Nagendra
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Tina TSOU
> Sent: Saturday, June 30, 2012 7:11 AM
> To: Manfredi, Albert E; Stig Venaas
> Cc: [e-mail]
> Subject: Re: [MBONED] An alternative to draft-ietf-mboned-64-multicast-address-format?
>
> The fixed 96 bits and then 32 bits of the IPv4 address is a simpler and better approach according to me, as described in http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02. However, this http://tools.ietf.org/html/draft-kumar-mboned-64mcast-embedded-address-00 document has its advantages of 6-4-6-4 scenario which is missing in the alternative document. The only point I would like to stress upon is if it covers the scenario of 6-4-6, as IPv6 multicast address expressed in terms of IPv4 is something I didn't find in the document. I am only concerned about the validity of the attributes in an IPv4 only multicast network. Would tunnels be used to route the IPv6 packets with the end routers being dual stack?

I think we're all talking about that last 32 bits being the IPv4 address
at least. Right? The only question is how a router (and maybe other
entities) can know that a particular IPv6 group address has an IPv4
address in the last 32 bits.

It can be done by a reserved well-known prefix, or a reserved flag.
Or it can be a non-defined prefix where devices need to be configured
or dynamically learn which prefixes are used. Or it can be some marking
in a PIM join or other places where the group address is used, without
putting it in the group address itself. As in this latest draft.

Stig

> Tina
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Manfredi, Albert E
>> Sent: Friday, June 29, 2012 12:35 PM
>> To: Stig Venaas
>> Cc: [e-mail]
>> Subject: Re: [MBONED] An alternative to
>> draft-ietf-mboned-64-multicast- address-format?
>>
>>> -----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.
>>
>> 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?
>>
>> Bert
>>
>> _______________________________________________
>> MBONED mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mboned
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned
>