Re: [dhcwg] [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05

Roni Even <roni.even@huawei.com> Thu, 02 February 2017 06:42 UTC

Return-Path: <roni.even@huawei.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEA3127735; Wed, 1 Feb 2017 22:42:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.419
X-Spam-Level:
X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82R8R46u_R0i; Wed, 1 Feb 2017 22:42:25 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E548127078; Wed, 1 Feb 2017 22:42:24 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFQ60273; Thu, 02 Feb 2017 06:42:20 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 2 Feb 2017 06:42:18 +0000
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by nkgeml411-hub.china.huawei.com (10.98.56.70) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 2 Feb 2017 14:42:14 +0800
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Thu, 2 Feb 2017 14:42:10 +0800
From: Roni Even <roni.even@huawei.com>
To: tianxiang li <peter416733@gmail.com>
Thread-Topic: [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05
Thread-Index: AQHSfKMEGC59Kqb/I0a0hf43svJnhaFVREvg
Date: Thu, 02 Feb 2017 06:42:09 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD771622@DGGEMM506-MBX.china.huawei.com>
References: <148568056700.24536.11691583944564362484.idtracker@ietfa.amsl.com> <CAFx+hEPy0rzAa_QFu4wOBc2hpRqX-5MM0OtZfmuy82Ls7WRmAA@mail.gmail.com> <6E58094ECC8D8344914996DAD28F1CCD770018@DGGEMM506-MBX.china.huawei.com> <CAFx+hEO0x9EVCOgA1YDU7O-1wfRPnsiDzK5GB=MAHSqcir2JMw@mail.gmail.com>
In-Reply-To: <CAFx+hEO0x9EVCOgA1YDU7O-1wfRPnsiDzK5GB=MAHSqcir2JMw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.201.150]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD771622DGGEMM506MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5892D4CD.030D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c1ff7e23a5fb1d24d3ae21aa07c5b874
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/7VKoGM3DajAVwzPcMM7irrcGM7g>
Cc: dhcwg <dhcwg@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, Roni Even <roni.even@mail01.huawei.com>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-dhc-dhcpv6-prefix-length-hint-issue.all@ietf.org" <draft-ietf-dhc-dhcpv6-prefix-length-hint-issue.all@ietf.org>
Subject: Re: [dhcwg] [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2017 06:42:27 -0000

Hi,
I will leave only the items that needed my response

7.      In section 3.4 “If the client decided to use  the prefix provided
by the server despite being longer than the  prefix-length hint” yet I
did not see in section 3.2 that the server can provide a longer
prefix.

[Tianxiang] This was mentioned in the last sentence of section 3.2:

"If the requested prefix is not available in the server's prefix pool, and the client also included a prefix-length hint in the same IA_PD option, then the server SHOULD try to provide a prefix matching the prefix-length value, or the prefix with the shortest length possible which is closest to the prefix-length hint value."
[Roni Even] I understood from 3.2 that it should provide a shorter length prefix  closer to the request maybe “or the prefix with the closest possible length to the prefix-length hint value”

[Tianxiang2] The original sentence was a bit confusing, perhaps we could change it like this:

OLD: "If the requested prefix is not available in the server's prefix pool, and the client also included a prefix-length hint in the same IA_PD option, then the server SHOULD try to provide a prefix matching the prefix-length value, or the prefix with the shortest length possible which is closest to the prefix-length hint value."

NEW:"If the requested prefix is not available in the server's prefix pool, and the client also included a prefix-length hint in the same IA_PD option, then the server SHOULD provide a prefix matching the prefix-length hint, or a prefix which is length is shorter and as close as possible to the prefix-length hint. If the server could not provide a prefix which length is shorter or equal to the prefix-length hint, the server SHOULD provide the prefix which length is longer and as close as possible to the prefix-length hint."

[Roni Even] I have no problem with this text since it will also work with the rest of the document but is it what was really meant

Also a nit

“or a prefix which is length is shorter and as close as possible to the prefix-length hint. If the server could not provide a prefix which length is shorter or equal to the prefix-length hint, the server SHOULD provide the prefix which length is longer and as close as possible to the prefix-length hint”

to

“or a prefix whose length is shorter and as close as possible to the prefix-length hint. If the server could not provide a prefix with a shorter or equal length  to the prefix-length hint, the server SHOULD provide a prefix whose length is longer and as close as possible to the prefix-length hint”


[Tianxiang] The idea was to list all the options, and discuss their consequences. And the server could decide which option to use depending on its policy.

Option 3 avoids the complexity of handling multiple delegated prefixes, despite of breaking up all connections. Option 4 allows to server to configure a valid-lifetime for the old prefix depending on actual requirements, rather than let the old prefix expire on its own.
[Roni Even] OK, still option 4 may have similar result to 3 since “a short non-zero” may be too short. Why not add a recommended value?

[Tianxiang2] Agree, as this may vary for different services, we could change the text to say "a specific valid-lifetime depending on the actual requirement".
[Roni Even] OK




Nits/editorial comments: