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

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 24 Aug 2018 19:34:25 +0000

Hello,

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

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.

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

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.

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Aug 2018 08:24:10 -0700

Some comments below, hopefully constructive/additive... 

Joe

On 2018-08-24 12:34, Templin (US), Fred L wrote:

> ...
> ...

94 is defined here:  

   [IDM91a] Ioannidis, J., Duchamp, D., Maguire, G., "IP-based
            protocols for mobile internetworking", Proceedings of
            SIGCOMM '91, ACM, September 1991.

See RFC 1853 for a list of other "non-4" and "non-6" IP tunnels, but
these are not IP-in-IP -- that should cite RFC2003 (though, as noted in
draft-ietf-tunnels, there are some issues with the details in that RFC).

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Aug 2018 08:47:59 -0700

On Tue, Aug 28, 2018 at 8:24 AM, Joe Touch <[email-masked]> wrote:
> See RFC 1853 for a list of other "non-4" and "non-6" IP tunnels, but these
> are not IP-in-IP -- that should cite RFC2003 (though, as noted in

I think it's probably better to use 4 and show the example as IPv4/IP
encapsulation since that's probably more common.

Thanks,
Tom

>
> Joe
>
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Aug 2018 08:50:37 -0700

Tom, 

Agreed, but I was suggesting both 4-in-4 and 6-in-6. It's not useful to
discuss 94 in this context. 

Joe

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 Aug 2018 12:54:21 -0700

> for initial comments, and respond on the list.
Hi Fred,

Thanks for shepherd review and comments! Some response inline.

Tom

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

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

> simply says: "Need Further Interpretation" - I think that interpretation should

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

> assignments appearing in this document. Instead, it quotes from "GUEEXTEN".
The reference to GUEEXTEN is not material and can be removed.

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

> for example, the reverse path might not use GUE and/or any other form of
Okay.

> well indicate the use of some form of error messaging.
Okay.

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

> appears to have a wording issue that I could not parse.

Okay, will fix.

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

> of this RFC is "GRE-in-UDP Encapsulation".
Okay, will fix.

> "Generic UDP tunneling [GUT]" expired in 2010. Can we either drop this or refer
Okay, can delete it.

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

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 30 Aug 2018 15:29:45 +0000

Hi Tom,

See below for responses:

Fred

> -----Original Message-----
> From: Tom Herbert [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2018 12:54 PM
> To: Templin (US), Fred L <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Int-area] Document shepherd comments on 'draft-ietf-intarea-gue-05'
> 

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.

> non-first GUE fragment), then 59 is used to avoid devices trying to

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.

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

> The reference to GUEEXTEN is not material and can be removed.

OK.

> > Misspelled "varinant". Check rest of document for spelling.

OK.

> > for example, the reverse path might not use GUE and/or any other form of

OK.

> > well indicate the use of some form of error messaging.

OK.

> encapsualtion in examples.

OK, good.

> > appears to have a wording issue that I could not parse.

OK.

> Is more clarificaiton needed?

No, the text you quoted already addresses the concern.

> > of this RFC is "GRE-in-UDP Encapsulation".

OK.

> > "Generic UDP tunneling [GUT]" expired in 2010. Can we either drop this or refer

OK.

> control message bu requires further context to be interpreted.

OK.

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 31 Aug 2018 19:16:49 -0700

Hi, all,

> adopted a similar convention when it was specified so many decades ago.
FWIW, IP fragmentation copies the IP header in each fragment because
that field is part of the context for the ID field; i.e., ID MUST be
unique within src/dst/proto. If fragments had a different proto field,
it would undermine that context.

Joe