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

Tom Herbert <> Wed, 29 August 2018 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D34C129C6A for <>; Wed, 29 Aug 2018 12:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UW99m3uwZwRb for <>; Wed, 29 Aug 2018 12:54:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0486E12785F for <>; Wed, 29 Aug 2018 12:54:22 -0700 (PDT)
Received: by with SMTP id j7-v6so4207474qkd.13 for <>; Wed, 29 Aug 2018 12:54:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YNTmB/3dVgWK19aQygFOgoSyz/aCL1LEyc96mdfvY6k=; b=uQta2ySngilWvm9wnHGt4fn5aSN6RFl4dkiDJliD8tzvAXSzfWb/tPTMJtMwES6gsT lNYum1YeP83khXiMvmqBdgMwV7fktjIAMj/l01+ldaj1LncVFJy6NLUVnqnAPo0bBdxr NTmflVRIBTyDrRichpllsbug2SchEyaS3DDkkBJPrsV+9U/xfyONtd3yqKJuJdo+spys Ants8d4igHjD8eRrIkofyl+ciMoyxtXyoyio2cRePUlu0C0BjjYIEYhrMcpsWC71SYV6 uyxWovB0ccUqKx+8gV+JPT9uSsyQYxhAlTz/Jj7KCp1JZF2+fdQiEx8tmdirczNDicN+ UaTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YNTmB/3dVgWK19aQygFOgoSyz/aCL1LEyc96mdfvY6k=; b=MEeRJLjC6xxHxY6J7ttYnnXSIa0Yly6ecZ8AuVBJiomm5tCrmaUSitV1BNaBwjbNzz Bj88gasUT2nSQS5Mj8Li5GY4IIQyNx/QfNQNAVPsQ3uWkrMrBZ+8PqW2Aib201nhu0Y+ wkR53D6G+B6d2lF2TCumL0JgxVAUhz6dEseDzPaQHXroiGlS9/ucgoc36XpZ0VyFfCGC a5bfcHpCQ/9Qb0LEC31p9EZIkks+kP4DNn0Md0Az9EQ4H8TyFQNL51KSIS7bspgBP13X OprMGwk3RAyZxWe/p/uBf348AlrNgTnZQ7Bf+YMjBNVYzpeO7HDJUFFktApd7evpDIBB n3pQ==
X-Gm-Message-State: APzg51DmGXf+6Xos5PJmRvyNpa5LEBKL4zf+zhav2R3jAQtuzg6OQXif pO+QFX4wQOlFqJYd/bn0B+3irR2ajdnVA5Liu1I3IA==
X-Google-Smtp-Source: ANB0VdbdwFuImHm2pWsLqfF3GiAqYeyHadGILM6VV0hzJ6zu9y0SGtFL/+UlJEuezpPzuPcTj2VRY+4LevTwrSU9IMA=
X-Received: by 2002:a37:168e:: with SMTP id 14-v6mr8008247qkw.168.1535572461908; Wed, 29 Aug 2018 12:54:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3312:0:0:0:0:0 with HTTP; Wed, 29 Aug 2018 12:54:21 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Tom Herbert <>
Date: Wed, 29 Aug 2018 12:54:21 -0700
Message-ID: <>
To: "Templin (US), Fred L" <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Int-area] Document shepherd comments on 'draft-ietf-intarea-gue-05'
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Aug 2018 19:54:26 -0000

On Fri, Aug 24, 2018 at 12:34 PM, Templin (US), Fred L
<> wrote:
> Hello,
> As document shepherd, I am required to perform a review. Please see below
> for initial comments, and respond on the list.
Hi Fred,

Thanks for shepherd review and comments! Some response inline.


> Fred
> ---
> Overall:
> 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.

The flags field is defined as part of the core GUE header, but the
actual extensions are defined elsewhere. I would like them separate
since that highlights the fact that GUE is exensible. We can move the
IANA request to GUEEXTEN if that makes more sense.

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

Yes. GUE allows a node to skip over the GUE header to inspect the
encapsulated payload, For instance, a firewall may be looking for an
inner IP destination in an encapsulated packet. The GUE payload is
interpreted based on the protocol in the Proto/ctype field. So if the
payload is not a parseable IP protocol (like it would be for a
non-first GUE fragment), then 59 is used to avoid devices trying to
parse it.

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

It's the control message equivalent of IP protocol 59 as discussed
above. The payload is a control message (or at least part of one) but
cannot be parsed with addition context (like a reassembled packet,
after a GUE transform, etc.).

> 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?
The reference to GUEEXTEN is not material and can be removed.

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

> 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'?
Correct, 4 should be used for IPv4 and 41 should be used for IPv6
encapsualtion in examples.

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

Okay, will fix.

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

>From section 5.6.1:

"The selection of whether to make the UDP source port fixed or set to
a flow entropy value for each packet sent SHOULD be configurable for a
tunnel. The default MUST be to set the flow entropy value in the UDP
source port."

Is more clarificaiton needed?

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

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

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

It's not really a placeholder. If means the playload contains a
control message bu requires further context to be interpreted.

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

If it makes sense the IANA request could be moved to GUEEXTEN.

> _______________________________________________
> Int-area mailing list