draft-ietf-tsvwg-ecn-encap-guidelines-08.txt   draft-ietf-tsvwg-ecn-encap-guidelines-09.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft Simula Research Laboratory Internet-Draft Simula Research Laboratory
Updates: 3819 (if approved) J. Kaippallimalil Updates: 3819 (if approved) J. Kaippallimalil
Intended status: Best Current Practice Huawei Intended status: Best Current Practice Huawei
Expires: September 28, 2017 P. Thaler Expires: January 21, 2018 P. Thaler
Broadcom Corporation Broadcom Corporation
March 27, 2017 July 20, 2017
Guidelines for Adding Congestion Notification to Protocols that Guidelines for Adding Congestion Notification to Protocols that
Encapsulate IP Encapsulate IP
draft-ietf-tsvwg-ecn-encap-guidelines-08 draft-ietf-tsvwg-ecn-encap-guidelines-09
Abstract Abstract
The purpose of this document is to guide the design of congestion The purpose of this document is to guide the design of congestion
notification in any lower layer or tunnelling protocol that notification in any lower layer or tunnelling protocol that
encapsulates IP. The aim is for explicit congestion signals to encapsulates IP. The aim is for explicit congestion signals to
propagate consistently from lower layer protocols into IP. Then the propagate consistently from lower layer protocols into IP. Then the
IP internetwork layer can act as a portability layer to carry IP internetwork layer can act as a portability layer to carry
congestion notification from non-IP-aware congested nodes up to the congestion notification from non-IP-aware congested nodes up to the
transport layer (L4). Following these guidelines should assure transport layer (L4). Following these guidelines should assure
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2017. This Internet-Draft will expire on January 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Guidelines in All Cases . . . . . . . . . . . . . . . . . . . 7 3. Guidelines in All Cases . . . . . . . . . . . . . . . . . . . 7
4. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 8 4. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 8
4.1. Feed-Forward-and-Up Mode . . . . . . . . . . . . . . . . 8 4.1. Feed-Forward-and-Up Mode . . . . . . . . . . . . . . . . 8
4.2. Feed-Up-and-Forward Mode . . . . . . . . . . . . . . . . 10 4.2. Feed-Up-and-Forward Mode . . . . . . . . . . . . . . . . 10
4.3. Feed-Backward Mode . . . . . . . . . . . . . . . . . . . 11 4.3. Feed-Backward Mode . . . . . . . . . . . . . . . . . . . 11
4.4. Null Mode . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Null Mode . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion 5. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 13 Notification . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . 14 5.1. IP-in-IP Tunnels with Shim Headers . . . . . . . . . . . 14
5.2. Wire Protocol Design: Indication of ECN Support . . . . . 14 5.2. Wire Protocol Design: Indication of ECN Support . . . . . 15
5.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 16 5.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 17
5.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 18 5.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 19
5.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 19 5.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 20
5.6. Reframing and Congestion Markings . . . . . . . . . . . . 20 5.6. Reframing and Congestion Markings . . . . . . . . . . . . 21
6. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion 6. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 20 Notification . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Feed-Backward Mode: Guidelines for Adding Congestion 7. Feed-Backward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 22 Notification . . . . . . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations (to be removed by RFC Editor) . . . . . . 23 8. IANA Considerations (to be removed by RFC Editor) . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 24 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Outstanding Document Issues . . . . . . . . . . . . 30 Appendix A. Outstanding Document Issues . . . . . . . . . . . . 31
Appendix B. Changes in This Version (to be removed by RFC Appendix B. Changes in This Version (to be removed by RFC
Editor) . . . . . . . . . . . . . . . . . . . . . . 30 Editor) . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
The benefits of Explicit Congestion Notification (ECN) described The benefits of Explicit Congestion Notification (ECN) described
below can only be fully realised if support for ECN is added to the below can only be fully realised if support for ECN is added to the
relevant subnetwork technology, as well as to IP. When a lower layer relevant subnetwork technology, as well as to IP. When a lower layer
buffer drops a packet obviously it does not just drop at that layer; buffer drops a packet obviously it does not just drop at that layer;
the packet disappears from all layers. In contrast, when a lower the packet disappears from all layers. In contrast, when a lower
layer marks a packet with ECN, the marking needs to be explicitly layer marks a packet with ECN, the marking needs to be explicitly
propagated up the layers. The same is true if a buffer marks the propagated up the layers. The same is true if a buffer marks the
skipping to change at page 3, line 52 skipping to change at page 3, line 52
is because drop involves a trade-off between sending a timely is because drop involves a trade-off between sending a timely
signal and trying to avoid impairment, whereas ECN is solely a signal and trying to avoid impairment, whereas ECN is solely a
signal not an impairment, so there is no harm triggering it signal not an impairment, so there is no harm triggering it
earlier. earlier.
Some lower layer technologies (e.g. MPLS, Ethernet) are used to form Some lower layer technologies (e.g. MPLS, Ethernet) are used to form
subnetworks with IP-aware nodes only at the edges. These networks subnetworks with IP-aware nodes only at the edges. These networks
are often sized so that it is rare for interior queues to overflow. are often sized so that it is rare for interior queues to overflow.
However, until recently this was more due to the inability of TCP to However, until recently this was more due to the inability of TCP to
saturate the links. For many years, fixes such as window scaling saturate the links. For many years, fixes such as window scaling
[RFC1323] proved hard to deploy. And the New Reno variant of TCP has [RFC1323] proved hard to deploy. And the Reno variant of TCP has
remained in widespread use despite its inability to scale to high remained in widespread use despite its inability to scale to high
flow rates. However, now that modern operating systems are finally flow rates. However, now that modern operating systems are finally
capable of saturating interior links, even the buffers of well- capable of saturating interior links, even the buffers of well-
provisioned interior switches will need to signal episodes of provisioned interior switches will need to signal episodes of
queuing. queuing.
Propagation of ECN is defined for MPLS [RFC5129], and is being Propagation of ECN is defined for MPLS [RFC5129], and is being
defined for TRILL [RFC7780], [I-D.ietf-trill-ecn-support], but it defined for TRILL [RFC7780], [I-D.ietf-trill-ecn-support], but it
remains to be defined for a number of other subnetwork technologies. remains to be defined for a number of other subnetwork technologies.
Similarly, ECN propagation is yet to be defined for many tunnelling Similarly, ECN propagation is yet to be defined for many tunnelling
protocols. [RFC6040] defines how ECN should be propagated for IP-in- protocols. [RFC6040] defines how ECN should be propagated for IP-in-
IP [RFC2003] and IPsec [RFC4301] tunnels, and it is cited by more IPv4 [RFC2003], IP-in-IPv6 [RFC2473] and IPsec [RFC4301] tunnels, but
recent tunnelling protocols, e.g. Generic UDP Encapsulation (GUE) there are numerous other tunnelling protocols with a shim and/or a
[I-D.ietf-nvo3-gue] and Geneve [I-D.ietf-nvo3-geneve]. However, as layer 2 header between two IP headers (v4 or v6). Some address ECN
Section 9.3 of RFC3168 pointed out, ECN support will need to be propagation between the IP headers, but many do not. This document
defined for other tunnelling protocols, e.g. L2TP [RFC2661], GRE gives guidance on how to address ECN propagation for future
[RFC1701], [RFC2784], PPTP [RFC2637] and GTP [GTPv1], [GTPv1-U], tunnelling protocols, and a companion standards track specification
[GTPv2-C], VXLAN [RFC7348]. [I-D.ietf-tsvwg-rfc6040update-shim] updates those existing IP-shim-
(L2)-IP protocols that are under IETF change control and still widely
used.
Incremental deployment is the most delicate aspect when adding Incremental deployment is the most delicate aspect when adding
support for ECN. The original ECN protocol in IP [RFC3168] was support for ECN. The original ECN protocol in IP [RFC3168] was
carefully designed so that a congested buffer would not mark a packet carefully designed so that a congested buffer would not mark a packet
(rather than drop it) unless both source and destination hosts were (rather than drop it) unless both source and destination hosts were
ECN-capable. Otherwise its congestion markings would never be ECN-capable. Otherwise its congestion markings would never be
detected and congestion would just build up further. However, to detected and congestion would just build up further. However, to
support congestion marking below the IP layer, it is not sufficient support congestion marking below the IP layer, it is not sufficient
to only check that the two end-points support ECN; correct operation to only check that the two transport layer end-points support ECN;
also depends on the decapsulator at each subnet egress faithfully correct operation also depends on the decapsulator at each subnet
propagating congestion notifications to the higher layer. Otherwise, egress faithfully propagating congestion notifications to the higher
a legacy decapsulator might silently fail to propagate any ECN layer. Otherwise, a legacy decapsulator might silently fail to
signals from the outer to the forwarded header. Then the lost propagate any ECN signals from the outer to the forwarded header.
signals would never be detected and again congestion would build up Then the lost signals would never be detected and again congestion
further. The guidelines given later require protocol designers to would build up further. The guidelines given later require protocol
carefully consider incremental deployment, and suggest various safe designers to carefully consider incremental deployment, and suggest
approaches for different circumstances. various safe approaches for different circumstances.
Of course, the IETF does not have standards authority over every link Of course, the IETF does not have standards authority over every link
layer protocol. So this document gives guidelines for designing layer protocol. So this document gives guidelines for designing
propagation of congestion notification across the interface between propagation of congestion notification across the interface between
IP and protocols that may encapsulate IP (i.e. that can be layered IP and protocols that may encapsulate IP (i.e. that can be layered
beneath IP). Each lower layer technology will exhibit different beneath IP). Each lower layer technology will exhibit different
issues and compromises, so the IETF or the relevant standards body issues and compromises, so the IETF or the relevant standards body
must be free to define the specifics of each lower layer congestion must be free to define the specifics of each lower layer congestion
notification scheme. Nonetheless, if the guidelines are followed, notification scheme. Nonetheless, if the guidelines are followed,
congestion notification should interwork between different congestion notification should interwork between different
skipping to change at page 5, line 47 skipping to change at page 5, line 49
The semantics of congestion signals can be relative to the traffic The semantics of congestion signals can be relative to the traffic
class. Therefore correct propagation of congestion signals could class. Therefore correct propagation of congestion signals could
depend on correct propagation of any traffic class field between the depend on correct propagation of any traffic class field between the
layers. In this document, correct propagation of traffic class layers. In this document, correct propagation of traffic class
information is assumed, while what 'correct' means and how it is information is assumed, while what 'correct' means and how it is
achieved is covered elsewhere (e.g. [RFC2983]) and is outside the achieved is covered elsewhere (e.g. [RFC2983]) and is outside the
scope of the present document. scope of the present document.
Note that these guidelines do not require the subnet wire protocol to Note that these guidelines do not require the subnet wire protocol to
be changed to accommodate congestion notification. Another way to be changed to accommodate congestion notification. For instance, the
add congestion notification without consuming header space in the Feed-Up-and-Forward Mode (Section 4.2) and the Null Mode
subnet protocol might be to use a parallel control plane protocol. (Section 4.4) do not. Another way to add congestion notification
without consuming header space in the subnet protocol might be to use
a parallel control plane protocol.
This document focuses on the congestion notification interface This document focuses on the congestion notification interface
between IP and lower layer protocols that can encapsulate IP, where between IP and lower layer protocols that can encapsulate IP, where
the term 'IP' includes v4 or v6, unicast, multicast or anycast. the term 'IP' includes v4 or v6, unicast, multicast or anycast.
However, it is likely that the guidelines will also be useful when a However, it is likely that the guidelines will also be useful when a
lower layer protocol or tunnel encapsulates itself (e.g. Ethernet lower layer protocol or tunnel encapsulates itself (e.g. Ethernet
MAC in MAC [IEEE802.1Qah]) or when it encapsulates other protocols. MAC in MAC [IEEE802.1Qah]) or when it encapsulates other protocols.
In the feed-backward mode, propagation of congestion signals for In the feed-backward mode, propagation of congestion signals for
multicast and anycast packets is out-of-scope (because it would be so multicast and anycast packets is out-of-scope (because it would be so
complicated that it is hoped no-one would attempt such an complicated that it is hoped no-one would attempt such an
skipping to change at page 13, line 31 skipping to change at page 13, line 31
e.g. a non-blocking fat-tree network. An alternative to fat links e.g. a non-blocking fat-tree network. An alternative to fat links
near the root is numerous thin links with multi-path routing to near the root is numerous thin links with multi-path routing to
ensure even worst-case patterns of load cannot congest any link, e.g. ensure even worst-case patterns of load cannot congest any link, e.g.
a Clos network. a Clos network.
5. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion 5. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion
Notification Notification
Feed-forward-and-up is the mode already used for signalling ECN up Feed-forward-and-up is the mode already used for signalling ECN up
the layers through MPLS into IP [RFC5129] and through IP-in-IP the layers through MPLS into IP [RFC5129] and through IP-in-IP
tunnels [RFC6040]. These RFCs take a consistent approach and the tunnels [RFC6040], whether encapsulating with IPv4 [RFC2003], IPv6
following guidelines are designed to ensure this consistency [RFC2473] or IPsec [RFC4301]. These RFCs take a consistent approach
and the following guidelines are designed to ensure this consistency
continues as ECN support is added to other protocols that encapsulate continues as ECN support is added to other protocols that encapsulate
IP. The guidelines are also designed to ensure compliance with the IP. The guidelines are also designed to ensure compliance with the
more general best current practice for the design of alternate ECN more general best current practice for the design of alternate ECN
schemes given in [RFC4774]. schemes given in [RFC4774].
The rest of this section is structured as follows: The rest of this section is structured as follows:
o Section 5.1 addresses the most straightforward cases, where o Section 5.1 addresses the most straightforward cases, where
[RFC6040] can be applied directly to add ECN to tunnels that are [RFC6040] can be applied directly to add ECN to tunnels that are
effectively the same as IP-in-IP tunnels. effectively IP-in-IP tunnels, but with shim header(s) between the
IP headers.
o The subsequent sections give guidelines for adding ECN to a subnet o The subsequent sections give guidelines for adding ECN to a subnet
technology that uses feed-forward-and-up mode like IP, but it is technology that uses feed-forward-and-up mode like IP, but it is
not so similar to IP that [RFC6040] rules can be applied directly. not so similar to IP that [RFC6040] rules can be applied directly.
Specifically: Specifically:
* Sections 5.2, 5.3 and 5.4 respectively address how to add ECN * Sections 5.2, 5.3 and 5.4 respectively address how to add ECN
support to the wire protocol and to the encapsulators and support to the wire protocol and to the encapsulators and
decapsulators at the ingress and egress of the subnet. decapsulators at the ingress and egress of the subnet.
* Section 5.5 deals with the special, but common, case of * Section 5.5 deals with the special, but common, case of
sequences of tunnels or subnets that all use the same sequences of tunnels or subnets that all use the same
technology technology
* Section 5.6 deals with the question of reframing when IP * Section 5.6 deals with the question of reframing when IP
packets do not map 1:1 into lower layer frames. packets do not map 1:1 into lower layer frames.
5.1. IP-in-IP Tunnels with Tightly Coupled Shim Headers 5.1. IP-in-IP Tunnels with Shim Headers
A common pattern for many tunnelling protocols is to encapsulate an A common pattern for many tunnelling protocols is to encapsulate an
inner IP header with shim header(s) then an outer IP header. In many inner IP header with shim header(s) then an outer IP header. A shim
cases the shim header(s) and the outer IP header are always added (or header is defined as one that is not sufficient alone to forward the
removed) as part of the same process. We call this a tightly coupled packet as an outer header. Another common pattern is for a shim to
shim header. Processing the shim and outer together is often encapsulate a layer 2 (L2) header, which in turn encapsulates (or
necessary because the shim(s) are not sufficient for packet might encapsulate) an IP header. [I-D.ietf-tsvwg-rfc6040update-shim]
forwarding in their own right; not unless complemented by an outer clarifies that RFC 6040 is just as applicable when there are shim(s)
header. and possibly a L2 header between two IP headers.
For all such tightly coupled shim headers (such as those listed in However, it is not always feasible or necessary to propagate ECN
the Introduction), the rules in [RFC6040] for propagating the ECN between IP headers when separated by a shim. For instance, it might
field can be applied directly between the inner and outer IP headers. be too costly to dig to arbitrary depths to find an inner IP header,
[I-D.ietf-tsvwg-rfc6040update-shim] clarifies that RFC 6040 is just there may be little or no congestion within the tunnel by design (see
as applicable when there is a tightly-coupled shim between two IP null mode in Section 4.4 above), or a legacy implementation might not
headers as wehen there is not. support ECN. In cases where a tunnel does not support ECN, it is
important that the ingress does not copy the ECN field from an inner
IP header to an outer. Therefore section 4 of
[I-D.ietf-tsvwg-rfc6040update-shim] requires network operators to
configure the ingress of a non-ECN tunnel so that it zeros the ECN
field in the outer IP header.
Nonetheless, in many cases it is feasible to propagate the ECN field
between IP headers separated by shim header(s) and/or a L2 header.
Particularly in the typical case when the outer IP header and the
shim(s) are added (or removed) as part of the same procedure. Even
if the shim(s) encapsulate a L2 header, it is often possible to find
an inner IP header within the L2 header and propagate ECN between
that and the outer IP header. This can be thought of as a special
case of the feed-up-and-forward mode (Section 4.2), so the guidelines
for this mode apply (Section 6).
Numerous shim protocols have been defined for IP tunnelling. More
recent ones e.g. Generic UDP Encapsulation (GUE) [I-D.ietf-nvo3-gue]
and Geneve [I-D.ietf-nvo3-geneve] cite RFC 6040. And some earlier
ones, e.g. CAPWAP [RFC5415] and LISP [RFC6830], cite RFC 3168, which
is compatible with RFC 6040.
However, as Section 9.3 of RFC3168 pointed out, ECN support needs to
be defined for many earlier shim-based tunnelling protocols, e.g.
L2TPv2 [RFC2661], L2TPv3 [RFC3931], GRE [RFC2784], PPTP [RFC2637],
GTP [GTPv1], [GTPv1-U], [GTPv2-C] and Teredo [RFC4380] as well as
some recent ones, e.g. VXLAN [RFC7348] and NVGRE [RFC7637].
All these IP-based encapsulations can be updated in one shot by
simple reference to RFC 6040. However, it would not be appropriate
to update all these protocols from within the present guidance
document. Instead a companion specification
[I-D.ietf-tsvwg-rfc6040update-shim] has been prepared that has
sufficient standards track status to update standards track
protocols. For those that are not under IETF change control
[I-D.ietf-tsvwg-rfc6040update-shim] can only recommend that the
relevant body updates them.
5.2. Wire Protocol Design: Indication of ECN Support 5.2. Wire Protocol Design: Indication of ECN Support
This section is intended to guide the redesign of any lower layer This section is intended to guide the redesign of any lower layer
protocol that encapsulate IP to add native ECN support at the lower protocol that encapsulate IP to add native ECN support at the lower
layer. It reflects the approaches used in [RFC6040] and in layer. It reflects the approaches used in [RFC6040] and in
[RFC5129]. Therefore IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS [RFC5129]. Therefore IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS
encapsulations that already comply with [RFC6040] or [RFC5129] will encapsulations that already comply with [RFC6040] or [RFC5129] will
already satisfy this guidance. already satisfy this guidance.
skipping to change at page 26, line 29 skipping to change at page 27, line 18
nvo3-geneve-04 (work in progress), March 2017. nvo3-geneve-04 (work in progress), March 2017.
[I-D.ietf-nvo3-gue] [I-D.ietf-nvo3-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-ietf-nvo3-gue-05 (work in progress), Encapsulation", draft-ietf-nvo3-gue-05 (work in progress),
October 2016. October 2016.
[I-D.ietf-trill-ecn-support] [I-D.ietf-trill-ecn-support]
Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit
Congestion Notification) Support", draft-ietf-trill-ecn- Congestion Notification) Support", draft-ietf-trill-ecn-
support-02 (work in progress), March 2017. support-03 (work in progress), May 2017.
[I-D.ietf-tsvwg-rfc6040update-shim] [I-D.ietf-tsvwg-rfc6040update-shim]
Briscoe, B., "Propagating Explicit Congestion Notification Briscoe, B., "Propagating Explicit Congestion Notification
Across IP Tunnel Headers Separated by a Shim", draft-ietf- Across IP Tunnel Headers Separated by a Shim", draft-ietf-
tsvwg-rfc6040update-shim-00 (work in progress), November tsvwg-rfc6040update-shim-04 (work in progress), July 2017.
2016.
[I-D.moncaster-tcpm-rcv-cheat] [I-D.moncaster-tcpm-rcv-cheat]
Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to
Allow Senders to Identify Receiver Non-Compliance", draft- Allow Senders to Identify Receiver Non-Compliance", draft-
moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014. moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014.
[IEEE802.1Qah] [IEEE802.1Qah]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Virtual Bridged Local Area Networks--Amendment Networks--Virtual Bridged Local Area Networks--Amendment
6: Provider Backbone Bridges", IEEE Std 802.1Qah-2008, 6: Provider Backbone Bridges", IEEE Std 802.1Qah-2008,
skipping to change at page 27, line 29 skipping to change at page 28, line 14
[LTE-RA] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) [LTE-RA] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA)
and Evolved Universal Terrestrial Radio Access Network and Evolved Universal Terrestrial Radio Access Network
(E-UTRAN); Overall description; Stage 2", Technical (E-UTRAN); Overall description; Stage 2", Technical
Specification TS 36.300. Specification TS 36.300.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, DOI 10.17487/RFC1323, May for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
1992, <http://www.rfc-editor.org/info/rfc1323>. 1992, <http://www.rfc-editor.org/info/rfc1323>.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701,
DOI 10.17487/RFC1701, October 1994,
<http://www.rfc-editor.org/info/rfc1701>.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
DOI 10.17487/RFC2003, October 1996, DOI 10.17487/RFC2003, October 1996,
<http://www.rfc-editor.org/info/rfc2003>. <http://www.rfc-editor.org/info/rfc2003>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol W., and G. Zorn, "Point-to-Point Tunneling Protocol
(PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999, (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999,
<http://www.rfc-editor.org/info/rfc2637>. <http://www.rfc-editor.org/info/rfc2637>.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, DOI 10.17487/RFC2661, August 1999, RFC 2661, DOI 10.17487/RFC2661, August 1999,
<http://www.rfc-editor.org/info/rfc2661>. <http://www.rfc-editor.org/info/rfc2661>.
skipping to change at page 28, line 19 skipping to change at page 29, line 5
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000, RFC 2983, DOI 10.17487/RFC2983, October 2000,
<http://www.rfc-editor.org/info/rfc2983>. <http://www.rfc-editor.org/info/rfc2983>.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, DOI 10.17487/RFC3540, June 2003, RFC 3540, DOI 10.17487/RFC3540, June 2003,
<http://www.rfc-editor.org/info/rfc3540>. <http://www.rfc-editor.org/info/rfc3540>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005,
<http://www.rfc-editor.org/info/rfc3931>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006,
<http://www.rfc-editor.org/info/rfc4380>.
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Ed., "Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification", RFC 5415,
DOI 10.17487/RFC5415, March 2009,
<http://www.rfc-editor.org/info/rfc5415>.
[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages",
RFC 6633, DOI 10.17487/RFC6633, May 2012, RFC 6633, DOI 10.17487/RFC6633, May 2012,
<http://www.rfc-editor.org/info/rfc6633>. <http://www.rfc-editor.org/info/rfc6633>.
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
Pre-Congestion Notification (PCN) States in the IP Header Pre-Congestion Notification (PCN) States in the IP Header
Using a Single Diffserv Codepoint (DSCP)", RFC 6660, Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
DOI 10.17487/RFC6660, July 2012, DOI 10.17487/RFC6660, July 2012,
<http://www.rfc-editor.org/info/rfc6660>. <http://www.rfc-editor.org/info/rfc6660>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>. <http://www.rfc-editor.org/info/rfc7348>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management", Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<http://www.rfc-editor.org/info/rfc7567>. <http://www.rfc-editor.org/info/rfc7567>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<http://www.rfc-editor.org/info/rfc7637>.
[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts, Abstract Mechanism, and Requirements", RFC 7713, Concepts, Abstract Mechanism, and Requirements", RFC 7713,
DOI 10.17487/RFC7713, December 2015, DOI 10.17487/RFC7713, December 2015,
<http://www.rfc-editor.org/info/rfc7713>. <http://www.rfc-editor.org/info/rfc7713>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection Ghanwani, A., and S. Gupta, "Transparent Interconnection
of Lots of Links (TRILL): Clarifications, Corrections, and of Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<http://www.rfc-editor.org/info/rfc7780>. <http://www.rfc-editor.org/info/rfc7780>.
skipping to change at page 30, line 29 skipping to change at page 31, line 29
2. Consider whether an IETF Standard Track doc will be needed to 2. Consider whether an IETF Standard Track doc will be needed to
Update the IP-in-IP protocols listed in Section 5.1--at least Update the IP-in-IP protocols listed in Section 5.1--at least
those that the IETF controls--and which Area it should sit under. those that the IETF controls--and which Area it should sit under.
This issue has been addressed by the production of This issue has been addressed by the production of
[I-D.ietf-tsvwg-rfc6040update-shim], but this text is left [I-D.ietf-tsvwg-rfc6040update-shim], but this text is left
outstanding until that draft is adopted. outstanding until that draft is adopted.
Appendix B. Changes in This Version (to be removed by RFC Editor) Appendix B. Changes in This Version (to be removed by RFC Editor)
From ietf-08 to ietf-09
* Updated para in Intro that listed all the IP-in-IP tunnelling
protocols, to instead refer to draft-ietf-tsvwg-rfc6040update-
shim
* Updated section 5.1 on "IP-in-IP tunnels with Shim Headers" to
summarize guidance that has evolved as rfc6040update-shim has
developed.
From ietf-07 to ietf-08: Refreshed to avoid expiry. Updated
references.
From ietf-06 to ietf-07:
* Added the people involved in liaisons to the acknowledgements.
From ietf-05 to ietf-06: From ietf-05 to ietf-06:
* Introduction: Added GUE and Geneve as examples of tightly * Introduction: Added GUE and Geneve as examples of tightly
coupled shims between IP headers that cite RFC 6040. And added coupled shims between IP headers that cite RFC 6040. And added
VXLAN to list of those that do not. VXLAN to list of those that do not.
* Replaced normative text about tightly coupled shims between IP * Replaced normative text about tightly coupled shims between IP
headers, with reference to new draft-ietf-tsvwg-rfc6040update- headers, with reference to new draft-ietf-tsvwg-rfc6040update-
shim shim
skipping to change at page 30, line 50 skipping to change at page 32, line 20
an example of a well-design protocol that does not need an an example of a well-design protocol that does not need an
indication of ECN support in the wire protocol. indication of ECN support in the wire protocol.
* Encapsulation Guidelines: In the case of a Not-ECN-PDU with a * Encapsulation Guidelines: In the case of a Not-ECN-PDU with a
CE outer, replaced SHOULD be dropped, with explanations of when CE outer, replaced SHOULD be dropped, with explanations of when
SHOULD or MUST are appropriate. SHOULD or MUST are appropriate.
* Feed-Up-and-Forward Mode: Explained examples more carefully, * Feed-Up-and-Forward Mode: Explained examples more carefully,
referred to PDCP and cited UTRAN spec as well as E-UTRAN. referred to PDCP and cited UTRAN spec as well as E-UTRAN.
* Added the people involved in liaisons to the acknowledgements.
* Updated references. * Updated references.
* Marked open issues as resolved, but did not delete Open Issues * Marked open issues as resolved, but did not delete Open Issues
Appendix (yet). Appendix (yet).
From ietf-04 to ietf-05: From ietf-04 to ietf-05:
* Explained why tightly coupled shim headers only "SHOULD" comply * Explained why tightly coupled shim headers only "SHOULD" comply
with RFC 6040, not "MUST". with RFC 6040, not "MUST".
 End of changes. 29 change blocks. 
67 lines changed or deleted 149 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/