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

"Carlos Pignataro (cpignata)" <> Tue, 01 November 2016 13:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DE321296F0; Tue, 1 Nov 2016 06:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9EC7X8SxLuU0; Tue, 1 Nov 2016 06:44:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0BDD12968B; Tue, 1 Nov 2016 06:44:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3580; q=dns/txt; s=iport; t=1478007894; x=1479217494; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=spbLeltr96SQKVhUmdMO4jDLbHAjG3z1JuRbV2koYBs=; b=Pvo54KlVDVhmDupS8GdEtc5y3lDvzIUEHsujbxhSasukv3vZ8GqO5rr7 7GnOxZ1DJGu1CtmzhpcHxlRoS6idJR0M8igjozMv7kC38fXGslzx59rMi TdIYsCQ+CWqTzkrDMQWKlFf3Ey1lHUb+h3zk0n8pAPZzql9oNxjMbymh9 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,579,1473120000"; d="scan'208";a="342657917"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2016 13:44:53 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id uA1DiqP8024627 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Nov 2016 13:44:53 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Nov 2016 09:44:52 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Tue, 1 Nov 2016 09:44:52 -0400
From: "Carlos Pignataro (cpignata)" <>
To: Paul Kyzivat <>
Thread-Topic: [Gen-art] Gen-ART Telechat review of draft-ietf-l2tpext-keyed-ipv6-tunnel-07
Thread-Index: AQHSM+aVpEDRmlv/EEKYZKc/WwfHZKDEZ32A
Date: Tue, 01 Nov 2016 13:44:52 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: General Area Review Team <>, "" <>
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-l2tpext-keyed-ipv6-tunnel-07
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Nov 2016 13:44:55 -0000

Thanks for the review, Paul!


Please find some comments inline.

Carlos, as shepherd.

> On Oct 31, 2016, at 10:20 PM, Paul Kyzivat <> wrote:
> 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 <​>.
> 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?

I agree with this. Some text explaining when you would prefer this approach, and when not, would help.

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

This is related to Mirja’s comment as well, and some clarity will improve the doc.

> (3) MINOR: Section 5:
> The 2nd paragraph uses "recommended" (non-normative) while the subsequent paragraphs used "RECOMMENDED" (normative). Is this intentional?


— Carlos.