Re: [MBONED] APPSDIR review of draft-ietf-mboned-64-multicast-address-format-01

Re-,

On 5/15/2012 Tuesday 5:06 AM, Lee, Yiu wrote:
> Hi Stig,
>
> Right. I explain only one use case. Other may find the latter case is more
> attractive for their deployments. This address format should enable the
> dynamic use case as well.
Yes, imaging the coexistence of the native provisioning and the embedded 
address for some transition approach deployment, to perform that 
statelessly, a flag bit is efficient.


Cheers,
Jacni

> Yiu
>
> On 5/14/12 4:56 PM, "Stig Venaas"<stig@cisco.com>  wrote:
>
>> On 5/14/2012 1:50 PM, Lee, Yiu wrote:
>>> Hi Brian,
>>>
>>> Sorry for getting back late. I read Bert's answers to your questions.
>>> His
>>> answers are inline with my answers. Most information are statically
>>> configured. For example: Ch1 is statically configured to 224.1.2.3 via
>>> OOB
>>> mechanism. If the STB is IPv4 only, it will only use IPv4 mcast address.
>>> It won't use the address format defined in this draft. In my mind, the
>>> most common deployment will use the same IPv6 prefix which will be
>>> statically configured in the AF.
>> Right, so that was my main concern with the draft. Is static
>> configuration like this sufficient, or are there more generic cases
>> where one needs to know that it is translated from IPv4 without a
>> priori configuration. The flag bit (or a well-known prefix) is only
>> needed in the latter case. I know there were some scenarios where
>> someone found the latter to be advantageous though.
>>
>> Stig
>>
>>> Regards,
>>> Yiu
>>>
>>>
>>> On 5/10/12 2:03 PM, "Brian Haberman"<brian@innovationslab.net>   wrote:
>>>
>>>> Hi Yiu,
>>>>        Let me ask a few questions...
>>>>
>>>> On 5/9/12 10:52 PM, Lee, Yiu wrote:
>>>>> Hi Carsten,
>>>>>
>>>>> Thanks very much for reviewing the document. I just want to add a
>>>>> point
>>>>> to
>>>>> your question about how applications decide when to use this multicast
>>>>> address format. In fact, they don't. Imagine a use case where a legacy
>>>>> IPv4 IP-TV receiver (an app) wants to join a channel which is
>>>>> broadcasted
>>>>> in IPv6. The app will continue to send the igmp-join (say 224.1.2.3).
>>>> How does the IPv4 IP-TV know to join 224.1.2.3?
>>>>
>>>> How is 224.1.2.3 advertised to the IPv4 IP-TV clients if the content is
>>>> generated by an IPv6 source?  Does the source need to be configured to
>>>> use one of these IPv4-in-IPv6 multicast addresses?
>>>>
>>>>> There will be a function in the network which is statically configured
>>>>> that when it receives a igmp-join, it would covert to a corresponding
>>>>> mld-join. The IPv6 address in the join message will follow what is
>>>>> described in this draft. This Adaptive Function is transparent to the
>>>>> application and managed by the network.
>>>> Are you limiting this approach to only mapping at the IGMP/MLD
>>>> protocols?
>>>>
>>>> How does your Adaptive Function know which IPv6 multicast prefix to use
>>>> when mapping the IPv4 multicast address in the IGMP Report message to
>>>> MLD?
>>>>
>>>> Regards,
>>>> Brian
>>
>>
>> _______________________________________________
>> MBONED mailing list
>> MBONED@ietf.org
>> https://www.ietf.org/mailman/listinfo/mboned