TSV ART IETF LC review of draft-ietf-opsawg-capwap-alt-tunnel
Joe Touch <touch@isi.edu> Mon, 26 September 2016 21:35 UTC
Return-Path: <touch@isi.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78E112B34B; Mon, 26 Sep 2016 14:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.215
X-Spam-Level:
X-Spam-Status: No, score=-9.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316] 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 GF7GAArXfsIm; Mon, 26 Sep 2016 14:35:42 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F6912B0A1; Mon, 26 Sep 2016 14:35:39 -0700 (PDT)
Received: from [128.9.184.244] ([128.9.184.244]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u8QLYIWg001358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Sep 2016 14:34:19 -0700 (PDT)
To: IETF discussion list <ietf@ietf.org>
From: Joe Touch <touch@isi.edu>
Subject: TSV ART IETF LC review of draft-ietf-opsawg-capwap-alt-tunnel
Message-ID: <78f07b6d-3c78-e002-b2f5-487da9c8be72@isi.edu>
Date: Mon, 26 Sep 2016 14:34:19 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------6A057C615796B37D2FE0AB44"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/vqKCAXOaxk-tlPuKVCaKsIqD6aY>
Cc: opsawg@ietf.org, draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2016 21:35:45 -0000
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 <mailto: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. ---