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

From: Lucy yong <[email-masked]>
Date: Mon, 31 Aug 2015 13:56:15 +0000

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