[Int-area] Document shepherd comments on 'draft-ietf-intarea-gue-05'

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 24 August 2018 19:34 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C6B33130EA7 for <int-area@ietfa.amsl.com>; Fri, 24 Aug 2018 12:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9biYyUwKcTPy for <int-area@ietfa.amsl.com>; Fri, 24 Aug 2018 12:34:33 -0700 (PDT)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net []) (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 CAE66130E6C for <Int-area@ietf.org>; Fri, 24 Aug 2018 12:34:33 -0700 (PDT)
Received: from localhost (localhost []) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w7OJYWCx012341; Fri, 24 Aug 2018 12:34:32 -0700
Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com []) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w7OJYQAw011925 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for <Int-area@ietf.org>; Fri, 24 Aug 2018 12:34:26 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 24 Aug 2018 12:34:25 -0700
Received: from XCH15-06-08.nw.nos.boeing.com ([]) by XCH15-06-08.nw.nos.boeing.com ([]) with mapi id 15.00.1367.000; Fri, 24 Aug 2018 12:34:25 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "Int-area@ietf.org" <Int-area@ietf.org>
Thread-Topic: Document shepherd comments on 'draft-ietf-intarea-gue-05'
Thread-Index: AdQ74GGlBhDKZ+KvR+CDcH9IBFNaLQ==
Date: Fri, 24 Aug 2018 19:34:25 +0000
Message-ID: <f1cf017dec464a8c8d2cd0dc3e6d60db@XCH15-06-08.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-tm-snts-smtp: CDA77607E8F1CD54E92E4864A96F1E393E0F4B4A2A0E5C142705F35930BF422C2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/tbewCD48zZMK35FcEr1COdeq1mA>
Subject: [Int-area] Document shepherd comments on 'draft-ietf-intarea-gue-05'
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Aug 2018 19:34:48 -0000


As document shepherd, I am required to perform a review. Please see below
for initial comments, and respond on the list.




The document is well written and clear. The only thing I wonder is whether this
document needs to be progressed in conjunction with GUEEXTEN or whether it
can go forward independently. In particular, this draft defines a flags registry
under IANA Considerations but with no initial assignments. Instead, initial
assignments are assumed to be requested in GUEEXTEN. TBD is whether the
two documents can be progressed together.

Section by Section comments:

Section 3.2.1:
Final paragraph beginning: "IP protocol number 59 ("No next header") can be set
to indicate that the GUE payload does not begin with the header of an IP protocol."
The example given was GUE fragmentation, but would that not represent a
departure from the way things are done for IP fragmentation? I believe in
IP fragmentation the protocol field contains the same value for both initial
and non-initial fragments. Is there a reason for the departure here?

Section 3.2.2:
Final sentence: "This document does not specify any standard control message
types other than type 0." If this document defines type 0, then the format and
use of that message type should be specified here. Also, IANA considerations
simply says: "Need Further Interpretation" - I think that interpretation should
appear in this document.

Section 3.3:
The use of "flags" and "paired flags" is discussed but with no actual flags
assignments appearing in this document. Instead, it quotes from "GUEEXTEN".
Is that OK?

Section 4:
Misspelled "varinant". Check rest of document for spelling.

Section 5:
Final sentence of first paragraph, suggest changing: "Packet flow in the reverse
direction need not be symmetric; GUE encapsulation is not required in the
reverse path." to: "Packet flow in the reverse direction need not be symmetric;
for example, the reverse path might not use GUE and/or any other form of

Section 5.4:
The sentence "No error message is returned back to the encapsulator." Suggest
removing this sentence and remain silent. Reason is that future variants may
well indicate the use of some form of error messaging.

Section 5.4.1:
Second paragraph, "set 94 for IPIP", I was under the impression that the common
values for IPIP encapsulation are '4' for IPv4 and '41' for IPv6. I have not seen '94'
appear elsewhere. Is this a common use? If not, would it be better to use '4' or '41'?

Section 5.5:
The sentence including: "there are no provisions to automatically GUE copy flags"
appears to have a wording issue that I could not parse.

Section 5.11:
Is "flow entropy" mandatory or optional? For example, shouldn't it be OK for the 
encapsulator to set the UDP source port to anything of its own choosing if it does
not want to get involved with flow entropy determination?

Section 6.2:
"Generic UDP Encapsulation for IP Tunneling (GRE over UDP)" - the correct title
of this RFC is "GRE-in-UDP Encapsulation".

Section 6.2:
"Generic UDP tunneling [GUT]" expired in 2010. Can we either drop this or refer
to it in the past tense?

Section 8.3:
Control type 0 defined as: "Need further interpretation". I think this document
should say what type 0 is instead of just requesting a "placeholder".

Section 8.4:
It seems unusual that this document requests a registry with no initial assignments.