Subject: [tsvwg] FW: New Version Notification for draft-ietf-tsvwg-gre-in-udp-encap-10.txt

From: Lucy yong <[email-masked]>
Date: Tue, 1 Mar 2016 20:51:33 +0000

This version has some editing changes to improve the readability.

Thank Tom Herbert for the work. 

Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 01, 2016 2:47 PM
To: Edward Crabbe; Xuxiaohu; Lucy yong; Tom Herbert
Subject: New Version Notification for draft-ietf-tsvwg-gre-in-udp-encap-10.txt

A new version of I-D, draft-ietf-tsvwg-gre-in-udp-encap-10.txt
has been successfully submitted by Lucy Yong and posted to the IETF repository.

Name:		draft-ietf-tsvwg-gre-in-udp-encap
Revision:	10
Title:		GRE-in-UDP Encapsulation
Document date:	2016-03-01
Group:		tsvwg
Pages:		24
URL:            https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-gre-in-udp-encap-10.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-10
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-gre-in-udp-encap-10

Abstract:
   This document describes a method of encapsulating network protocol
   packets within GRE and UDP headers. In this encapsulation method,
   the source UDP port can be used as an entropy field for purposes of
   load balancing, while the protocol of the encapsulated packet in the
   GRE payload is identified by the GRE Protocol Type. This document
   specifies requirements for two applicability scenarios for the
   encapsulation: (1) General Internet; (2) Controlled Environment,
   e.g. well-managed operator networks. The controlled environment has
   less restrictive requirements than the general Internet.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: [email-masked]
Date: Wed, 2 Mar 2016 17:51:27 -0000

I think this version was a great improvement. Thanks ever so much.
However, after reading this I have a small number of questions for authors
and everyone interested.

I have 4 questions, which are still sent as an individual - although I
think the process is now heading towards WGLC, and it would be great to
understand the answers before we enter the formal process

Protocol questions
---------------------

(A) Two terms are used a WMON and a “controlled environment”. While I do
agree with, and much like, the idea of defining two styles of usage, I
worry about the name given for this particular usage. To me it kind of
suggests that “well-managed” and “operator” are key elements, whereas I
think the term “controlled environment” is what really matters. If the
safeguards are in place, it would seem at least to me that this usage
would apply - even if not an operator network. Would people  consider
changing this term? e.g. to "Controlled Environment"

- If you made such a change, I'd expect a well-managed operator network to
be a very concrete example of such a controlled environment.

- If for reasons we don't change, then it may be wise to add some
statement that explains that non-operator networks can also be considered
controlled environments ... which may be takes some care??.

(B)  I'd plan to discuss the statement below if it were still the same at
WGLC:
/   1. UDP checksum MAY be used when encapsulating in IPv4./
- It a detail, but I suggest the first statement needs to remain /SHOULD/
since this is what RFC5405 states. RFC2119, is clear, the default needs to
be to use as far as RFCs are concerned.

After you say this you can explain (including a MAY in the next sentence),
why this could can be relaxed in this specific case. This may be quite OK
to say for this case if you state that the encapsulation method is
considered robust from errors and that you MAY rely on the integrity
checks offered in the encapsulated protocol.

(C) The draft states:
/An encapsulator SHOULD NOT enable both the GRE checksum and
   UDP checksum simultaneously as this would be mostly redundant.
/
- I know we have discussed this before: To me this is purely an efficiency
consideration, but I do not see this as a SHOULD.
- I’d much prefer:
/When the UDP checksum is enabled, it protects the GRE payload,
resulting in the GRE checksum being mostly redundant.
Enabling both checksums may result in unnecessary processing./
- do you agree (in which case I'm happy to propose new text), or can we
discuss this again?

(D) I disagree with the statement:
“, and whether the
   packets in the network are protected by other, possibly stronger
   mechanisms such as the Ethernet CRC.”
Ethernet CRC is*NOT* equivalent in any way to transport checksum.  All
link-layers really should provide CRCs (RFC3819). If this sentence were to
propose an adaption-layer CRC on the header and contents that is
endpoint-to-endpoint I’d agree. Otherwise I strongly disagree with the
statement

Gorry

(I also have a rather large number of technical or textual comments that I
shall send separately, having spoke with the editors before, I believe
most of these are in the spirit of what I think they are proposing and
expect these to be resolved quickly).

> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-gre-in-udp-encap-10.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/
> Htmlized:
> https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-10
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-gre-in-udp-encap-10
>
> Abstract:
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
>

---

From: [email-masked]
Date: Wed, 2 Mar 2016 18:42:28 -0000

...
> expect these to be resolved quickly).

Document comments:

(1) One point I raised previously is that this encapsulation can be, and I
expect will be, used for purposes beyond ECMP.  The text has been updated,
but the abstract has not:
“In this encapsulation method,
   the source UDP port can be used as an entropy field for purposes of
   load balancing, while the protocol of the encapsulated packet in the
   GRE payload is identified by the GRE Protocol Type. “
- Is it possible to improve the writing of the first two sentences? or
perhaps even simpler to just move the above sentence to the sentences
after defining the two applicability scenarios?

(2) Similarly, the introduction opens with a specific example, rather than
a generic statement. To me, this is important, because we want the spec to
be ready by others thinking of new uses - otherwise we will have yet more
proposals for new encapsulation methods over UDP!

Could you please add a very short para before the start of intro based on
the generic properties of GRE?
Again a simpler solution may be to move a para -One of the later
paragraphs seems to introduce the encaps as a whole better, for example
the one starting:
/This document defines a generic GRE-in-UDP encapsulation/

(3) 1st para of current intro:
A suggestion is to move this later...
You perhaps could then start the sentence of the current first para: “Load
balancing,” By saying “One application of a UDP encapsulation is to
support load balancing...”

(4) Intro
“Equal Cost Multi-Path (ECMP)”
- cite info reference please.

(5) Intro
 “Link Aggregation Groups (LAGs)”
- cite info reference please.

(6)
“Most existing routers in IP networks”
- really? I don’t think so.

Most routers in the internet are home gateways or wifi basestations... I
think it would be better to say something like “many routers” or to
qualify that you mean carrier-grade or enterprise or some sector of the
router market.

Perhaps you actually mean “Most routers currently supporting ECMP”...?
Please update text one way or another

(7)
“ (UDP)[RFC768]”
insert space before reference.

(8)
/GRE encapsulation/ should be expanded as
/Generic Router Encapsulation (GRE) [REFxxxx]/

(9)
/Unfortunately, using GRE encapsulated within IP/
- same comment - this text needs to be in the part with the application
description, rather than the rationale for GRE/UDP.

(10)
/is not used for entropy purpose/
- English needs repaired, I do not quite understand.

 (11)
...  following statement would I think need changed:
/and the UDP header provides
   additional entropy by way of its source port./
to
/and the source port field in the UDP header may be
used to provide additional entropy./

(12)
/treat other tunnel endpoints as of the end hosts for the traffic and do
not differentiate such end hosts from other end
   hosts/
- English odd, is this something like:
/do not differentiate the traffic from different endpoints, applying the
same treatment for traffic from hosts and tunnel endpoints./ - or similar?

--- Section 1.1

(13) /networks including the Internet/
- I’m not sure you need to say /including the Internet/

(14)
   /When using GRE-in-UDP encapsulation, encapsulated
   traffic will be treated as a UDP application in an IP delivery
   network./
- Did you intend something like:
/Packets encapsulated by GRE-in-UDP are treated as UDP datagrams by an IP
network./
- Or something different?

(15)
/needs to meet UDP requirements/
insert /the/ before UDP./

(16)
/These limits may depend on both the network and the nature of
   the encapsulated traffic. /
Maybe better as:
/The requirements this place on the endpoints depend on both the network
and the nature of the encapsulated traffic. /

(17) I do not understand:
/and/or within a network that has the congestion management./
--- what is this subclause about? Are there examples of IUP networks that
provide network congestion management features? - what are they - can you
supply references?

(18)
/ 1) General Internet and 2) Controlled Environment./
should be:
/ 1) the general Internet and 2) a controlled environment./

(19)
/The controlled environment means within a single/
I think this could be something like:
/A controlled environment can be a single/

(20)
/A network under controlled environment/
I think this could be something like:
/A network forming a controlled environment/

(21)
/can be
   managed/operated to meet certain conditions while the general
   Internet cannot be.
- This may well be true, but what is about? I don’t see what you
are trying to say here.

(22)
/Tunnel protocol requirements under controlled
   environment/
Should be:
/The requirements for a tunnel protocol operating under a controlled
environment/

(23) The corrected sentence /Tunnel protocol ...
   general Internet. /
probably needs to follow the sentence after this.

(24)
/This document specifies GRE-in-UDP tunnel usage in
   the general Internet and GRE-in-UDP tunnel usage in the well-managed
   operator network that is an example of controlled environment./
- I’m not sure I buy the implication that all operator networks are like
this... can we rewrite this:
/ This document specifies GRE-in-UDP tunnel usage in
   the general Internet.

It also specifies usage of GRE-in-UDP for a controlled environment (e.g.,
a well-managed
   operator network)./
- starting a new para...

(25) Can we combine the para starting: /For the purpose of this document,
.../ - with the second sentence from (24).

(26)
/   This document refers to the GRE-in-UDP tunnel usage in the general
   Internet as Default GRE-in-UDP Tunnel; the GRE-in-UDP tunnel usage
   in a well-managed operator network as WMON GRE-in-UDP Tunnel.
/

/ The default usage described in this document refers to usage in the general
   Internet. It also describes usage within a Well-managed
operator network (WMON)./

(27) NOTE: I’m not sure the scope of WMON is correct. I’d have expected
the scope to be a “Controlled Environment” with a WMON as an example of
this type of network. Do you agree or think different?

- If you agree with my proposal, this needs to be reflected in section 1.2.

--- 1.2. GRE-in-UDP Tunnel Usage Requirements ---

(28)
/The section summarizes GRE-in-UDP tunnel requirements. The
   requirements for Default GRE-in-UDP tunnel are listed in Section
   1.2.1, which applies to a GRE-in-UDP tunnel over the general
   Internet; the relaxed requirements for WMON GRE-in-UDP Tunnel are
   listed in Section 1.2.2, which applies to a GRE-in-UDP tunnel within
   a well-managed operator network. These networks can use IPv4 or IPv6.
/
This needs to be written more clearly, and could be shorter such as:

/This section provides a summary of the requirements for a GRE-in-UDP tunnel.
Section 1.2.1 describes the default usage of GRE-in-UDP tunnel, suitable
for the general Internet; a set of relaxed requirements for use in a
controlled environment provided in Section 1.2.2./

(29) /UDP checksum SHOULD be used when encapsulating in IPv4./
Insert /A/ before UDP

(30) /UDP checksum SHOULD be used when encapsulating in IPv6./
Insert /A/ before UDP

(31)
/GRE-in-UDP tunnel MUST NOT be used for traffic that has no
   congestion control. /
perhaps better as:
/A GRE-in-UDP tunnel MUST NOT be used for traffic that does not implement
   congestion control. /

(32) /   4. UDP source port that is used for flow entropy SHOULD be set to a
   UDP ephemeral port (49152-65535)./
Insert /A/ before UDP

(32a) I see requirement 4 on the source port. At this point, I also note
the useful requirement in the security section to use a randomisation
algorithm to provide off-path protection. I think this is good, and should
be a requirement when source entropy is not in use.

(33)
/   5. UDP source port usage MUST be configurable so that a single value
   is used for all traffic in the tunnel (this disables use of the UDP
   source port to provide flow entropy).
/
perhaps better as:
/   5. The use of at the UDP source port MUST be configurable so that a
single value
   can be set for all traffic using the tunnel (this disables use of the UDP
   source port to provide flow entropy).
/

(34) Point 7.
It may be worth noting that: “All fragments MUST set the DSCP value. Use
of the ECN field is specified in RFC6040.“

(35)
/and SHOULD use the same source UDP port for all packet
   fragments to ensure the packet fragments traversing on the same path./
- strictly speaking it doesn’t ensure (alas). This may be better written as:
/. To avoid unwanted forwarding over multiple paths the same source UDP port
value SHOULD be set in all packet fragments./

(36)
 /  The following lists the changed requirements for WMON GRE-in-UDP
   Tunnel that is used in a well-managed operator network; they replace
   requirements 1-3 listed in section 1.2.1. The requirements 4-7 in
   that section are unchanged for WMON GRE-in-UDP Tunnel./
Suggest:
/  This section lists the changed requirements for use of a GRE-in-UDP
   Tunnel in a WMON GRE-in-UDP Tunnel. This replaces
   requirements 1-3 listed in section 1.2.1. The requirements 4-7 remain
   unchanged for a WMON GRE-in-UDP Tunnel./

(37)
 1. UDP checksum MAY
Insert /A/ before UDP
- I disagree on the /MAY/ see note above. Additional text would be needed
here to be consistent with recent RFCs.

(38)
/   3. GRE-in-UDP tunnel MAY encapsulate traffic that is not congestion/
Insert /A/ before GRE
- Additional text is needed here to state how this is managed.

(39) The requirements section needs to follow the definition of RFC 2119
keywords. Suggest you make this a new section to follow section 2.
Possibly 2.1.

---- Section 3

(40)
/   GRE-in-UDP encapsulation format is shown as follows:/
should be:
/   The GRE-in-UDP encapsulation format is shown in the following diagrams:/

(41)
Are diagrams presented in network byte order? I assume so, please check
and then state.

(42) I assume these diagrams are informative? - It may be worth stating this.

Please add a clear note in the text to request IANA to update the value
TBD in the diagrams. I think there are two alternate port numbers? So
maybe this should say TBD1 or TBD2.

Please explain “XXXX” in legend.

(43) If the headers in figure 1 are actually defined by another RFC,
please cite the RFC in the legend, to clarify that this document is not
redefining these fields.

---    3.1. IP Header

(44)
/The TTL field in the IP header MUST be set to a value
   appropriate for delivery of the encapsulated packet to the peer of
   the encapsulation./
- How would it know this? I’d suggest the text may be more acceptable if
rewritten:
/A sufficiently large value is needed in the IPv4 TTL field or
IPv6 Hop Count field to allow delivery of the encapsulated packet to the
peer of
   the encapsulation./
- alternatively you could remove this, since this is a standard behaviour.

(45)
I would strongly suggest this section starts by saying something like:
“There are two modes for usage of the UDP source port field. The first mode
assigns a static value to the source port field of all encapsulating
values. The second mode sets a dynamic value that may be used as a source
of entropy by network
devices that parse this field.”

(46)
- This is hard to parse about what is random and constant:
/it SHOULD set a randomly selected constant value for
   UDP source port to avoid payload packet flow reordering, e.g., the
   port can be chosen as a hash of the tunnel ingress and egress IP
   address./
- suggest something like:
/to avoid reordering with a packet flow, the encapsulator SHOULD use the same
UDP source port value for all packets assigned to a flow e.g., the result
of an algorithm that performa a hash of the tunnel ingress and egress IP
address./

(47)
The IPv6 Flow label appears to has two different specified uses - I think
the following is just a mistake):
/   For IPv6 delivery network, if IPv6 flow label load balancing is
   supported [RFC6438], the flow entropy SHOULD also be placed in the
   flow label field.
/
- The present text seems to suggest that operators should know whether the
tunnel passes over an IPv6 infrastructure that uses the flow label. If
that was intended, I disagree. This sort of statement discourage any
deployment of methods to use the field. I suggest the correct approach is:
/  Note: An IPv6 tunnel endpoint should copy a flow entropy value in
the IPv6 flow label field (requirement 6).
This permits network equipment to inspect this
value and utilise it during forwarding, e.g. to perform ECMP [RFC6438].
/
- add a cross reference to the section that says this.
- I suggest that this clause is only a note, since the requirement is
already stated.

(48)
/   How an encapsulator generates flow entropy from the payload is
   outside the scope of this document./
- Appears to contradict, there are restrictions stated in this section.
Suggest:
/This document places requirements on the generation of the flow entropy
value
but does not specify the algorithm that an implementation should use to
derive this value./

(49)
- Please change to say two port numbers here.
- In section 3.2.2. Please add a clear note to IANA to replace TBD with
the assigned port number.

(50)
/An encapsulator may set the GRE Key Present, Sequence Number Present,
   and Checksum Present bits and associated fields in the GRE header as
   defined by /
- Is this “MAY”, i think it is.

(51)
- do you agree, or can we discuss this again?

(52)
/Since
   the UDP checksum covers more of the packet including the GRE header
   and payload, the UDP checksum SHOULD have preference to using GRE
   checksum.
/
- True, but also because it includes the pseudo-header.
/Since
   the UDP checksum covers the pseudo-header and the packet payload,
   including the GRE header
   and its payload, the UDP checksum SHOULD be used in preference to using
the GRE
   checksum.
/

(53)
Currently says:
/The GRE checksum MAY be used for the payload integrity
   check when use of UDP zero-checksum./
- English needs fixed, but can we say more? e.g.,
/The GRE checksum MAY be used to provide a payload integrity check
when use of UDP zero-checksum./
- I believe this should be SHOULD - as later stated at the end of section
5.2.

--- 4. Encapsulation Process Procedures

(54)
/  When performing GRE-in-UDP
   encapsulation by the encapsulator, the entropy value is generated by
   the encapsulator and then be filled in the Source Port field of the
   UDP header. The Destination Port field is set to a value (TBD) to
   indicate that the UDP tunnel payload is a GRE packet. The Protocol
   Type header field in GRE header is set to the EtherType value
   corresponding to the protocol of the encapsulated packet.
/
- This seems to replicate the text above. I’d really suggest removing it
to avoid slight inconsistencies. If you keep it - make sure you update it.
There are two source port modes; there are two destination ports
specified; etc.

(55)
/ GRE-in-UDP allows encapsulation of unicast, broadcast, or multicast
   traffic./
- and not any cast? please explain why or include in the list.
- prefix broadcast by “IPv4”.

---    4.1. MTU and Fragmentation

(56)
/When applying payload fragment, the UDP checksum MUST/
- change /fragment/ to /fragmentation/

(57)
/   If a tunnel operator is able to control the payload MTU size, the
   tunnel operator SHOULD factor in the additional bytes of tunnel
   overhead when considering the MTU size to avoid the likelihood of
   fragmentation.
/
- If the operator doesn’t it goes wrong? Maybe a better form of words
could be:
/  If a tunnel operator is able to control the payload MTU size, the
   tunnel operator SHOULD configure an MTU to avoid fragmentation
   that is sufficient for the
   largest supported size of packet, including
   all additional bytes introduced by the tunnel
   overhead [RFC5405bis].
/

---    4.2. Middlebox Considerations

(58)
/   The Source Port number of the UDP header is pertinent to the
   middlebox behavior. /
- not all middlexboxes are the same. I suggest:
/Many middleboxes read or update UDP port information of the packets
that they forward./

(59)
/   with the behavior that the UDP source port number is used as entropy
   in GRE-in-UDP tunnel.
/
suggest:
/   with the behavior a GRE-in-UDP tunnel that is configured to use the
    UDP source port value to provide entropy.
/

(60)
/ the GRE-in-UDP Destination Port (TBD), /
- should be:
/one of GRE destination ports (TBD1 or TBD2)/
- You need to add an “IANA NOTE: please update with assigned values”

(61)
/and in particular, is never
   sent back to any port used as a UDP Source Port/
- However, the requirement to use ephemeral ports was not a MUST, and
hence this isn’t really necessarily true, you could have a src port the
same as the destination port. This needs more clever use of English.
- Maybe you could say something a little like:
/However, traffic is not expected to be returned back to the UDP Source
Port values used to generate entropy./

(62)
/assume that bidirectional traffic uses a common pair of
   UDP ports/
Perhaps add:
/assume that bidirectional traffic uses a common pair of
   UDP ports (e.g., to dynamically configure forwarding rules)/

(63)
/the operator either disable UDP source .../
- insert can before /either/

(64)
/configure the middlebox to deal with the UDP source port
   variation./
- perhaps better as:
/configure middleboxes on the path to expect the UDP source port
   entropy./

(65)
/process the payload to get the proper parameters to fill into the IP
   header/
- suggest:
/process the tunnelled IP packet headers to retrieve appropriate
parameters for the
encapsulating IP packet header./

(66)
I suggest you add a reference from 3.1 to point to this section.
“Additional information on IP header processing is provided in section
4.3”.

--- 5.1. UDP Checksum with IPv4

(67)
This statement is repeated from earlier:
/   Default GRE-in-UDP Tunnel SHOULD perform UDP checksum. WMON GRE-in-
   UDP Tunnel MAY perform UDP checksum./
- and said again below, could we remove this statement.

(68)
/Enabling or disabling the use of checksums/
- The checksum MUST be enabled by default - hence this sentence should
really read:
/Disabling the use of checksums/

(69) - see note on my earlier position that I do not understand why this
draft would not say “SHOULD use an IPv4 checksum” for all cases - with
stated reasons for not doing so for the WMON. I do not see a need to
updating the guidelines to say “MAY use an IPv4 Checksum”.

(70) part d:
/It is RECOMMENDED that UDP zero-checksum selectively be enabled
        for certain source addresses. /
- That doesn’t quite make sense, is this better:
/It is RECOMMENDED that the UDP zero-checksum mode is only enabled for
certain selected source addresses. /

(71) part f:
- May also be useful to note that a “Using a fixed UDP source port value
can also improve the probability of middlebox traversal.”

(72)
/In summary, WMON GRE-in-UDP Tunnel is allowed to use UDP-zero-
   checksum mode for IPv6 when the conditions and requirements stated
   above are met. Otherwise the UDP checksum MUST be used for IPv6 as
   specified in [RFC768] and [RFC2460]./

To avoid repeating the RFC2119 clauses please remove the “Otherwise... “
sentence, or change /MUST/ to /needs to/.

(73)
/Use of GRE checksum is
   recommended when the UDP checksum is not used./
- I agree, please ensure corrections above to ensure this is consistent
within the document.

(74) 4.2 and 5.2.1 are both called middlebox considerations!
- Maybe rename 4.2 as “Middlebox considerations for source port entropy”
and 5.2.1 as “Middlebox considerations for zero checksums”

(75)
It may be MUCH more helpful to place 4.2 and 5.2.1 together in the same
section, since then any middlebox vendor or operator could read both
together and know what to do. I suggest making section 6 “Middlebox
considerations”

(76)
/For this reason, GRE-in-UDP tunnel MUST be used within a single
   operator's network that utilizes/
- Maybe this actually would read better as:
/When a GRE-in-UDP tunnel carries this type of traffic, use MUST be
constrained
to a controlled environment (e.g., single
   operator network that utilizes/

(77)
/GRE-in-UDP tunnel can be used in some cases to carry traffic/
Could we change to:
/A GRE-in-UDP tunnel can be used to carry traffic/
(78)
/to ensure against congestion/
- to /to manage congestion/

(79)
- could we move the default case before the “operator” case, because the
flow is much easier to read that way...

i.e., move para starting:
/The default GRE-in-UDP tunnel can be used/
before para starting:
/GRE-in-UDP tunnel can be/

(80)
/WMON GRE-in-UDP Tunnel is used within/
- change to
/A WMON GRE-in-UDP Tunnel is specified for use within/

(81)
/listening on the destination port (TBD)./
change to - ports and add IANA note to update.

(82) DTLS
The para starting /Datagram Transport Layer Security (DTLS) /
is not a security consideration, it is a part of the protocol spec. Please
create a new subsection and place the text there. Maybe at the end of
section 3?

- I suspect the final security section should then briefly say that DTLS
can be used to secure the GRE connection.

(83) /Corruption of GRE header can cause a privacy and security/
Insert “a” before GRE

Protocol questions (also sent separately for list discussion).

(A) Two terms are used a WMON and a “controlled environment”. While I do
agree with the idea of defining this additional usage, I worry about the
name given. To me it kind of suggests that “well-managed” and “operator”
are key elements, whereas I think the term “controlled environment” is
what really matters. If the safeguards are in place, the usage would seem
to apply - even if not an operator network. Would you consider changing
this term?

(B)    I'd plan to discuss the statement below if it were still the same
at WGLC:

(c)
/An encapsulator SHOULD NOT enable both the GRE checksum and
   UDP checksum simultaneously as this would be mostly redundant.
/
- I know we have discussed this before: To me this is purely an efficiency
consideration, but I do not see this as a SHOULD.
- I’d much prefer:
/When the UDP checksum is enabled, it protects the GRE payload,
resulting in the GRE checksum being mostly redundant.
Enabling both checksums may result in unnecessary processing./
- do you agree, or can we discuss this again?
See comments 52 and 53 in my list.

(d) I disagree with the statement:
“, and whether the
statement.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 3 Mar 2016 08:30:20 -0800

> understand the answers before we enter the formal process

It's not entirely clear to me either what the difference is between
WMON and Controlled environment.

> be to use as far as RFCs are concerned.
I agree.

> - do you agree (in which case I'm happy to propose new text), or can we
I like this alternate text. Since we're already saying that UDP+GRE is
one protocol, I think it's very unlikely anyone would use GRE checksum
instead of UDP checksum, UDP checksum has much better support.

> endpoint-to-endpoint I’d agree. Otherwise I strongly disagree with the
How about ", and whether the packets in the network are protected by
other, possibly stronger end to end mechanisms such as an application
layer CRC.”?

Tom

---

From: "Black, David" <[email-masked]>
Date: Thu, 3 Mar 2016 17:01:56 +0000

> WMON and Controlled environment.

Controlled Environment is the term used in the rfc5405bis draft.   It might be best
to adopt that term here in place of WMON for clarity.

Thanks, --David

> From: tsvwg [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Thursday, March 03, 2016 11:30 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [tsvwg] FW: New Version Notification for draft-ietf-tsvwg-gre-in-
> udp-encap-10.txt
>

---

From: <[email-masked]>
Date: Sun, 6 Mar 2016 04:18:34 +0000 (UTC)

> When the UDP checksum is enabled, it protects the GRE payload,

No. That's like saying 'When an Ethernet CRC protects the UDP payload,
the UDP checksum is redundant', which as is pointed out below,
is not true - it's a question of scope of the part of path covered,
and the Eth link scope is different from the UDP scope.

Similarly, the UDP tunnel scope can be different from the GRE
tunnel scope, as the draft intro says: 'may be used to encapsulate
already tunnelled traffic' on a larger overall path - just as
the UDP path is greater than the Eth path.

When the path scope is different, the GRE checksum is far more
useful, and 'mostly' doesn't cover that.

God, this don't-throw-the-baby-out-with-the-bathwater stuff
is tedious. This entire draft is 'well, you probably don't like
the baby that much, so okay, out it goes, because one action
throwing out everything is more efficient.'

 Lloyd Wood [email-masked] http://about.me/lloydwood 

----- Original Message -----
From: Tom Herbert <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Friday, 4 March 2016, 3:30
Subject: Re: [tsvwg] FW: New Version Notification for draft-ietf-tsvwg-gre-in-udp-encap-10.txt

I agree.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Sun, 6 Mar 2016 08:34:02 -0800

> useful, and 'mostly' doesn't cover that.
Lloyd, the path scope is the same for GRE-in-UDP. From section 3.3:

"Although GRE-in-UDP encapsulation protocol uses both UDP header and
GRE header, it is one tunnel encapsulation protocol. GRE and UDP
headers MUST be applied and removed as a pair at the encapsulation
and decapsulation points. This specification does not support UDP
encapsulation of a GRE header where that GRE header is applied or
removed at a network node other than the UDP tunnel ingress or
egress."

---

From: Lucy yong <[email-masked]>
Date: Mon, 7 Mar 2016 14:51:01 +0000

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Thursday, March 03, 2016 10:30 AM
To: [email-masked]
Cc: Lucy yong; [email-masked]
Subject: Re: [tsvwg] FW: New Version Notification for draft-ietf-tsvwg-gre-in-udp-encap-10.txt

On Wed, Mar 2, 2016 at 9:51 AM,  <[email-masked]> wrote:
> However, after reading this I have a small number of questions for 
> authors and everyone interested.
>
> think the process is now heading towards WGLC, and it would be great 
> to understand the answers before we enter the formal process
>
> Protocol questions
> ---------------------
>
> (A) Two terms are used a WMON and a “controlled environment”. While I 
> do agree with, and much like, the idea of defining two styles of 
> usage, I worry about the name given for this particular usage. To me 
> it kind of suggests that “well-managed” and “operator” are key 
> elements, whereas I think the term “controlled environment” is what 
> really matters. If the safeguards are in place, it would seem at least 
> to me that this usage would apply - even if not an operator network. 
> Would people  consider changing this term? e.g. to "Controlled Environment"
>
> - If you made such a change, I'd expect a well-managed operator 
> network to be a very concrete example of such a controlled environment.
>
> statement that explains that non-operator networks can also be 
> considered controlled environments ... which may be takes some care??.

It's not entirely clear to me either what the difference is between WMON and Controlled environment.
[[Lucy]] Controlled environment means within a single
   administrative domain or bilaterally agreed connection between
   domains. There could be many controlled environments. Here we specifies a particular controlled environment, i.e. congestion controlled environment. How about call congestion controlled environment? 

> at
> - It a detail, but I suggest the first statement needs to remain 
> /SHOULD/ since this is what RFC5405 states. RFC2119, is clear, the 
> default needs to be to use as far as RFCs are concerned.
>
I agree.
[[Lucy]] agree too.

> After you say this you can explain (including a MAY in the next 
> sentence), why this could can be relaxed in this specific case. This 
> may be quite OK to say for this case if you state that the 
> encapsulation method is considered robust from errors and that you MAY 
> rely on the integrity checks offered in the encapsulated protocol.
>
> (C) The draft states:
> - I know we have discussed this before: To me this is purely an 
> efficiency consideration, but I do not see this as a SHOULD.
> - I’d much prefer:
> - do you agree (in which case I'm happy to propose new text), or can 
> we discuss this again?
>
[[Lucy]] OK.
I like this alternate text. Since we're already saying that UDP+GRE is one protocol, I think it's very unlikely anyone would use GRE checksum instead of UDP checksum, UDP checksum has much better support.

> link-layers really should provide CRCs (RFC3819). If this sentence 
> were to propose an adaption-layer CRC on the header and contents that 
> is endpoint-to-endpoint I’d agree. Otherwise I strongly disagree with 
> the statement
>
How about ", and whether the packets in the network are protected by other, possibly stronger end to end mechanisms such as an application layer CRC.”?
[[Lucy]] What is the reason for use of UDP zero checksum in ipv4 network? It is because IP has the checksum. Should we state possibly mechanisms such as IP checksum, etc?

Will look at Gorry's second comment mail later today due to day's meeting.

Regards,
Lucy

Tom

> Gorry
>
> (I also have a rather large number of technical or textual comments 
> that I shall send separately, having spoke with the editors before, I 
> believe most of these are in the spirit of what I think they are 
> proposing and expect these to be resolved quickly).
>

---

From: "Black, David" <[email-masked]>
Date: Mon, 7 Mar 2016 16:51:51 +0000

>    domains. There could be many controlled environments. Here we specifies a
> particular controlled environment, i.e. congestion controlled environment. How
> about call congestion controlled environment?

Offline discussion among authors and WG chairs suggests "Traffic-Managed Controlled Environment"
as a better term.  Network operators manage/control traffic - the resulting avoidance of congestion
is a by-product.

Thanks, --David

> From: tsvwg [mailto:[email-masked]] On Behalf Of Lucy yong
> Sent: Monday, March 07, 2016 9:51 AM
> To: Tom Herbert; [email-masked]
> Cc: [email-masked]
>    domains. There could be many controlled environments. Here we specifies a
> particular controlled environment, i.e. congestion controlled environment. How
> about call congestion controlled environment?
> 
> >
> I like this alternate text. Since we're already saying that UDP+GRE is one protocol,
> I think it's very unlikely anyone would use GRE checksum instead of UDP
> checksum, UDP checksum has much better support.
> 
> How about ", and whether the packets in the network are protected by other,
> possibly stronger end to end mechanisms such as an application layer CRC.”?
> [[Lucy]] What is the reason for use of UDP zero checksum in ipv4 network? It is
> because IP has the checksum. Should we state possibly mechanisms such as IP
> checksum, etc?
>

---

From: Lucy yong <[email-masked]>
Date: Mon, 7 Mar 2016 17:48:52 +0000

Thx David.
Lucy

-----Original Message-----
From: Black, David [mailto:[email-masked]] 
Sent: Monday, March 07, 2016 10:52 AM
To: Lucy yong; Tom Herbert; [email-masked]
Cc: [email-masked]
Subject: RE: [tsvwg] FW: New Version Notification for draft-ietf-tsvwg-gre-in-udp-encap-10.txt

>    domains. There could be many controlled environments. Here we 
> specifies a particular controlled environment, i.e. congestion 
> controlled environment. How about call congestion controlled environment?

Offline discussion among authors and WG chairs suggests "Traffic-Managed Controlled Environment"
as a better term.  Network operators manage/control traffic - the resulting avoidance of congestion is a by-product.

Thanks, --David

> Subject: Re: [tsvwg] FW: New Version Notification for 
> draft-ietf-tsvwg-gre-in- udp-encap-10.txt
> 
> 
> 
> Subject: Re: [tsvwg] FW: New Version Notification for 
> draft-ietf-tsvwg-gre-in- udp-encap-10.txt
> 
> > I have 4 questions, which are still sent as an individual - although 
> > I think the process is now heading towards WGLC, and it would be 
> > great to understand the answers before we enter the formal process
> >
> > Protocol questions
> > ---------------------
> >
> > (A) Two terms are used a WMON and a “controlled environment”. While 
> > I do agree with, and much like, the idea of defining two styles of 
> > really matters. If the safeguards are in place, it would seem at 
> > least to me that this usage would apply - even if not an operator network.
>    domains. There could be many controlled environments. Here we 
> specifies a particular controlled environment, i.e. congestion 
> controlled environment. How about call congestion controlled environment?
> 
> >
> > encapsulation method is considered robust from errors and that you 
> > MAY rely on the integrity checks offered in the encapsulated protocol.
> >
> > (C) The draft states:
> > Ethernet CRC is*NOT* equivalent in any way to transport checksum.  
> > All link-layers really should provide CRCs (RFC3819). If this 
> > sentence were to propose an adaption-layer CRC on the header and 
> > contents that is endpoint-to-endpoint I’d agree. Otherwise I 
> > strongly disagree with the statement
> >
> other, possibly stronger end to end mechanisms such as an application layer CRC.”?
> [[Lucy]] What is the reason for use of UDP zero checksum in ipv4 
> network? It is because IP has the checksum. Should we state possibly 
> mechanisms such as IP checksum, etc?
> 
> > that I shall send separately, having spoke with the editors before, 
> > I believe most of these are in the spirit of what I think they are 
> >> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-gre-in-udp-en
> >> ca
> >> p-10.txt
> >> Status:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-gre-in-udp-encap
> >> -1
> >> 0
> >>
> >> Abstract:

---

From: Lucy yong <[email-masked]>
Date: Mon, 7 Mar 2016 20:57:14 +0000

Hi Gorry,

(D) I disagree with the statement:
", and whether the
   packets in the network are protected by other, possibly stronger
   mechanisms such as the Ethernet CRC."
Ethernet CRC is*NOT* equivalent in any way to transport checksum.  All link-layers really should provide CRCs (RFC3819). If this sentence were to propose an adaption-layer CRC on the header and contents that is endpoint-to-endpoint I'd agree. Otherwise I strongly disagree with the statement

How about: remove the wording. " and whether the packets in the network are protected by other, possibly stronger
   mechanisms such as the Ethernet CRC."

Lucy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 02, 2016 11:51 AM
To: Lucy yong
Cc: [email-masked]
Subject: Re: [tsvwg] FW: New Version Notification for draft-ietf-tsvwg-gre-in-udp-encap-10.txt

I think this version was a great improvement. Thanks ever so much.
However, after reading this I have a small number of questions for authors and everyone interested.

I have 4 questions, which are still sent as an individual - although I think the process is now heading towards WGLC, and it would be great to understand the answers before we enter the formal process

Protocol questions
---------------------

(A) Two terms are used a WMON and a "controlled environment". While I do agree with, and much like, the idea of defining two styles of usage, I worry about the name given for this particular usage. To me it kind of suggests that "well-managed" and "operator" are key elements, whereas I think the term "controlled environment" is what really matters. If the safeguards are in place, it would seem at least to me that this usage would apply - even if not an operator network. Would people  consider changing this term? e.g. to "Controlled Environment"

- If you made such a change, I'd expect a well-managed operator network to be a very concrete example of such a controlled environment.

- If for reasons we don't change, then it may be wise to add some statement that explains that non-operator networks can also be considered controlled environments ... which may be takes some care??.

(B)  I'd plan to discuss the statement below if it were still the same at
WGLC:
/   1. UDP checksum MAY be used when encapsulating in IPv4./
- It a detail, but I suggest the first statement needs to remain /SHOULD/ since this is what RFC5405 states. RFC2119, is clear, the default needs to be to use as far as RFCs are concerned.

After you say this you can explain (including a MAY in the next sentence), why this could can be relaxed in this specific case. This may be quite OK to say for this case if you state that the encapsulation method is considered robust from errors and that you MAY rely on the integrity checks offered in the encapsulated protocol.

(C) The draft states:
/An encapsulator SHOULD NOT enable both the GRE checksum and
   UDP checksum simultaneously as this would be mostly redundant.
/
- I know we have discussed this before: To me this is purely an efficiency consideration, but I do not see this as a SHOULD.
- I'd much prefer:
/When the UDP checksum is enabled, it protects the GRE payload, resulting in the GRE checksum being mostly redundant.
Enabling both checksums may result in unnecessary processing./
- do you agree (in which case I'm happy to propose new text), or can we discuss this again?

(D) I disagree with the statement:
", and whether the
   packets in the network are protected by other, possibly stronger
   mechanisms such as the Ethernet CRC."
Ethernet CRC is*NOT* equivalent in any way to transport checksum.  All link-layers really should provide CRCs (RFC3819). If this sentence were to propose an adaption-layer CRC on the header and contents that is endpoint-to-endpoint I'd agree. Otherwise I strongly disagree with the statement

Gorry

(I also have a rather large number of technical or textual comments that I shall send separately, having spoke with the editors before, I believe most of these are in the spirit of what I think they are proposing and expect these to be resolved quickly).

---

From: Lucy yong <[email-masked]>
Date: Mon, 7 Mar 2016 21:43:24 +0000

Hi Gorry,

Thank you very much for the detail review and good comments/suggestions. I am OK with most of your suggestions. There are few I proposed alternative text. Please see inline below and let me know if those tweak wordings are acceptable? If not, what alternatives you like. Once we done, I will update the new version to reflect your suggestions.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 02, 2016 12:42 PM
To: [email-masked]
Cc: Lucy yong; [email-masked]
Subject: Comments on draft-ietf-tsvwg-gre-in-udp-encap-10.txt

...

Document comments:

(1) One point I raised previously is that this encapsulation can be, and I expect will be, used for purposes beyond ECMP.  The text has been updated, but the abstract has not:
"In this encapsulation method,
   the source UDP port can be used as an entropy field for purposes of
   load balancing, while the protocol of the encapsulated packet in the
   GRE payload is identified by the GRE Protocol Type. "
- Is it possible to improve the writing of the first two sentences? or perhaps even simpler to just move the above sentence to the sentences after defining the two applicability scenarios?
[[Lucy]]  How about:
   This document describes a method of encapsulating network protocol
   packets within GRE and UDP headers, which leverages transit network ECMP mechanism. 
   In this encapsulation method,
   the source UDP port can be used as an entropy field for purposes of
   load balancing, while the protocol of the encapsulated packet in the
   GRE payload is identified by the GRE Protocol Type. The document
   specifies requirements for two applicability scenarios for the
   encapsulation: (1) General Internet; (2) Traffic-Managed Controlled Environment. This controlled environment has
   less restrictive requirements than the general Internet.

(2) Similarly, the introduction opens with a specific example, rather than a generic statement. To me, this is important, because we want the spec to be ready by others thinking of new uses - otherwise we will have yet more proposals for new encapsulation methods over UDP!

Could you please add a very short para before the start of intro based on the generic properties of GRE?
Again a simpler solution may be to move a para -One of the later paragraphs seems to introduce the encaps as a whole better, for example the one starting:
/This document defines a generic GRE-in-UDP encapsulation/
[[Lucy]] How about remove first and second paragraphs in intro?

(3) 1st para of current intro:
A suggestion is to move this later...
You perhaps could then start the sentence of the current first para: "Load balancing," By saying "One application of a UDP encapsulation is to support load balancing..."

(4) Intro
"Equal Cost Multi-Path (ECMP)"
- cite info reference please.

(5) Intro
 "Link Aggregation Groups (LAGs)"
- cite info reference please.

(6)
"Most existing routers in IP networks"
- really? I don't think so.

Most routers in the internet are home gateways or wifi basestations... I think it would be better to say something like "many routers" or to qualify that you mean carrier-grade or enterprise or some sector of the router market.

Perhaps you actually mean "Most routers currently supporting ECMP"...?
Please update text one way or another

(7)
" (UDP)[RFC768]"

(8)
/GRE encapsulation/ should be expanded as /Generic Router Encapsulation (GRE) [REFxxxx]/

(9)
/Unfortunately, using GRE encapsulated within IP/
- same comment - this text needs to be in the part with the application description, rather than the rationale for GRE/UDP.

(10)
/is not used for entropy purpose/
- English needs repaired, I do not quite understand.
[[Lucy]] comments from 1 to 10 is in first and second para. Thx. If they stay, I will modify according your comment.

 (11)
...  following statement would I think need changed:
/and the UDP header provides
   additional entropy by way of its source port./ to /and the source port field in the UDP header may be used to provide additional entropy./
[[Lucy]] ack

(12)
/treat other tunnel endpoints as of the end hosts for the traffic and do not differentiate such end hosts from other end
   hosts/
- English odd, is this something like:
/do not differentiate the traffic from different endpoints, applying the same treatment for traffic from hosts and tunnel endpoints./ - or similar?
[[Lucy]] how about: do not differentiate the traffic from different endpoints, i.e., applying the same treatment for traffic from hosts and tunnel endpoints.

--- Section 1.1

(13) /networks including the Internet/
- I'm not sure you need to say /including the Internet/
[[Lucy]] ack

(14)
   /When using GRE-in-UDP encapsulation, encapsulated
   traffic will be treated as a UDP application in an IP delivery
   network./
- Did you intend something like:
/Packets encapsulated by GRE-in-UDP are treated as UDP datagrams by an IP network./
- Or something different?
[[Lucy]] yes. Will use your words.

(15)

(16)
/These limits may depend on both the network and the nature of
   the encapsulated traffic. /
Maybe better as:
/The requirements this place on the endpoints depend on both the network and the nature of the encapsulated traffic. /

(17) I do not understand:
/and/or within a network that has the congestion management./
--- what is this subclause about? Are there examples of IUP networks that provide network congestion management features? - what are they - can you supply references?
[[Lucy]] How about: a network that has traffic management capability to avoid congestion happening

(18)
/ 1) General Internet and 2) Controlled Environment./ should be:
/ 1) the general Internet and 2) a controlled environment./
[[Lucy]] Thx. Will change to "a traffic-managed controlled environment"

(19)
/The controlled environment means within a single/ I think this could be something like:
/A controlled environment can be a single/
[[Lucy]] how about: A controlled environment means a single 

(20)
/A network under controlled environment/ I think this could be something like:
/A network forming a controlled environment/
[[Lucy]] ack

(21)
/can be
   managed/operated to meet certain conditions while the general
   Internet cannot be.
- This may well be true, but what is about? I don't see what you are trying to say here.
[[Lucy]] How about: A network forming a controlled environment can be managed/operated to meet certain conditions while the general Internet cannot be; thus tunnel protocol requirements under a controlled environment can be less restrictive than the requirements in the general Internet.

(22)
/Tunnel protocol requirements under controlled
   environment/
Should be:
/The requirements for a tunnel protocol operating under a controlled environment/
[[Lucy]] ack

(24)
- I'm not sure I buy the implication that all operator networks are like this... can we rewrite this:

It also specifies usage of GRE-in-UDP for a controlled environment (e.g., a well-managed
   operator network)./
- starting a new para...
[[Lucy]] how about: This document specifies GRE-in-UDP tunnel usage in the general Internet; it also specifies GRE-in-UDP tunnel usage in the traffic-managed controlled environment.

(25) Can we combine the para starting: /For the purpose of this document, .../ - with the second sentence from (24).
[[Lucy]] ack.

(26)

/ The default usage described in this document refers to usage in the general
   Internet. It also describes usage within a Well-managed operator network (WMON)./
[[Lucy]] how about: The default usage described in this document refers to usage in the general Internet; the conditional usage described in this document refers to usage in a traffic-managed controlled environment.

(27) NOTE: I'm not sure the scope of WMON is correct. I'd have expected the scope to be a "Controlled Environment" with a WMON as an example of this type of network. Do you agree or think different?
[[Lucy]] above proposed change removes "as example of this ..."

- If you agree with my proposal, this needs to be reflected in section 1.2.
[[Lucy]] yes, the document works on a tariff-managed controlled environment. See the text below.

(28)

/This section provides a summary of the requirements for a GRE-in-UDP tunnel.
Section 1.2.1 describes the default usage of GRE-in-UDP tunnel, suitable for the general Internet; a set of relaxed requirements for use in a controlled environment provided in Section 1.2.2./
[[Lucy]] how about: This section provides a summary of the requirements for a GRE-in-UDP tunnel. Section 1.2.1 describes the default usage of GRE-in-UDP tunnel, suitable for the general Internet; Section 1.2.2 describes a set of relaxed requirements for use in a traffic-managed controlled environment

(29) /UDP checksum SHOULD be used when encapsulating in IPv4./ Insert /A/ before UDP
[[Lucy]] ack

(30) /UDP checksum SHOULD be used when encapsulating in IPv6./ Insert /A/ before UDP
[[Lucy]] ack

(31)
[[Lucy]] ack

(32a) I see requirement 4 on the source port. At this point, I also note the useful requirement in the security section to use a randomisation algorithm to provide off-path protection. I think this is good, and should be a requirement when source entropy is not in use.

(33)
[[Lucy]] how about: The use of the UDP source port MUST be configurable so that a single value can be set for all traffic within the tunnel (this disables use of the UDP source port to provide flow entropy). When a single value is set, a random port SHOULD be selected in order to minimize the vulnerability to off-path attacks.[RFC6056]

(34) Point 7.
It may be worth noting that: "All fragments MUST set the DSCP value. Use of the ECN field is specified in RFC6040."
[[Lucy]] why need to mention ECN here? How about: the tunnel ingress MUST apply the UDP checksum to all encapsulated fragments so that the tunnel egress can validate reassembly of the fragments; it MUST set the same DSCP value.

(35)
/and SHOULD use the same source UDP port for all packet
   fragments to ensure the packet fragments traversing on the same path./
- strictly speaking it doesn't ensure (alas). This may be better written as:
/. To avoid unwanted forwarding over multiple paths the same source UDP port value SHOULD be set in all packet fragments./
[[Lucy]] ack.

(36)
[[Lucy]] How about: The section lists the changed requirements for a conditional GRE-in-UDP Tunnel that is applied to a traffic-managed controlled environment. This replaces requirements 1-3 listed in section 1.2.1. The requirements 4-7 remain unchanged for a conditional GRE-in-UDP Tunnel.

(37)
 1. UDP checksum MAY
Insert /A/ before UDP
- I disagree on the /MAY/ see note above. Additional text would be needed here to be consistent with recent RFCs.
[[Lucy]] do you want "SHOULD"? Which RFC?

(38)

(39) The requirements section needs to follow the definition of RFC 2119 keywords. Suggest you make this a new section to follow section 2.
Possibly 2.1.

---- Section 3

(40)
[[Lucy]] ack

(41)
Are diagrams presented in network byte order? I assume so, please check and then state.
[[Lucy]] I think it is in bit order, right? I can add a note to clarity.

Please add a clear note in the text to request IANA to update the value TBD in the diagrams. I think there are two alternate port numbers? So maybe this should say TBD1 or TBD2.

Please explain "XXXX" in legend.
[[Lucy]] ack

(43) If the headers in figure 1 are actually defined by another RFC, please cite the RFC in the legend, to clarify that this document is not redefining these fields.
[[Lucy]] ack

---    3.1. IP Header

(44)
/The TTL field in the IP header MUST be set to a value
   appropriate for delivery of the encapsulated packet to the peer of
   the encapsulation./
- How would it know this? I'd suggest the text may be more acceptable if
rewritten:
/A sufficiently large value is needed in the IPv4 TTL field or
IPv6 Hop Count field to allow delivery of the encapsulated packet to the peer of
   the encapsulation./
- alternatively you could remove this, since this is a standard behaviour.
[[Lucy]] use your wording.

(45)
I would strongly suggest this section starts by saying something like:
"There are two modes for usage of the UDP source port field. The first mode assigns a static value to the source port field of all encapsulating values. The second mode sets a dynamic value that may be used as a source of entropy by network devices that parse this field."
[[Lucy]] since thi

(46)
/to avoid reordering with a packet flow, the encapsulator SHOULD use the same UDP source port value for all packets assigned to a flow e.g., the result of an algorithm that performa a hash of the tunnel ingress and egress IP address./
[[Lucy]] ack

(47)
The IPv6 Flow label appears to has two different specified uses - I think the following is just a mistake):
/   For IPv6 delivery network, if IPv6 flow label load balancing is
   supported [RFC6438], the flow entropy SHOULD also be placed in the
   flow label field.
/
- The present text seems to suggest that operators should know whether the tunnel passes over an IPv6 infrastructure that uses the flow label. If that was intended, I disagree. This sort of statement discourage any deployment of methods to use the field. I suggest the correct approach is:
/  Note: An IPv6 tunnel endpoint should copy a flow entropy value in the IPv6 flow label field (requirement 6).
This permits network equipment to inspect this value and utilise it during forwarding, e.g. to perform ECMP [RFC6438].
/
- add a cross reference to the section that says this.
- I suggest that this clause is only a note, since the requirement is already stated.
[[Lucy]] ack.

(48)
/   How an encapsulator generates flow entropy from the payload is
   outside the scope of this document./
- Appears to contradict, there are restrictions stated in this section.
Suggest:
/This document places requirements on the generation of the flow entropy value but does not specify the algorithm that an implementation should use to derive this value./
[[Lucy]] ack

(49)
- Please change to say two port numbers here.
- In section 3.2.2. Please add a clear note to IANA to replace TBD with the assigned port number.
[[Lucy]] ack

(50)
/An encapsulator may set the GRE Key Present, Sequence Number Present,
   and Checksum Present bits and associated fields in the GRE header as
   defined by /
- Is this "MAY", i think it is.
[[Lucy]] ack

(51)
[[Lucy]] ack

(52)
/Since
   and its payload, the UDP checksum SHOULD be used in preference to using the GRE
   checksum.
/
[[Lucy]] ack.

(53)
Currently says:
/The GRE checksum MAY be used for the payload integrity
   check when use of UDP zero-checksum./
- English needs fixed, but can we say more? e.g., /The GRE checksum MAY be used to provide a payload integrity check when use of UDP zero-checksum./
- I believe this should be SHOULD - as later stated at the end of section 5.2.
[[Lucy]] removed.

(54)
/  When performing GRE-in-UDP
   encapsulation by the encapsulator, the entropy value is generated by
   the encapsulator and then be filled in the Source Port field of the
   UDP header. The Destination Port field is set to a value (TBD) to
   indicate that the UDP tunnel payload is a GRE packet. The Protocol
   Type header field in GRE header is set to the EtherType value
   corresponding to the protocol of the encapsulated packet.
/
- This seems to replicate the text above. I'd really suggest removing it to avoid slight inconsistencies. If you keep it - make sure you update it.
There are two source port modes; there are two destination ports specified; etc.
[[Lucy]] take your suggestion. Simply refer to Section 3.

(55)
/ GRE-in-UDP allows encapsulation of unicast, broadcast, or multicast
   traffic./
- and not any cast? please explain why or include in the list.
- prefix broadcast by "IPv4".
[[Lucy]] any cast too. What is prefix broadcast?

(56)
[[Lucy]] ack

(57)
- If the operator doesn't it goes wrong? Maybe a better form of words could be:
[[Lucy]] ack

(58)
/   The Source Port number of the UDP header is pertinent to the
   middlebox behavior. /
- not all middlexboxes are the same. I suggest:
/Many middleboxes read or update UDP port information of the packets that they forward./
[[Lucy]] ack

(59)
[[Lucy]] ack

(60)
/ the GRE-in-UDP Destination Port (TBD), /
- should be:
/one of GRE destination ports (TBD1 or TBD2)/
- You need to add an "IANA NOTE: please update with assigned values"
[[Lucy]] ack

(61)
/and in particular, is never
   sent back to any port used as a UDP Source Port/
- However, the requirement to use ephemeral ports was not a MUST, and hence this isn't really necessarily true, you could have a src port the same as the destination port. This needs more clever use of English.
- Maybe you could say something a little like:
/However, traffic is not expected to be returned back to the UDP Source Port values used to generate entropy./
[[Lucy]] ack

(62)
[[Lucy]] ack

(63)
[[Lucy]] ack

(64)
[[Lucy]] ack

(65)
/process the payload to get the proper parameters to fill into the IP
   header/
- suggest:
/process the tunnelled IP packet headers to retrieve appropriate parameters for the encapsulating IP packet header./
[[Lucy]] ack

(66)
I suggest you add a reference from 3.1 to point to this section.
"Additional information on IP header processing is provided in section 4.3".
[[Lucy]] ack

(67)
[[Lucy]] ack

(68)
/Enabling or disabling the use of checksums/
- The checksum MUST be enabled by default - hence this sentence should really read:
/Disabling the use of checksums/
[[Lucy]] ack

(69) - see note on my earlier position that I do not understand why this draft would not say "SHOULD use an IPv4 checksum" for all cases - with stated reasons for not doing so for the WMON. I do not see a need to updating the guidelines to say "MAY use an IPv4 Checksum".
[[Lucy]] take your suggestion here. This was discussed several times and toggling between "SHOULD" and "MAY". 

(70) part d:
/It is RECOMMENDED that UDP zero-checksum selectively be enabled
        for certain source addresses. /
- That doesn't quite make sense, is this better:
/It is RECOMMENDED that the UDP zero-checksum mode is only enabled for certain selected source addresses. /

(71) part f:
- May also be useful to note that a "Using a fixed UDP source port value can also improve the probability of middlebox traversal."
[[Lucy]] this section is about UDP zero checksum.

(72)

To avoid repeating the RFC2119 clauses please remove the "Otherwise... " sentence, or change /MUST/ to /needs to/.
[[Lucy]] ack

(73)
/Use of GRE checksum is
   recommended when the UDP checksum is not used./
- I agree, please ensure corrections above to ensure this is consistent within the document.
[[Lucy]] ack

(74) 4.2 and 5.2.1 are both called middlebox considerations!
- Maybe rename 4.2 as "Middlebox considerations for source port entropy"
and 5.2.1 as "Middlebox considerations for zero checksums"
[[Lucy]] ack

(75)
It may be MUCH more helpful to place 4.2 and 5.2.1 together in the same section, since then any middlebox vendor or operator could read both together and know what to do. I suggest making section 6 "Middlebox considerations"
[[Lucy]] take your suggestion.

