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

["Templin (US), Fred L" <[e-mail]>]

Hi Tom,

See below for responses:

Fred

> -----Original Message-----
> From: Tom Herbert [mailto:[e-mail]]
> Sent: Wednesday, August 29, 2018 12:54 PM
> To: Templin (US), Fred L <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Int-area] Document shepherd comments on 'draft-ietf-intarea-gue-05'
> 
> On Fri, Aug 24, 2018 at 12:34 PM, Templin (US), Fred L
> <[e-mail]> 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.

My take is that this would make more sense. Leave the "flags" field
as "reserved" in GUE and then specify it as a flags field an request
an IANA registry  in GUEEXTEN. Then, GUEEXTEN could be published
as an update to GUE.

I am open to hearing other opinions on this.

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

I am OK with ipproto-59. In hindsight, maybe IP fragmentation should have
adopted a similar convention when it was specified so many decades ago.

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

Does GUEEXTEN specify any standard control messages? If so, maybe use
the same strategy for control message IANA considerations similar to what
we discussed for flags above.

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

OK.

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

OK.

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

OK.

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

OK.

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

OK, good.

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

OK.

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

No, the text you quoted already addresses the concern.

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

OK.

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

OK.

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

OK.

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

That would make sense to me, but open to hearing other opinions. I would
like to see GUE published, and then publish GUEEXTEN with an "updates GUE"
designation.

> > _______________________________________________
> > Int-area mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/int-area