[Gen-art] Gen-ART Telechat review of draft-ietf-l2tpext-keyed-ipv6-tunnel-07

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 01 November 2016 02:20 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1752F129B0C for <gen-art@ietfa.amsl.com>; Mon, 31 Oct 2016 19:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 TJv7JacIjqiz for <gen-art@ietfa.amsl.com>; Mon, 31 Oct 2016 19:20:55 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37E4129A48 for <gen-art@ietf.org>; Mon, 31 Oct 2016 19:20:54 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-12v.sys.comcast.net with SMTP id 1OgycOPSwxBKT1Oh4cPVOW; Tue, 01 Nov 2016 02:20:54 +0000
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-19v.sys.comcast.net with SMTP id 1Oh3c6ac3cP8w1Oh3c6oux; Tue, 01 Nov 2016 02:20:53 +0000
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: draft-ietf-l2tpext-keyed-ipv6-tunnel.all@ietf.org
Message-ID: <9ddc9b06-364b-8cf1-ae77-41931b7894b3@alum.mit.edu>
Date: Mon, 31 Oct 2016 22:20:53 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfGJ3gDrfI6UQvlPsODxUA5EM5QAJgVSYeYNbXwmkW43qhXSLb66HQdaj+h2lEC7AnKr/ZvFSI6uX3udgpqymc+3ogufNDq1YObjMfjbXyp8GtXioMwZh do6Fj3h0EIgNgWj6PwnIcRTkzsnyQ7vN4o7TlGn5uZ/CsVkp0Npb8zDBjG6r8UAKCVo6ava5EnI6RedfpPy9FmxHARG/cyzzvWpv1uLkg5QHUYlbqwZlS20V qRIyLh7/svj7t9hx7p2iKA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/rR8sanMIvlYJjhyFph_ii1gA_n0>
Cc: General Area Review Team <gen-art@ietf.org>
Subject: [Gen-art] Gen-ART Telechat review of draft-ietf-l2tpext-keyed-ipv6-tunnel-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Nov 2016 02:20:56 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-l2tpext-keyed-ipv6-tunnel-07
Reviewer: Paul Kyzivat
Review Date: 2016-10-26
IETF LC End Date: 2016-10-28
IESG Telechat date: 2016-11-03

Summary:

This draft is on the right track but has open issues, described in the 
review.

(Note: The draft is unchanged since Last Call, as is this review.)

Issues:

Major: 0
Minor: 3
Nits:  0

(1) MINOR: General comment

As best I can understand, this draft provides a new alternative approach 
tunneling Ethernet over IPv6, that differs from L2TPv3 over IP in two 
key ways:

- it uniquely associates a tunnel with an IPv6 address, simplifying 
routing of arriving packets

- it does not use the L2TPv3 control plane, instead relying upon 
coordinated consistent configuration of the two ends of the tunnel.

As best I can tell, these two choices are independent of one another.

IMO this draft would be improved with a substantial discussion of why 
this new approach to tunneling, using these two features, is being 
offered as an alternative. This is mentioned very slightly in Section 1, 
but seems incomplete. What are the cons as well as the pros, and under 
what circumstances will the pros outweigh the cons?

(2) MINOR: Section 3:

There is no explanation of why 64-bit cookies are chosen and required. 
Is this because there is no mechanism for negotiation, so a fixed size 
is needed to define the packet format? Since coordinated configuration 
of the two ends is required wouldn't it be possible to allow the 
consistent configuration of the cookie size? Better explanation would be 
helpful.

(3) MINOR: Section 5:

The 2nd paragraph uses "recommended" (non-normative) while the 
subsequent paragraphs used "RECOMMENDED" (normative). Is this intentional?