(76)
/When a GRE-in-UDP tunnel carries this type of traffic, use MUST be constrained to a controlled environment (e.g., single
[[Lucy]] ack

(77)
/GRE-in-UDP tunnel can be used in some cases to carry traffic/ Could we change to:
/A GRE-in-UDP tunnel can be used to carry traffic/
[[Lucy]] ack
(78)
/to ensure against congestion/
- to /to manage congestion/
[[Lucy]] ack

(79)
- could we move the default case before the "operator" case, because the flow is much easier to read that way...

i.e., move para starting:
/The default GRE-in-UDP tunnel can be used/ before para starting:
/GRE-in-UDP tunnel can be/
[[Lucy]] ack.

(80)
[[Lucy]] ack

(81)
/listening on the destination port (TBD)./ change to - ports and add IANA note to update.
[[Lucy]] ack

(82) DTLS
The para starting /Datagram Transport Layer Security (DTLS) / is not a security consideration, it is a part of the protocol spec. Please create a new subsection and place the text there. Maybe at the end of section 3?

- I suspect the final security section should then briefly say that DTLS can be used to secure the GRE connection.
[[Lucy]] ack. Create a new section after section 3.

(83) /Corruption of GRE header can cause a privacy and security/ Insert "a" before GRE
[[Lucy]] ack

(A) Two terms are used a WMON and a "controlled environment". While I do agree with the idea of defining this additional usage, I worry about the name given. To me it kind of suggests that "well-managed" and "operator"
are key elements, whereas I think the term "controlled environment" is what really matters. If the safeguards are in place, the usage would seem to apply - even if not an operator network. Would you consider changing this term?
[[Lucy]] change to "traffic-managed controlled environment.

After you say this you can explain (including a MAY in the next sentence), why this could can be relaxed in this specific case. This may be quite OK to say for this case if you state that the encapsulation method is considered robust from errors and that you MAY rely on the integrity checks offered in the encapsulated protocol.
[[Lucy]] let's change to "SHOULD". if someone requests adding additional case that fit "MAY", we will do it. IMO: not need to add additional case to differ "SHOULD" and "MAY".

(c)
[[Lucy]] modified as your suggested.

(d) I disagree with the statement:
", and whether the
   packets in the network are protected by other, possibly stronger
   mechanisms such as the Ethernet CRC."
Ethernet CRC is*NOT* equivalent in any way to transport checksum.  All link-layers really should provide CRCs (RFC3819). If this sentence were to propose an adaption-layer CRC on the header and contents that is endpoint-to-endpoint I'd agree. Otherwise I strongly disagree with the statement.
[[Lucy]] How about: remove this wording?

Regards,
Lucy

---

From: [email-masked]
Date: Tue, 8 Mar 2016 18:00:04 -0000

Answers/responses in-line below,

best wishes,

Gorry

> Hi Gorry,
>
> Thank you very much for the detail review and good comments/suggestions. I
> am OK with most of your suggestions. There are few I proposed alternative
> text. Please see inline below and let me know if those tweak wordings are
> acceptable? If not, what alternatives you like. Once we done, I will
> update the new version to reflect your suggestions.
>
>    encapsulation: (1) General Internet; (2) Traffic-Managed Controlled
> Environment. This controlled environment has
See another message on this topic.

> [[Lucy]] How about remove first and second paragraphs in intro?
GF: I'm OK with your proposal to remove these para, that also would work
for me.

> You perhaps could then start the sentence of the current first para: "Load
> balancing," By saying "One application of a UDP encapsulation is to
> support load balancing..."
>
As above.

> think it would be better to say something like "many routers" or to
> [[Lucy]] comments from 1 to 10 is in first and second para. Thx. If they
> stay, I will modify according your comment.
>
>  (11)
>    additional entropy by way of its source port./ to /and the source port
> field in the UDP header may be used to provide additional entropy./
> [[Lucy]] ack
>
> (12)
> [[Lucy]] how about: do not differentiate the traffic from different
> endpoints, i.e., applying the same treatment for traffic from hosts and
> tunnel endpoints.
>
Works for me.

> avoid congestion happening
You probably should remove /happening/ from the end of the phrase.
I wonder if "avoid" many be taken as too string and perhaps you would be
truer to say
/avoid or manage the occurrence of congestion/

> [[Lucy]] Thx. Will change to "a traffic-managed controlled environment"
OK

> [[Lucy]] How about: A network forming a controlled environment can be
> managed/operated to meet certain conditions while the general Internet
> cannot be; thus tunnel protocol requirements under a controlled
> environment can be less restrictive than the requirements in the general
> Internet.
>
That sounds good, check the text fits in the para, and make sure it reads OK.

> [[Lucy]] how about: This document specifies GRE-in-UDP tunnel usage in the
> general Internet; it also specifies GRE-in-UDP tunnel usage in the
> traffic-managed controlled environment.
>
Sounds correct.

> [[Lucy]] how about: The default usage described in this document refers to
> usage in the general Internet; the conditional usage described in this
> document refers to usage in a traffic-managed controlled environment.
>
Sounds good.

> (27) NOTE: I'm not sure the scope of WMON is correct. I'd have expected
> the scope to be a "Controlled Environment" with a WMON as an example of
OK

> [[Lucy]] how about: This section provides a summary of the requirements
> for a GRE-in-UDP tunnel. Section 1.2.1 describes the default usage of
insert "a"
> GRE-in-UDP tunnel, suitable for the general Internet; Section 1.2.2
> describes a set of relaxed requirements for use in a traffic-managed
> controlled environment
>
OK

> [[Lucy]] how about: The use of the UDP source port MUST be configurable so
> that a single value can be set for all traffic within the tunnel (this
> disables use of the UDP source port to provide flow entropy). When a
> single value is set, a random port SHOULD be selected in order to minimize
> the vulnerability to off-path attacks.[RFC6056]
>
Fine.

> (34) Point 7.
> It may be worth noting that: "All fragments MUST set the DSCP value. Use
> of the ECN field is specified in RFC6040."
> [[Lucy]] why need to mention ECN here? How about: the tunnel ingress MUST
> apply the UDP checksum to all encapsulated fragments so that the tunnel
> egress can validate reassembly of the fragments; it MUST set the same DSCP
> value.
>
I'd expect somewhere in the ID that this states that the RFC6040 applies.
-- but I intended this to say that you may use ECN, but if you do, obey
RFC6040.

> /. To avoid unwanted forwarding over multiple paths the same source UDP
> port value SHOULD be set in all packet fragments./
> [[Lucy]] ack.
>
> (36)
> [[Lucy]] How about: The section lists the changed requirements for a
> conditional GRE-in-UDP Tunnel that is applied to a traffic-managed
> controlled environment. This replaces requirements 1-3 listed in section
> 1.2.1. The requirements 4-7 remain unchanged for a conditional GRE-in-UDP
> Tunnel.
>
OK

> [[Lucy]] do you want "SHOULD"? Which RFC?
UDP checksum MAY be used when encapsulating in IPv4.
- RFC5405bis states:
"Applications SHOULD enable UDP checksums.  For IPv4, [RFC0768]
permits an option to disable their use."

> [[Lucy]] I think it is in bit order, right? I can add a note to clarity.
Just note it.

> "There are two modes for usage of the UDP source port field. The first
> mode assigns a static value to the source port field of all encapsulating
> of entropy by network devices that parse this field."
> [[Lucy]] since thi
>
? unsure what you typed?
> /to avoid reordering with a packet flow, the encapsulator SHOULD use the
> same UDP source port value for all packets assigned to a flow e.g., the
> result of an algorithm that performa a hash of the tunnel ingress and
> egress IP address./
> [[Lucy]] ack
>
> (47)
> This permits network equipment to inspect this value and utilise it during
> forwarding, e.g. to perform ECMP [RFC6438].
> /
> value but does not specify the algorithm that an implementation should use
> to derive this value./
> [[Lucy]] ack
>
> (49)
> /When the UDP checksum is enabled, it protects the GRE payload, resulting
> in the GRE checksum being mostly redundant.
> - English needs fixed, but can we say more? e.g., /The GRE checksum MAY be
> used to provide a payload integrity check when use of UDP zero-checksum./
OK
> - This seems to replicate the text above. I'd really suggest removing it
Sorry I meant to suggest you do not say "broadcast" but say "IPv4 broadcast".

> hence this isn't really necessarily true, you could have a src port the
> parameters for the encapsulating IP packet header./
> [[Lucy]] ack
>
> (66)
> draft would not say "SHOULD use an IPv4 checksum" for all cases - with
> updating the guidelines to say "MAY use an IPv4 Checksum".
If you say "SHOULD" that's really OK with me.

> - May also be useful to note that a "Using a fixed UDP source port value
> can also improve the probability of middlebox traversal."
> To avoid repeating the RFC2119 clauses please remove the "Otherwise... "
> together and know what to do. I suggest making section 6 "Middlebox
> considerations"
> constrained to a controlled environment (e.g., single
> The para starting /Datagram Transport Layer Security (DTLS) / is not a
> security consideration, it is a part of the protocol spec. Please create a
> new subsection and place the text there. Maybe at the end of section 3?
>
> (A) Two terms are used a WMON and a "controlled environment". While I do
> name given. To me it kind of suggests that "well-managed" and "operator"
> are key elements, whereas I think the term "controlled environment" is
> [[Lucy]] let's change to "SHOULD". if someone requests adding additional
> case that fit "MAY", we will do it. IMO: not need to add additional case
> to differ "SHOULD" and "MAY".
>
> (c)
> /When the UDP checksum is enabled, it protects the GRE payload, resulting
> in the GRE checksum being mostly redundant.
> endpoint-to-endpoint I'd agree. Otherwise I strongly disagree with the
> statement.