Subject: [tsvwg] FW: I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt

From: Lucy yong <[email-masked]>
Date: Wed, 2 Jul 2014 13:32:47 +0000

Hello,

The new version is uploaded. It addresses the comments in London's meeting, i.e. congestion control, checksum, etc. Please let us know if the description is sufficient in this version. Other comments are welcome.

Thanks,
Lucy

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, July 01, 2014 2:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Area Working Group Working Group of the IETF.

        Title           : Generic UDP Encapsulation for IP Tunneling
        Authors         : Edward Crabbe
                          Lucy Yong
                          Xiaohu Xu
	Filename        : draft-ietf-tsvwg-gre-in-udp-encap-02.txt
	Pages           : 13
	Date            : 2014-07-01

Abstract:
   This document describes a method of encapsulating arbitrary
   protocols within GRE and UDP headers.  In this encapsulation, the
   source UDP port may be used as an entropy field for purposes of load
   balancing while the payload protocol may be identified by the GRE
   Protocol Type.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-gre-in-udp-encap-02

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 08 Jul 2014 16:38:01 +0100

I have some comments on this draft as an individual, please see below:

* First, I think the new revision helps explain some of the questions 
that were highlighted, thanks for preparing the update.

* section 3
"randomly selected constant value, e.g. zero,"
- I don't understand this in two ways:
(1) I don't think it should be zero, I think you could find a hash of 
some internal state to generate a ramdom number. For instance this is 
used in the PIM routing (RFC4601) to specify the genID which is simply a 
unique number each time the system reboots or the session is restarted 
(this has the advantage of reseting state after a reboot).
(2) setting it to zero means you wont have any entropy for ECMP, so why 
is this mode specified in this draft - or is for more general use?

* Section 3 para 3 - "packets destined
    to this assigned UDP destination port [TBD] MAY have their UDP
    checksum set to zero."
I think the first specification here applies only to IPv4, sicne IPv6 
rules are stated later, could you insert "IPv4" before "packets" ?

* Section 3 para 3, says SHOULD use IPv6 UDP Checksum, which is fine, 
but then it leaves open the possibility that an implementation may not 
(i.es.this is more than the base IPv6 sepcification). I think if you 
choose SHOULD rather MUST there should at least be some statement that 
points to RFC6936 (e.g. section 2 explains the function of this check, 
and section 5 decsribes the additional functions that would need to be 
defined to allow this encapsulation to use a zero IPv6 UDP Checksum.)

* Section 3 para 5, The Congestion Control statement is true if the IP 
traffic implements Congestion Control, so I'm not sure I buy "no need to 
apply", and would prefer the statement in RFC 5405, which carefully says:

   "IP-based traffic is generally assumed to be congestion-controlled,
    i.e., it is assumed that the transport protocols generating IP-based
    traffic at the sender already employ mechanisms that are sufficient
    to address congestion on the path.  Consequently, a tunnel carrying
    IP-based traffic should already interact appropriately with other
    traffic sharing the path, and specific congestion control mechanisms
    for the tunnel are not necessary."

- Citing RFC 5405 (or successor) may help clarify this.

* The current revision syas: " In the absence of either, a congestion	
control mechanism SHOULD be implemented at the tunnel ingress and	
egress."
- The "Circuit-Breaker" draft is not really a form of congestion 
control, as currently written. A circuit-breaker is intended primarily 
to terminate traffic that is persistently thought to cause congestion. I 
think this is actually what is intended.

* I am dubious whether it is sufficient to say you need to do 
"something", personally I'd much rather see something that says you MUST 
implement XXXX, and you SHOULD use it under YYY conditions. It would be 
fine to explain that well-provisioned or controlled 
environments...etc... provide other equivalent mechanisms that would 
allow an operator to not use this. I don't see the point in writing a 
spec that says you need to invent another mechanism to deploy it.

- How hard can it be to identify the best type of circuit breaker for 
this case and require the sender and receiver implementers counters per 
source address/source port pair?

* Section 4.
/ Tunnel ingress SHOULD/
^ Insert "the"

* SHOULD perform fragmentation ... and if it does not, then what 
happens, please specify what happens when the recommendation is not applied.

* "impact network performance and user experience."
- true, but I think you should be more precise, e.g. refer to section 
1.3 of RFC6936, where various limitations were explained.

* Section 5
    "Upon receiving this ICMP message, the tunnel
    ingress MUST NOT continue to use GRE-in-UDP encapsulation toward
    this tunnel egress without management intervention."
- but also the ingress MUST validate the IP address originating the ICMP 
message is an address of an active tunnel and MUST evaluate the packet 
header returned in the ICMP payload to ensure the source port is the one 
used for this tunnel. The draft should also note that how to handle 
tunnels carrying other tunnels :-)

Gorry

---

From: Edward Crabbe <[email-masked]>
Date: Tue, 8 Jul 2014 10:44:52 -0700

Gorry, thank you for the comments.  Implicit agreement where not noted,
with explicit disagreements inline:

On Tue, Jul 8, 2014 at 8:38 AM, Gorry Fairhurst <[email-masked]>
wrote:

> * First, I think the new revision helps explain some of the questions that
> were highlighted, thanks for preparing the update.
>
> * section 3
> (1) I don't think it should be zero, I think you could find a hash of some
> internal state to generate a ramdom number. For instance this is used in
> the PIM routing (RFC4601) to specify the genID which is simply a unique
> number each time the system reboots or the session is restarted (this has
> the advantage of reseting state after a reboot).
> (2) setting it to zero means you wont have any entropy for ECMP, so why is
> this mode specified in this draft - or is for more general use?
>
> * Section 3 para 3, says SHOULD use IPv6 UDP Checksum, which is fine, but
> then it leaves open the possibility that an implementation may not
> (i.es.this is more than the base IPv6 sepcification). I think if you choose
> SHOULD rather MUST there should at least be some statement that points to
> RFC6936 (e.g. section 2 explains the function of this check, and section 5
> decsribes the additional functions that would need to be defined to allow
> this encapsulation to use a zero IPv6 UDP Checksum.)
>
> - The "Circuit-Breaker" draft is not really a form of congestion control,
> as currently written. A circuit-breaker is intended primarily to terminate
> traffic that is persistently thought to cause congestion. I think this is
> actually what is intended.
>
> * I am dubious whether it is sufficient to say you need to do "something",
> personally I'd much rather see something that says you MUST implement XXXX,
> and you SHOULD use it under YYY conditions. It would be fine to explain
> that well-provisioned or controlled environments...etc... provide other
> equivalent mechanisms that would allow an operator to not use this. I don't
> see the point in writing a spec that says you need to invent another
> mechanism to deploy it.
>
>
[ed] we had discussed this in reference to the as the transport area
meeting and come to the agreement that SHOULD was sufficient.
 Specifically:  if someone is operating this only on an intradomain basis
without interdomain traversal, they should not have to implement 'the
circuit breaker'.

Regardless, is it sufficient to say that for an interdomain use case where
the traffic is not congestion controlled at the source, a circuitbreaker
MUST be implemented?

> - How hard can it be to identify the best type of circuit breaker for this
> case and require the sender and receiver implementers counters per source
> address/source port pair?
>
> * Section 4.
> / Tunnel ingress SHOULD/
> ^ Insert "the"
>
> * SHOULD perform fragmentation ... and if it does not, then what happens,
> please specify what happens when the recommendation is not applied.
>
> - true, but I think you should be more precise, e.g. refer to section 1.3
> of RFC6936, where various limitations were explained.
>
> * Section 5
> used for this tunnel. The draft should also note that how to handle tunnels
> carrying other tunnels :-)
>
> Gorry
>
>
>> The new version is uploaded. It addresses the comments in London's
>> meeting, i.e. congestion control, checksum, etc. Please let us know if the
>> description is sufficient in this version. Other comments are welcome.
>>
>> Thanks,
>> Lucy
>>
>> 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.
>>

