IETF Logo Mail Archive

Re: [MBONED] draft-zhou-mboned-multrans-path-optimization

"Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> Fri, 23 March 2012 14:21 UTC

Return-Path: <yiu_lee@cable.comcast.com>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9138421F8455 for <mboned@ietfa.amsl.com>; Fri, 23 Mar 2012 07:21:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.157
X-Spam-Level:
X-Spam-Status: No, score=-101.157 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100]
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 CrefHQKNdaHl for <mboned@ietfa.amsl.com>; Fri, 23 Mar 2012 07:21:35 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id DD6D221F851C for <mboned@ietf.org>; Fri, 23 Mar 2012 07:21:34 -0700 (PDT)
Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.10628162; Fri, 23 Mar 2012 08:08:57 -0600
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 10:21:00 -0400
From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
To: "Zhouqian (Cathy)" <cathy.zhou@huawei.com>, Stig Venaas <stig@venaas.com>
Thread-Topic: [MBONED] draft-zhou-mboned-multrans-path-optimization
Thread-Index: AQHNCQAqLlVcGNXv8kKJcNm+QnEETA==
Date: Fri, 23 Mar 2012 14:20:57 +0000
Message-ID: <CB91FDA4.1E66D%yiu_lee@cable.comcast.com>
In-Reply-To: <A6A061BEE5DDC94A9692D9D81AF776DF1BDBE2F1@szxeml527-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [24.40.55.72]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3415342856_96344"
MIME-Version: 1.0
Cc: "mboned@ietf.org" <mboned@ietf.org>, Ronald Bonica <rbonica@juniper.net>
Subject: Re: [MBONED] draft-zhou-mboned-multrans-path-optimization
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Mar 2012 14:21:35 -0000

Hi Cathy,

Comment inlines:

On 3/23/12 12:09 AM, "Zhouqian (Cathy)" <cathy.zhou@huawei.com> wrote:

>Yes, the v4 stream will be converted to v6 stream.
>What do you mean "back-to-back"? Do you mean the two MTRs are
>back-to-back? The first MTR will convert the v4 stream to v6 stream and
>send the v6 stream to the second MTR, which will just copy it to the v6
>network?

[YL] Yes and I argue this is a rare scenario.

>In addition, this document is not limited to this case, the multi-access
>scenario defined in RFC 4601 is also included.
>Another advantage of this solution is that when IPv4 source transitions
>to IPv6 source, there will be no impact on the MTR.

[YL] I think it would be easier to understand the motivation if you can
include some high-level use cases in the drafts. Then we can compare them
in deployment and see how urgent we need to solve them.

B.R.,
Yiu

>
>Best Regards,
>Cathy ZHOU
>
>
>-----Original Message-----
>From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]
>Sent: Friday, March 23, 2012 11:32 AM
>To: Zhouqian (Cathy); Stig Venaas
>Cc: mboned@ietf.org; Ronald Bonica
>Subject: Re: [MBONED] draft-zhou-mboned-multrans-path-optimization
>
>The whole assumption is the v4 stream has been converted once in the upper
>network. In other words, this optimization only helps in a back-to-back
>MTR. This is really a rare scenario.
>
>
>On 3/22/12 11:16 PM, "Zhouqian (Cathy)" <cathy.zhou@huawei.com> wrote:
>
>>Sorry, I mean the v4 and v6 interface, rather than the source in my last
>>email.
>>Yes, there will be two streams coming from the source. When the two
>>streams coming from v4 and v6 interface separately, MTR will determine
>>whether the two addresses (v4 and v6) have the address format based on
>>draft-ietf-mboned-64-multicast-address-format. If the v6 address is
>>v4-embedded v6 address according to the draft, it means the two streams
>>are the same. If it is not, the two steams are different.
>>Then the two streams will come to different receivers.
>>
>>
>>Best Regards,
>>Cathy ZHOU
>>

v2.23.0 | Report a Bug | By Email