Skip to main content

Last Call Review of draft-ietf-l2tpext-keyed-ipv6-tunnel-07
review-ietf-l2tpext-keyed-ipv6-tunnel-07-genart-lc-kyzivat-2016-11-01-00

Request Review of draft-ietf-l2tpext-keyed-ipv6-tunnel
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-11-01
Requested 2016-10-27
Authors Maciek Konstantynowicz , Giles Heron , Rainer Schatzmayr , Wim Henderickx
I-D last updated 2016-11-01
Completed reviews Genart Last Call review of -07 by Paul Kyzivat
Genart Last Call review of -07 by Paul Kyzivat
Secdir Last Call review of -07 by David Waltermire
Rtgdir Early review of -05 by Sasha Vainshtein (diff)
Assignment Reviewer Paul Kyzivat
State Completed
Request Last Call review on draft-ietf-l2tpext-keyed-ipv6-tunnel by General Area Review Team (Gen-ART) Assigned
Reviewed revision 07
Result Ready w/issues
Completed 2016-11-01
review-ietf-l2tpext-keyed-ipv6-tunnel-07-genart-lc-kyzivat-2016-11-01-00
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?