Re: [Mip4] Fw: Recharter: Ethernet Service Support

Qin Wu <sunseawq@huawei.com> Tue, 19 May 2009 02:09 UTC

Return-Path: <sunseawq@huawei.com>
X-Original-To: mip4@core3.amsl.com
Delivered-To: mip4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7D13A708E for <mip4@core3.amsl.com>; Mon, 18 May 2009 19:09:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.231
X-Spam-Level:
X-Spam-Status: No, score=0.231 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOjzfJE9VZ8v for <mip4@core3.amsl.com>; Mon, 18 May 2009 19:09:14 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 9A94C28C1C3 for <mip4@ietf.org>; Mon, 18 May 2009 19:09:14 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJV00623CPR7I@szxga01-in.huawei.com> for mip4@ietf.org; Tue, 19 May 2009 10:10:40 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJV00GOPCPRUQ@szxga01-in.huawei.com> for mip4@ietf.org; Tue, 19 May 2009 10:10:39 +0800 (CST)
Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJV005DSCPOQ7@szxml04-in.huawei.com> for mip4@ietf.org; Tue, 19 May 2009 10:10:39 +0800 (CST)
Date: Tue, 19 May 2009 10:10:35 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Christian Makaya <cmakaya@research.telcordia.com>, mip4@ietf.org
Message-id: <033901c9d826$ff374960$260ca40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <005f01c9cde7$000cfb40$260ca40a@china.huawei.com> <4A11862A.6090106@research.telcordia.com>
Cc: Shahriar Rahman <rahman@redback.com>, 'Hui Deng' <denghui@chinamobile.com>
Subject: Re: [Mip4] Fw: Recharter: Ethernet Service Support
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mip4>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2009 02:09:15 -0000

Hi, Christian:
Thank for your feedback. Just let you know, we have already updated the version 2. 
As regarding your comments, please see my reply below.

> Below, you'll find some comments based on my review of your I-D  
> draft-wu-mip4-ether-01.txt:
> 
> Introduction:
> 
> Remove the r:  "The capability .......service providers to _provide_ IP 
> services ..."

[Qin]: Right,  there appears to be a typo here, thanks you for pointing out this.

> Third bullet: ISP-head _and_ to enable
> 
> Last paragraph:  "... home address assignment _policies_ and tunnel ... 
> can be operated _in_ parallel to ..."

[Qin]: Right, good catch.

> Terminology:
> 
> GRE Extension: check: _to differentiate between *difference* Ethernet_ 
> ... Not clear what you mean.

[Qin]: I actually said GRE extension can be used to differentiate between different Ethernet service based on GRE keys.
Here is a nits, thank you for pointing out this.

> Section 3.3
> 
> VLAN tags process in _both direction_ towards ...

[Qin]: It is okay with me, I can change bidirection into both direction.
 
> Section 4.2
> " ... the communication between the MN and the home agent needs to be 
> modified to support Ethernet frame network..." This statement maybe 
> difficult  in order to sell your proposal.
[Qin] You are right. We could add some text to say:
"
In order to support Ethernet service delivery in mobile IPv4
scenario, the communication between the MN and the home agent needs
to be modified to setup binding between MN's MAC address and FA CoA.
"
What do you think of it?

> I do not understand what do you mean by: "host behind the MN" is  it a 
> router/IP node? MN is one of the end-point of communication path. Which 
> node/host is behind MN?

[Qin]: What I mean here is in multi-host support scenario(please see the section 3.4 of this draft), there are multiple mobile devices connected to the bridge behind Mobile Router. The mobile router contains a bridge forwarding to the mobile devices behind the MR. The traffic sent from the mobile device should be forwarded by the Mobile Router to the Ethernet sevice provider. In this scenario, the MN is the mobile router and not a end point of communication path. The mobile device behind the mobile router is the real end point of communication path.

> Section 6.2
> _to differentiate between *difference* Ethernet_ services or flows... 
> Not clear what you mean.

[Qin]: It is a typo, the difference should be changed into different, thank you for correcting me.

> Last sentence: "... Wu Expires ....", formatting issue, need to check.
> 
> Section 7.2
> 
> Home Agent Operatio_*n

> *_Best regards,
> Christian_*
> *_