Re: [MEXT] draft-xia-mext-hioptv4-01 and draft-ietf-mip6-hiopt-17 comments

xiayangsong <xiayangsong@huawei.com> Thu, 17 March 2011 23:12 UTC

Return-Path: <xiayangsong@huawei.com>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C673A6B3E for <mext@core3.amsl.com>; Thu, 17 Mar 2011 16:12:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 A+KVekigtEmW for <mext@core3.amsl.com>; Thu, 17 Mar 2011 16:12:01 -0700 (PDT)
Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 39DFB3A69B3 for <mext@ietf.org>; Thu, 17 Mar 2011 16:12:01 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI80056H5UGZY@usaga02-in.huawei.com> for mext@ietf.org; Thu, 17 Mar 2011 16:13:28 -0700 (PDT)
Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LI800J3J5UGVQ@usaga02-in.huawei.com> for mext@ietf.org; Thu, 17 Mar 2011 16:13:28 -0700 (PDT)
Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 17 Mar 2011 16:13:22 -0700
Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.47]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 17 Mar 2011 16:13:27 -0700
Date: Thu, 17 Mar 2011 23:13:26 +0000
From: xiayangsong <xiayangsong@huawei.com>
In-reply-to: <4D8283DF.7030702@gmail.com>
X-Originating-IP: [10.193.34.133]
To: Tomasz Mrugalski <tomasz.mrugalski@gmail.com>, MEXT WG <mext@ietf.org>
Message-id: <CB60645E6241144CB82269604373757AE6D72F@dfweml503-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US
Thread-topic: [MEXT] draft-xia-mext-hioptv4-01 and draft-ietf-mip6-hiopt-17 comments
Thread-index: AQHL5O5q1r6E+qfhYkOyka41ouyFsJQyImzg
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <4D8283DF.7030702@gmail.com>
Cc: Behcet Sarikaya <behcetsarikaya@yahoo.com>
Subject: Re: [MEXT] draft-xia-mext-hioptv4-01 and draft-ietf-mip6-hiopt-17 comments
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Mar 2011 23:12:02 -0000

Hi Tomek

Thank you for reviewing the document.

Please see my inline comments...

BR
Frank

-----Original Message-----
From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Tomasz Mrugalski
Sent: Thursday, March 17, 2011 2:58 PM
To: MEXT WG
Cc: Behcet Sarikaya
Subject: [MEXT] draft-xia-mext-hioptv4-01 and draft-ietf-mip6-hiopt-17 comments

Dear MEXT WG,
Behcet asked me to review draft-xia-mext-hioptv4-01.txt. It refers to
draft-ietf-mip6-hiopt-17.txt, so I'd like to briefly comment on both of
them.

Disclaimer: I'm not involved in MEXT activity (nor do I intend to). I'm
quite familiar with DHCPv6 and to some extent DHCPv4 protocols, so my
comments are related to those aspects.

draft-ietf-mip6-hiopt-17:
MIP6 Relay Agent Option defined in Section 3.2 of
draft-ietf-mip6-hiopt-17 is specific to one option only. On the other
hand Ted's RSOO proposal is generic and can be applied to any options.
This make RSOO better approach. I strongly suggest to modify Section 3.2
of draft-ietf-mip6-hiopt-17 to reference RSOO draft, rather than define
its own dedicated option.

draft-xia-mext-hioptv4-01:
In Section 1 you enumerate all IPv4-IPv6 permutations, without any
justification why they are actually needed. What's the use case there?
My understanding is that there is Dual Stack mobile node. Is it supposed
to do DHCPv4 only? Why? If client visits network that is IPv4 only, how
is it supposed to do MIPv6?
Frank=>This is all about Dual Stack MIPv6.  There is one scenario that a IPv4 only mobile node needs to discover a home agent address through DHCPv4 protocol.
According to specification of DSMIPv6, the home address needs both an IPv4
and IPv6 address.
 

If you have dual stack mobile node, it should run both DHCPv4 and DHCPv6
clients, each configuring its own protocol family.
Frank=>DSMIPv6 mobile node does not necessarily support both IPv4 and IPv6,
or DHCPv4 and DHCPv6.


I think Ted's major objection was Section 4.2, where DSMIPv6 Relay
Agent Option is defined. Why do you need this option for? What options
is it supposed to carry? Are you expecting it to convey DHCPv6 options,
as defined in mip6-hiopt-17? That would be wrong on many levels. You
would encapsulate DHCPv6 suboptions into DHCPv4 options. DHCPv4 clients
typically don't have parsing capabilities of DHCPv6 option formats.
Frank=>Just I explained aforementioned, we need define DHCPv4 option for
carrying home agents information(such as IPv6 addresses). We can't encapsulate
DHCPv6 suboptions into DHCPv4 options because the client is DHCPv4 only.

At current form, this draft is unclear at best. Who is including
OPTION_DSMIP6_RELAY option? Relay?
Frank=>Access routers as DHCP relay and DHCPv4 servers includes the option.

My generic recommendation is that authors should should start with:
- explaining why you need this instead of using DHCPv4 for IPv4
  configuration and DHCPv6 for IPv6 configuration.
- redesigning those option to not requiring conveying DHCPv6 options in
  DHCPv4.
- explain your use case and the rationale behind it.
Frank=>Thank your recommendation,  and we will update this draft accordingly.

References:
RSOO draft:
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-relay-supplied-options/

Please keep me on cc: as I'm not subscribed to mext mailing list.

-- 
Tomek
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext