On Fri, Aug 24, 2018 at 12:34 PM, Templin (US), Fred L
<fred.l.temp...@boeing.com> 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.
Tom
> 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.
>
Okay.
> 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."
>
Okay.
> 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.
>
Okay.
> 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
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
