Document shepherd write-up:
GRE-in-UDP Encapsulation
draft-ietf-tsvwg-gre-in-udp-encap-13
1. Summary
Document Shepherd: David Black
Responsible AD: Spencer Dawkins
This document specifies a method of encapsulating network protocol
packet within GRE and UDP headers. This GRE-in-UDP encapsulation
allows the UDP source port field to be used as an entropy field.
This may be used for load balancing of GRE traffic in transit
networks using existing ECMP mechanisms. This document also
specifies GRE-in-UDP tunnel requirements for two applicability
scenarios: (1) general Internet; (2) a traffic-managed controlled
environment. The controlled environment has less restrictive
requirements than the general Internet.
This draft requires the GRE and UDP tunnel endpoints to coincide (both
the GRE and UDP headers have to be applied and removed as a pair).
This draft does not cover scenarios where arriving GRE traffic is
UDP-encapsulated and/or GRE traffic is forwarded after UDP decapsulation.
The WG has requested Proposed Standard status because this draft
specifies a protocol that is intended for use in the Internet.
2. Review and Consensus
The Transport Area WG (TSVWG) is a collection of people with varied
interests that don't individually justify their own working groups.
This draft is supported by the portion of the tsvwg working group that
is familiar with and interested in UDP encapsulation. The draft has
received significant review and critique from a number of Transport
experts, including the draft shepherd, and has undergone significant
modification as a result. These reviews and related work on this draft
have resultings in several changes to the UDP guidelines draft
(also in TSVWG - rfc5405bis) - this GRE/UDP draft is now aligned with
that UDP guidelines draft.
This GRE/UDP draft has had a long history - it originally replaced an
earlier draft that proposed encapsulation of arbitrary protocols in
UDP without a shim header (draft-yong-tsvwg-udp-encap-4-ip-tunneling).
This replacement focused nitial work on a single encapsulated protocol,
GRE. The resulting draft then got caught up in the UDP encapsulation
adventure set off by the initial (failed) IETF Last Call on the
MPLS/UDP draft.
A design team was formed to work out the Transport issues affecting
both drafts, primarily requirements for omission of UDP checksums for
IPv6 (these cannot be simply stated by reference to RFCs 6935 sand 6936,
because some of the requirments apply to protocol design) and congestion
control (MPLS/UDP turned out to only be deployable by network operators,
and hence can rely to a large extent on network operator provisioning
and traffic management). The design team's work on these two problems
(and some additional concerns) lead to the publication of the MPLS/UDP
draft as RFC 7510 in April 2015, with the expectation that RFC publication
of the GRE/UDP draft would follow shortly thereafter.
Unfortunately, that didn't happen - the underlying cause is that it was
not feasible to specify a single set of requirements that cover both
network operator usage of GRE/UDP (Controlled Environment) and general
Internet usage (the latter does not apply to MPLS/UDP). The GRE/UDP
draft was revised to specify requirements for both applicability
scenarios. Multiple reviews by Transport experts have been performed
on this draft subsequent to that revision, revision was done, and the
shepherd belives that the draft is now (finally) ready for RFC
Publication.
3. Intellectual Property
Each draft author has stated his/her direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.
4. Other Points
Versions of this specification have been reported for both BSD and
Linux, although they may not be current with the revision being
forwarded for publication yet.
From the AD: The document shepherd and authors reported that Gorry
Fairhurst and Jouni Korhonen both provided reviews with significant
impact on the specification. The working group solicited reviews from
Donald Eastlake III and Eliot Lear late in the process, and these
reviews did not identify significant new issues.
There is a normative reference to draft-ietf-tsvwg-rfc5405bis, which has
already been submitted to the IESG for RFC publication.
idnits 2.14.01 didn't find any nits.
The IANA considerations (two port assignments) are clear.