---

From: Lucy yong <[email-masked]>
Date: Tue, 8 Jul 2014 18:43:14 +0000

Hi Gorry,

Yes, thank you for the review and comments. Please see inline.

From: tsvwg [mailto:[email-masked]] On Behalf Of Edward Crabbe
Sent: Tuesday, July 08, 2014 12:45 PM
To: Gorry Fairhurst
Cc: [email-masked]; tsvwg WG
Subject: Re: [tsvwg] FW: I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt

Gorry, thank you for the comments.  Implicit agreement where not noted, with explicit disagreements inline:

On Tue, Jul 8, 2014 at 8:38 AM, Gorry Fairhurst <[email-masked]<mailto:[email-masked]>> wrote:
I have some comments on this draft as an individual, please see below:

* First, I think the new revision helps explain some of the questions that were highlighted, thanks for preparing the update.

* section 3
"randomly selected constant value, e.g. zero,"
- I don't understand this in two ways:
(1) I don't think it should be zero, I think you could find a hash of some internal state to generate a random number. For instance this is used in the PIM routing (RFC4601) to specify the genID which is simply a unique number each time the system reboots or the session is restarted (this has the advantage of reseting state after a reboot).
(2) setting it to zero means you wont have any entropy for ECMP, so why is this mode specified in this draft - or is for more general use?
[Lucy] how about "a randomly selected constant value"? The reason we mention this method here is to address the case when ingress is unable to differentiate the flows from the received packets. In this case, the ingress sets a same value for all the packets. If ingress is able to generate the entropy value from the flows, the entropy value is used at source UDP.
Regarding the method for selecting the value, it simply can use the time value at boot up time. However I prefer to leave the algorithm for selecting the value outside scope of the draft. Will that be acceptable?

* Section 3 para 3 - "packets destined
   to this assigned UDP destination port [TBD] MAY have their UDP
   checksum set to zero."
I think the first specification here applies only to IPv4, sicne IPv6 rules are stated later, could you insert "IPv4" before "packets" ?
[Lucy] OK.

* Section 3 para 3, says SHOULD use IPv6 UDP Checksum, which is fine, but then it leaves open the possibility that an implementation may not (i.es.this is more than the base IPv6 sepcification). I think if you choose SHOULD rather MUST there should at least be some statement that points to RFC6936 (e.g. section 2 explains the function of this check, and section 5 decsribes the additional functions that would need to be defined to allow this encapsulation to use a zero IPv6 UDP Checksum.)
[Lucy] will use "MUST" here. Thus no need to refer to RFC6936.

* Section 3 para 5, The Congestion Control statement is true if the IP traffic implements Congestion Control, so I'm not sure I buy "no need to apply", and would prefer the statement in RFC 5405, which carefully says:

- Citing RFC 5405 (or successor) may help clarify this.
[Lucy] Thanks for the suggestion. We will take your suggestion.

* The current revision syas: " In the absence of either, a congestion
control mechanism SHOULD be implemented at the tunnel ingress and
egress."
- The "Circuit-Breaker" draft is not really a form of congestion control, as currently written. A circuit-breaker is intended primarily to terminate traffic that is persistently thought to cause congestion. I think this is actually what is intended.
[Lucy] We will not describe Circuit-breaker in this draft but cite the CB draft. Terminating traffic is one way to reduce the congestion. Will "congestion handling mechanism" is acceptable?
Lucy

* I am dubious whether it is sufficient to say you need to do "something", personally I'd much rather see something that says you MUST implement XXXX, and you SHOULD use it under YYY conditions. It would be fine to explain that well-provisioned or controlled environments...etc... provide other equivalent mechanisms that would allow an operator to not use this. I don't see the point in writing a spec that says you need to invent another mechanism to deploy it.

[ed] we had discussed this in reference to the as the transport area meeting and come to the agreement that SHOULD was sufficient.  Specifically:  if someone is operating this only on an intradomain basis without interdomain traversal, they should not have to implement 'the circuit breaker'.

