Re: [OPSAWG] TSV ART IETF LC review of draft-ietf-opsawg-capwap-alt-tunnel

Duzongpeng <duzongpeng@huawei.com> Tue, 18 October 2016 07:49 UTC

Return-Path: <duzongpeng@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337A3129597; Tue, 18 Oct 2016 00:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Level:
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, 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 YZbV-N7vc9uV; Tue, 18 Oct 2016 00:49:45 -0700 (PDT)
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 C653812959C; Tue, 18 Oct 2016 00:49:43 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTJ20373; Tue, 18 Oct 2016 07:49:40 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 18 Oct 2016 08:48:39 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 18 Oct 2016 15:48:32 +0800
From: Duzongpeng <duzongpeng@huawei.com>
To: Joe Touch <touch@isi.edu>
Thread-Topic: [OPSAWG] TSV ART IETF LC review of draft-ietf-opsawg-capwap-alt-tunnel
Thread-Index: AQHSGD4DWumMsag3LEKPYa8luKqN4qCLxZmAgAsD84CAFyEiIA==
Date: Tue, 18 Oct 2016 07:48:32 +0000
Message-ID: <BAFEC9523F57BC48A51C20226A5589575FE5BA6D@nkgeml514-mbx.china.huawei.com>
References: <78f07b6d-3c78-e002-b2f5-487da9c8be72@isi.edu> <a9f05461-f117-afa5-fe6d-886efdc2aab0@isi.edu> <CAHw9_iJunvqAiXWipLWD5kAnA3JjKR6BFoj1efY4CU3FS0VLAA@mail.gmail.com>
In-Reply-To: <CAHw9_iJunvqAiXWipLWD5kAnA3JjKR6BFoj1efY4CU3FS0VLAA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.149.226]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5805D415.001C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 13d103779c9ef6ea9811da5ae04ee68e
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/1jcMg6qy32atis9C6QL9nPmlpqA>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, "draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org" <draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org>
Subject: Re: [OPSAWG] TSV ART IETF LC review of draft-ietf-opsawg-capwap-alt-tunnel
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2016 07:49:48 -0000

Hello, Joe

	Although not as an author of the draft, I would like to talk about your suggestions.

	Please see inline. 

Best Regards
Zongpeng Du

> Major issues:
>
> As already noted in draft-intarea-tunnels, many existing tunnel 
> mechanisms are inconsistent or incorrect in their support for IPv6 MTU 
> requirements, both as transits for IP packets and as IP endpoints. 
> Although this document cites existing standards, the inconsistency and 
> incorrectness of these standards should be addressed. It might be 
> sufficient to indicate that any tunneling mechanism selected MUST 
> support the minimum IPv6 MTU requirements independent of this 
> signalling mechanism (i.e, the signalling mechanism doesn't address or 
> correct any errors or inconsistencies in the tunnel mechanism selected).
>
[duzongpeng] 
Would it ok if the authors add a section to declare that every tunneling mechanism 
MUST support the minimum IPv6 MTU requirements said in "draft-ietf-intarea-tunnels-03"

If the draft, the tunnel between the WTP and Access Router needs to be established, and the WTP and AC already have a CAPWAP connection.
According to the tunneling mechanism supported, MTU information perhaps can be computed by the AR.
AC can have the information, and inform the WTP in the "Tunnel Info Element" field. 
[duzongpeng]


> Regarding IP endpoint requirements, it might be useful to consider 
> whether this protocol could be extended to indicate the receiver 
> payload reassembly limit when indicating support for each tunnel type, 
> to assist the source in determining whether the resulting tunnel will 
> be IPv6 compliant (rather than becoming a black hole for valid packet sizes).
>

[duzongpeng] 
Is it the same information talked above? 
I think it is flexible to indicate something in the "Tunnel Info Element" field.
If you can provide detailed modification suggestions, perhaps the author will be glad to accept it.
BTW, I have also given some suggestions to the draft.
[duzongpeng]

> Additionally, for the transport protocol-based tunnels, it would be 
> useful to consider whether the protocol could indicate not only the 
> endpoint IP address but the port number as well.
>

[duzongpeng] 
If any tunnel type needs this port information, it should be ok to carry it in the "Tunnel Info Element" field.
[duzongpeng]

> Minor issues:
>
> It might be useful to consider IPsec TLS, and DTLS tunnels as well as 
> those already listed.

[duzongpeng] 
According to my understanding, it is ok to add some tunnel types. 
However, the authors have decided to only talk some essential ones in this draft, and perhaps talk about others in latter drafts if necessary.
[duzongpeng]


-----Original Message-----
From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari
Sent: Tuesday, October 04, 2016 5:50 AM
To: Joe Touch
Cc: opsawg@ietf.org; draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org
Subject: Re: [OPSAWG] TSV ART IETF LC review of draft-ietf-opsawg-capwap-alt-tunnel

[ - Discuss, tsv-art (first for clutter, second because I'm not subscribed) ] Dear authors,

I just wanted to make sure that you had seen these are well...

W

On Mon, Sep 26, 2016 at 5:36 PM, Joe Touch <touch@isi.edu> wrote:
> CC'ing tsv-art...
>
>
> On 9/26/2016 2:34 PM, Joe Touch wrote:
>
> Hi, all,
>
> I've reviewed this document as part of the Transport Area Review 
> Team's
> (TSVART) ongoing effort to review key IETF documents. These comments 
> were written primarily for the transport area directors, but are 
> copied to the document's authors for their information and to allow 
> them to address any issues raised. When done at the time of IETF Last 
> Call, the authors should consider this review together with any other 
> last-call comments they receive. Please always CC tsv-art@ietf.org if 
> you reply to or forward this review.
>
> Please resolve these comments along with any other Last Call comments 
> you may receive. Please wait for direction from your document shepherd 
> or AD before posting a new version of the draft.
>
> Document: draft-ietf-opsawg-capwap-alt-tunnel
> Title: Alternate Tunnel Encapsulation for Data Frames in CAPWAP
> Reviewer: J. Touch
> Review Date: Sept 26, 2016
> IETF Last Call Date: Sept 16, 2016
>
> Summary: This doc refers to existing tunneling specifications, many of 
> which are inconsistent or incorrect. In particular, there are 
> potential complicatinos with MTU support and signalling that could 
> affect transport protocols.
>
> Major issues:
>
> As already noted in draft-intarea-tunnels, many existing tunnel 
> mechanisms are inconsistent or incorrect in their support for IPv6 MTU 
> requirements, both as transits for IP packets and as IP endpoints. 
> Although this document cites existing standards, the inconsistency and 
> incorrectness of these standards should be addressed. It might be 
> sufficient to indicate that any tunneling mechanism selected MUST 
> support the minimum IPv6 MTU requirements independent of this 
> signalling mechanism (i.e, the signalling mechanism doesn't address or 
> correct any errors or inconsistencies in the tunnel mechanism selected).
>
> Regarding IP endpoint requirements, it might be useful to consider 
> whether this protocol could be extended to indicate the receiver 
> payload reassembly limit when indicating support for each tunnel type, 
> to assist the source in determining whether the resulting tunnel will 
> be IPv6 compliant (rather than becoming a black hole for valid packet sizes).
>
> Additionally, for the transport protocol-based tunnels, it would be 
> useful to consider whether the protocol could indicate not only the 
> endpoint IP address but the port number as well.
>
> Minor issues:
>
> It might be useful to consider IPsec TLS, and DTLS tunnels as well as 
> those already listed.
>
> ---
>
>



--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg