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

Jacni Qin <jacni@jacni.com> Wed, 16 May 2012 01:20 UTC

Return-Path: <jacni@jacni.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0221721F86A5; Tue, 15 May 2012 18:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Level:
X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JNWZiMxeHxX; Tue, 15 May 2012 18:20:51 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD9F21F86A4; Tue, 15 May 2012 18:20:51 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 5EC803800E9; Tue, 15 May 2012 21:20:47 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 05162340105; Wed, 16 May 2012 09:20:46 +0800 (CST)
Received: from [10.140.20.37] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJDrH43sALNPt0_1AA--.2450S2; Wed, 16 May 2012 09:20:45 +0800 (CST)
Message-ID: <4FB300E9.60505@jacni.com>
Date: Wed, 16 May 2012 09:20:41 +0800
From: Jacni Qin <jacni@jacni.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
Subject: Re: [MBONED] APPSDIR review of draft-ietf-mboned-64-multicast-address-format-01
References: <CBD6EB81.20E9E%yiu_lee@cable.comcast.com>
In-Reply-To: <CBD6EB81.20E9E%yiu_lee@cable.comcast.com>
Content-Type: multipart/alternative; boundary="------------090903050302090805080501"
X-CM-TRANSID: +AWowJDrH43sALNPt0_1AA--.2450S2
X-Coremail-Antispam: 1UD129KBjvJXoWxWryrZF1UuryUKw1fGryUZFb_yoW5WFW8pa y8Ww4UGr4kGrn3Ca97Jw409rySyFn5G345Ary5G345u3y5Ca4SkryYk3y5ta4DGr90ya1j 9rWj9ryUZF1kA3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnL8YjsxI4VWkKwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0x vEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY 0x0EwIxGrwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0x ZFpf9x07jr4SrUUUUU=
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEKEko7lQ9FBwBLs6
X-Mailman-Approved-At: Tue, 15 May 2012 22:57:02 -0700
Cc: "6man@ietf.org" <6man@ietf.org>, "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>, "draft-ietf-mboned-64-multicast-address-format.all@tools.ietf.org" <draft-ietf-mboned-64-multicast-address-format.all@tools.ietf.org>, Stig Venaas <stig@cisco.com>, The IESG <iesg@ietf.org>, "mboned@ietf.org" <mboned@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 May 2012 01:20:52 -0000

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