Regardless, is it sufficient to say that for an interdomain use case where the traffic is not congestion controlled at the source, a circuitbreaker MUST be implemented?

- How hard can it be to identify the best type of circuit breaker for this case and require the sender and receiver implementers counters per source address/source port pair?

* Section 4.
/ Tunnel ingress SHOULD/
^ Insert "the"

* SHOULD perform fragmentation ... and if it does not, then what happens, please specify what happens when the recommendation is not applied.

* "impact network performance and user experience."
- true, but I think you should be more precise, e.g. refer to section 1.3 of RFC6936, where various limitations were explained.

* Section 5
   "Upon receiving this ICMP message, the tunnel
   ingress MUST NOT continue to use GRE-in-UDP encapsulation toward
   this tunnel egress without management intervention."
- but also the ingress MUST validate the IP address originating the ICMP message is an address of an active tunnel and MUST evaluate the packet header returned in the ICMP payload to ensure the source port is the one used for this tunnel. The draft should also note that how to handle tunnels carrying other tunnels :-)

Gorry

Thanks,
Lucy

-----Original Message-----
From: tsvwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, July 01, 2014 2:26 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt

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<http://tools.ietf.org>.

---

From: [email-masked]
Date: Tue, 8 Jul 2014 20:56:31 +0100

Thanks, See some responses in-line,

Gorry

> On Tue, Jul 8, 2014 at 8:38 AM, Gorry Fairhurst
> <[email-masked]<mailto:[email-masked]>> wrote:
> internal state to generate a random number. For instance this is used in
> [Lucy] how about "a randomly selected constant value"? The reason we
> mention this method here is to address the case when ingress is unable to
> differentiate the flows from the received packets. In this case, the
> ingress sets a same value for all the packets. If ingress is able to
> generate the entropy value from the flows, the entropy value is used at
> source UDP.
> Regarding the method for selecting the value, it simply can use the time
> value at boot up time. However I prefer to leave the algorithm for
> selecting the value outside scope of the draft. Will that be acceptable?
>
GF: That makes sense - I agree, you could give an example, but I wouldn't
expect the ID to specify the algorithm for initialising the value.

> points to RFC6936 (e.g. section 2 explains the function of this check, and
> section 5 decsribes the additional functions that would need to be defined
> to allow this encapsulation to use a zero IPv6 UDP Checksum.)
GF: Either way works for me. MUST for IPv6 is obviously easy to get
agreement upon.

> [Lucy] We will not describe Circuit-breaker in this draft but cite the CB
> draft. Terminating traffic is one way to reduce the congestion.
> Will  "congestion handling mechanism" be acceptable?
>
GF: I think that is better.
> personally I'd much rather see something that says you MUST implement
> XXXX, and you SHOULD use it under YYY conditions. It would be fine to
> explain that well-provisioned or controlled environments...etc... provide
> other equivalent mechanisms that would allow an operator to not use this.
> I don't see the point in writing a spec that says you need to invent
> another mechanism to deploy it.
>
GF: That's where we differ, but we need to be precise - I'm not saying an
operator MUST use the Circuit breaker, because clearly there are
operational characteristics of a network that may mean the operator
already has mechanisms to deal with overload.

However. the question is whether the implementor needs to provides the
mechanism, to allow the operator to enable or disable the feature. This is
about what needs to be specified to conform - assuming that a lightweight
circuit breaker is possible at design time, but we know from other
experience is really hard to introduce afterwards to a deployed protocol.

> the traffic is not congestion controlled at the source, a circuitbreaker
GF: Probably correct. But see above. It is possible to use words such as
MUST be supported and SHOULD be enabled by default.
> From: tsvwg [mailto:[email-masked]<mailto:[email-masked]>]
> On Behalf Of [email-masked]<mailto:[email-masked]>
> tools.ietf.org<http://tools.ietf.org>.
>