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

Joe Touch <touch@isi.edu> Mon, 26 September 2016 21:37 UTC

Subject: Re: TSV ART IETF LC review of draft-ietf-opsawg-capwap-alt-tunnel
To: IETF discussion list <ietf@ietf.org>
References: <78f07b6d-3c78-e002-b2f5-487da9c8be72@isi.edu>
From: Joe Touch <touch@isi.edu>
Message-ID: <a9f05461-f117-afa5-fe6d-886efdc2aab0@isi.edu>
Date: Mon, 26 Sep 2016 14:36:53 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <78f07b6d-3c78-e002-b2f5-487da9c8be72@isi.edu>
Content-Type: multipart/alternative; boundary="------------2C0FBB8EE7C0EE6B6A05558A"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/2DWgaBAFHo4pHdrWpGnRK3Q_tSw>
Cc: "tsv-art@ietf.org" <tsv-art@ietf.org>, opsawg@ietf.org, draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org
Precedence: list

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 <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.
>
> ---

TSV ART IETF LC review of draft-ietf-opsawg-capwa… Joe Touch
Re: TSV ART IETF LC review of draft-ietf-opsawg-c… Joe Touch