Subject: Re: [tsvwg] GRE/UDP scope (draft-ietf-tsvww-gre-in-udp-encap)

From: Lucy yong <[email-masked]>
Date: Wed, 2 Sep 2015 19:37:12 +0000

Hi,

Gorry made some suggestions on the previous text. Here is the revised the text accordingly.

In Prague, we discussed what should be the scope for this protocol: applying it to the Internet and/or a specific network. It seems valuable to apply to both but the requirements/implementations in these cases have notable difference. David suggested addressing these cases separately and specifying requirements/implementations accordingly. Here are highlight of the requirements/implementations for the Internet and differences in a well-defined operation network.

A) As default, GRE/UDP encap. can be used over an IP network including the Internet. GRE/UDP tunnel EPs:

1.     SHOULD perform UDP checksum when over an IPv4 network.

2.     MUST perform UDP checksum when over an IPv6 network.

3.     IP-traffic can be assumed to be congestion-controlled; other tunneled protocol/payload SHOULD implement an appropriate congestion control method because the GRE/UDP tunnel does not itself provide any congestion control. If the tunneled traffic does not implement an appropriate congestion control the GRE/UDP tunnel SHOULD NOT be used across the general Internet. Within a well-managed operator network (see second use case), other mechanisms

SHOULD be used to protect the network, (e.g., use of pre-provisioned capacity or

a circuit breaker mechanism [CK]).

4.     UDP src port that is used for flow entropy SHOULD be set to a UDP ephemeral port (49152-65535).

5.     For IPv6 delivery network, if IPv6 flow label load balancing is supported [RFC4638], the flow entropy SHOULD also be placed in the flow label field.

6.     If a tunnel ingress fragments the incoming packet (before encapsulation), the UDP checksum MUST be used so that the receiving endpoint can validate reassembly of the fragments, and the same src UDP port SHOULD be used for all packet fragments to ensure that the transit routers will forward the packet fragments on the same path.

7.     If the incoming packet needs to be fragmented, it SHOULD be done before the encapsulation [RFC7588] and calculate the size of fragments based on the MTU and including the size of the UDP header.

B) GRE/UDP tunnel may be used within a well-managed operator network where 1) the network lower layer is monitored so that packet corruption is unlike to impact user traffic; 2) the network is traffic-engineered and/or operated to avoid congestion. In this case, tunnel EPs MAY use the default mode or a simpler implementation; the simpler implementation is specified below when all stated conditions (specified below) are satisfied.

1.     When over an IPv4 network, SHOULD set UDP zero-checksum to improve the tunnel performance.

2.     When over an IPv6 network, MUST perform UDP checksum as default but MAY be configured with UDP zero-checksum if at least one of three conditions (a. corruption is extremely unlikely; b. history shows the level of packet corruption is tolerably low; c. tunneled applications are tolerable of mis-delivered or corrupted packet.) is satisfied. When using UDP zero-checksum, tunnel EP MUST also meet the implementation requirements as follows:

   a.  Use of the UDP checksum with IPv6 MUST be the default

       configuration of all GRE/UDP implementations.

   b.  The GRE/UDP implementation MUST comply with all requirements

       specified in Section 4 of [RFC6936] and with requirement 1

       specified in Section 5 of [RFC6936].

   c.  The tunnel decapsulator SHOULD only allow the use of UDP zero-

       checksum mode for IPv6 on a single received UDP Destination Port

       regardless of the encapsulator.  The motivation for this

       requirement is possible corruption of the UDP Destination Port,

       which may cause packet delivery to the wrong UDP port.  If that

       other UDP port requires the UDP checksum, the misdelivered packet

       will be discarded

   d.  The tunnel decapsulator MUST check that the source and

       destination IPv6 addresses are valid for the MPLS-in-UDP tunnel

       on which the packet was received if that tunnel uses UDP zero-

       checksum mode and discard any packet for which this check fails.

   e.  The tunnel encapsulator SHOULD use different IPv6 addresses for

       each GRE/UDP tunnel that uses UDP zero-checksum mode

       (regardless of decapsulator) in order to strengthen the

       decapsulator's check of the IPv6 source address (i.e., the same

       IPv6 source address SHOULD NOT be used with more than one IPv6

       destination address, independent of whether that destination

       address is a unicast or multicast address).  When this is not

       possible, it is RECOMMENDED to use each source IPv6 address for

       as few UDP zero-checksum mode GRE/UDP tunnels (i.e., with as

       few destination IPv6 addresses) as is feasible.

   f.  When any middlebox exists on the path of GRE/UDP tunnel, it is RECOMMENDED

       to use the default mode to reduce the chance that the encapsulated packets

       to be dropped;

   g. Any middle box for UDP zero-checksum mode for IPv6 MUST comply with

      requirements 1 and 8-10 in Section 5 of [RFC6936].

   h.  Measures SHOULD be taken to prevent IPv6 traffic with zero UDP

       checksums from "escaping" to the general Internet; see Section 5 of RFC5710

       for examples of such measures.

   i.  IPv6 traffic with zero UDP checksums MUST be actively monitored

       for errors by the network operator.

j.  GRE checksum (or GRE key) SHOULD be used for the GRE header/payload (or GRE header only) integrity check. It is RECOMMENDED that GRE/UDP tunnel EPs use either a UDP checksum or a GRE checksum (or GRE key) for integrity check.

3.     A tunnel may encapsulate a protocol/payload that does not provide congestion control or a circuit breaker mechanism because the delivery network is traffic-engineered and/or operated by the network operator to avoid congestion, e.g. utilize a managed circuit breaker [CK].

4-7.  no change.

Welcome comment/suggestion on these points.

Thank you, Gorry.

Regards,

Lucy

From: Lucy yong
Sent: Monday, August 31, 2015 8:56 AM
To: [email-masked]'
Cc: [email-masked]'
Subject: GRE/UDP scope (draft-ietf-tsvww-gre-in-udp-encap)

Hi All,

In Prague, we discussed what should be the scope for this protocol: applying it to the Internet and/or a specific network. It seems valuable to apply to both but the requirements/implementations in these cases have notable difference. David suggested addressing these cases separately and specified requirements/implementations accordingly. Here are highlight of the requirements/implementations for the Internet and differences in a well-defined operation network.

1) As default, GRE/UDP encap. can be used over an IP network including the Internet. GRE/UDP tunnel EPs:

a.     SHOULD perform UDP checksum when over an IPv4 network.

b.     MUST perform UDP checksum when over an IPv6 network.

c.     Tunneled protocol/payload SHOULD handle the congestion control because GRE/UDP tunnel does not support any congestion control. As a result, some applications are excluded. The Section 3.1.9 of [RFC5405bis] describes three common tunnel cases that may or may not apply to GRE/UDP tunnel.

    1. IP-based traffic.  Apply, IP application handles congestion control.

    2. Non-IP-based traffic. Not Apply unless there is reserved path capacity (see case of a well-managed operator network).

    3. Traffic amplification. N/A, as GRE does not send additional packets.

d.     UDP src port that is used for flow entropy SHOULD be set to a UDP ephemeral port (49152-65535).

e.     For IPv6 delivery network, if IPv6 flow label load balancing is supported, the flow entropy SHOULD also be placed in the flow label field.

f.     If tunnel ingress fragments the incoming packet (before encapsulation), UDP checksum MUST be used, and the same src UDP port MUST be used for all packet fragments to ensure that the transit routers will forward the packet fragments on the same path.

g.     If the incoming packet needs to be fragmented, it should be done before the encapsulation [RFC7588] and UDP header should be factor into the allowed MTU.

2) GRE/UDP tunnel may be used within a well-managed operator network where the network lower layer is robust and monitored so that packet corruption is extremely unlike and the network is traffic-engineered and/or operated to avoid congestion. In this case, tunnel EPs and tunneled protocol/payload do not have to implement all the functions as of the default case; simplified implementations as follows are allowed when all stated conditions (highlight below) are satisfied.

a.     When over an IPv4 network, SHOULD set UDP zero-checksum to improve the tunnel performance.

b.     When over an IPv6 network, MUST perform UDP checksum as default but MAY be configured with UDP zero-checksum if one of three conditions (a,b,c) stated in Section 3.1 of RFC7510 is satisfied. When using UDP zero-checksum, tunnel EP MUST also meet the implementation requirement a-e specified in Section 3.1 of RFC7510 in the context of GRE/UDP; the network MUST implement the requirement g-h specified in Section 3.1 of RFC7510. If tunneled packets may traverse some middle box, to avoid the tunneled packets to be dropped there [RFC5405bis], use of the default method is more suitable. GRE checksum (or GRE key) SHOULD be used for GRE header/payload (or GRE header only) protection. It is RECOMMEND that GRE/UDP tunnel EPs do not use UDP checksum and GRE checksum at the same time, which has some redundant and lowers tunnel performance.

c.     Tunneled protocol/payload is allowed not having congestion control mechanism because the delivery network is traffic-engineered and/or operated to avoid congestion.

d-g.  no change.

Welcome comments/suggestions. We like to get the WG censuses first on these points, then update the draft.

Thank David and Gorry to help on these.

Thanks,

Lucy on behalf of co-authors