draft-ietf-tsvwg-ecn-encap-guidelines-05.txt   draft-ietf-tsvwg-ecn-encap-guidelines-06.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 22, 2016 P. Thaler Expires: January 9, 2017 P. Thaler
Broadcom Corporation Broadcom Corporation
March 21, 2016 July 8, 2016
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-05 draft-ietf-tsvwg-ecn-encap-guidelines-06
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 22, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 21 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 10 4.3. Feed-Backward Mode . . . . . . . . . . . . . . . . . . . 11
4.4. Null Mode . . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . 12 Notification . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . 13 5.1. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . 14
5.2. Wire Protocol Design: Indication of ECN Support . . . . . 14 5.2. Wire Protocol Design: Indication of ECN Support . . . . . 14
5.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 16 5.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 16
5.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 17 5.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 18
5.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 18 5.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 19
5.6. Reframing and Congestion Markings . . . . . . . . . . . . 19 5.6. Reframing and Congestion Markings . . . . . . . . . . . . 20
6. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion 6. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 20 Notification . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Feed-Backward Mode: Guidelines for Adding Congestion 7. Feed-Backward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 21 Notification . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations (to be removed by RFC Editor) . . . . . . 22 8. IANA Considerations (to be removed by RFC Editor) . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 23 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . 24 13.1. Normative References . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Outstanding Document Issues . . . . . . . . . . . . 28 Appendix A. Outstanding Document Issues . . . . . . . . . . . . 30
Appendix B. Changes in This Version (to be removed by RFC Appendix B. Changes in This Version (to be removed by RFC
Editor) . . . . . . . . . . . . . . . . . . . . . . 28 Editor) . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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 4, line 16 skipping to change at page 4, line 16
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.eastlake-trill-ecn-support], but it defined for TRILL [RFC7780], [I-D.eastlake-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. However, as Section 9.3 of IP [RFC2003] and IPsec [RFC4301] tunnels, and it is cited by more
RFC3168 pointed out, ECN support will need to be defined for other recent tunnelling protocols, e.g. Generic UDP Encapsulation (GUE)
tunnelling protocols, e.g. L2TP [RFC2661], GRE [RFC1701], [RFC2784], [I-D.ietf-nvo3-gue] and Geneve [I-D.ietf-nvo3-geneve]. However, as
PPTP [RFC2637] and GTP [GTPv1], [GTPv1-U], [GTPv2-C]. Section 9.3 of RFC3168 pointed out, ECN support will need to be
defined for other tunnelling protocols, e.g. L2TP [RFC2661], GRE
[RFC1701], [RFC2784], PPTP [RFC2637] and GTP [GTPv1], [GTPv1-U],
[GTPv2-C], VXLAN [RFC7348].
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 end-points support ECN; correct operation
also depends on the decapsulator at each subnet egress faithfully also depends on the decapsulator at each subnet egress faithfully
skipping to change at page 13, line 29 skipping to change at page 14, line 16
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 Tightly Coupled 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. In many
cases the shim header(s) always have to be tightly coupled to the cases the shim header(s) and the outer IP header are always added (or
outer IP header because they are not sufficient as outer headers in removed) as part of the same process. We call this a tightly coupled
their own right. In such cases the shim header(s) and the outer IP shim header. Processing the shim and outer together is often
header are always added (or removed) in the same operation. necessary because the shim(s) are not sufficient for packet
Therefore, in all such tightly coupled IP-in-IP tunnelling protocols, forwarding in their own right; not unless complemented by an outer
the rules in [RFC6040] for propagating the ECN field between the two header.
IP headers SHOULD be applied directly. This is written as a 'SHOULD'
not a 'MUST' to allow for the possibility that it might not be
possible to apply the rules of RFC6040 retrospectively. For
instance, even though two (or more) tunnel headers are tightly
coupled, some tunnel implementations might process them on separate
devices.
Examples of tightly coupled IP-in-IP tunnelling protocols where
[RFC6040] SHOULD be applied directly are:
o L2TP [RFC2661]
o GRE [RFC1701], [RFC2784]
o PPTP [RFC2637]
o GTP [GTPv1], [GTPv1-U], [GTPv2-C] For all such tightly coupled shim headers (such as those listed in
o VXLAN [RFC7348]. the Introduction), the rules in [RFC6040] for propagating the ECN
field can be applied directly between the inner and outer IP headers.
[I-D.briscoe-tsvwg-rfc6040bis] clarifies that RFC 6040 is just as
applicable when there is a tightly-coupled shim between two IP
headers as wehen there is not.
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 14, line 47 skipping to change at page 15, line 22
generate ECN markings, guideline 2 above says that all relevant generate ECN markings, guideline 2 above says that all relevant
egress node(s) SHOULD be able to propagate those markings up to the egress node(s) SHOULD be able to propagate those markings up to the
higher layer. higher layer.
In IP, if the ECN field in each PDU is cleared to the Not-ECT (not In IP, if the ECN field in each PDU is cleared to the Not-ECT (not
ECN-capable transport) codepoint, it indicates that the L4 transport ECN-capable transport) codepoint, it indicates that the L4 transport
will not understand congestion markings. A congested buffer must not will not understand congestion markings. A congested buffer must not
mark these Not-ECT PDUs, and therefore drops them instead. mark these Not-ECT PDUs, and therefore drops them instead.
The mechanism a lower layer uses to distinguish the ECN-capability of The mechanism a lower layer uses to distinguish the ECN-capability of
PDUs need not mimic that of IP. All the above guidelines say is that PDUs need not mimic that of IP. The above guidelines merely say that
the lower layer system, as a whole, should achieve the same outcome. the lower layer system, as a whole, should achieve the same outcome.
For instance, ECN-capable feedback loops might use PDUs that are For instance, ECN-capable feedback loops might use PDUs that are
identified by a particular set of labels or tags. Alternatively, identified by a particular set of labels or tags. Alternatively,
logical link protocols that use flow state might determine whether a logical link protocols that use flow state might determine whether a
PDU can be congestion marked by checking for ECN-support in the flow PDU can be congestion marked by checking for ECN-support in the flow
state. Other protocols might depend on out-of-band control signals. state. Other protocols might depend on out-of-band control signals.
The per-domain checking of ECN support in MPLS [RFC5129] is a good The per-domain checking of ECN support in MPLS [RFC5129] is a good
example of a way to avoid sending congestion markings to transports example of a way to avoid sending congestion markings to transports
that will not understand them, without using any header space in the that will not understand them, without using any header space in the
skipping to change at page 15, line 42 skipping to change at page 16, line 19
technologies targeted at zero-configuration deployment or deployment technologies targeted at zero-configuration deployment or deployment
by the general public (e.g. Ethernet). For such 'plug-and-play' by the general public (e.g. Ethernet). For such 'plug-and-play'
environments it will be necessary to invent a failsafe approach that environments it will be necessary to invent a failsafe approach that
ensures congestion markings will never fall into black holes, no ensures congestion markings will never fall into black holes, no
matter how inconsistently a system is put together. Alternatively, matter how inconsistently a system is put together. Alternatively,
congestion notification relying on correct system configuration could congestion notification relying on correct system configuration could
be confined to flavours of Ethernet intended only for professional be confined to flavours of Ethernet intended only for professional
network operators, such as IEEE 802.1ah Provider Backbone Bridges network operators, such as IEEE 802.1ah Provider Backbone Bridges
(PBB). (PBB).
ECN support in TRILL [I-D.eastlake-trill-ecn-support] provides a good
example of how to add ECN to a lower layer protocol without relying
on careful and consistent operator configuration. TRILL provides an
extension header word with space for flags of different categories
depending on whether logic to understand the extension is critical.
The congestion experienced marking has been defined as a 'critical
ingress-to-egress' flag. So if a transit RBridge sets this flag and
an egress RBridge does not have any logic to process it, it will drop
it; which is the desired default action anyway. Therefore TRILL
RBridges can be updated with support for ECN in no particular order
and, at the egress of the TRILL campus, congestion notification will
be propagated to IP as ECN whenever ECN logic has been implemented,
and as drop otherwise.
QCN [IEEE802.1Qau] provides another example of how to indicate to QCN [IEEE802.1Qau] provides another example of how to indicate to
lower layer devices that the end-points will not understand ECN. An lower layer devices that the end-points will not understand ECN. An
operator can define certain 802.1p classes of service to indicate operator can define certain 802.1p classes of service to indicate
non-QCN frames and an ingress bridge is required to map arriving not- non-QCN frames and an ingress bridge is required to map arriving not-
QCN-capable IP packets to one of these non-QCN 802.1p classes. QCN-capable IP packets to one of these non-QCN 802.1p classes.
5.3. Encapsulation Guidelines 5.3. Encapsulation Guidelines
This section is intended to guide the redesign of any node that This section is intended to guide the redesign of any node that
encapsulates IP with a lower layer header when adding native ECN encapsulates IP with a lower layer header when adding native ECN
skipping to change at page 17, line 46 skipping to change at page 18, line 34
outgoing congestion notification field from the inner and outer outgoing congestion notification field from the inner and outer
headers using the following guidelines. If there is any conflict, headers using the following guidelines. If there is any conflict,
rules earlier in the list take precedence over rules later in the rules earlier in the list take precedence over rules later in the
list: list:
1. If the arriving inner header is a Not-ECN-PDU it implies the L4 1. If the arriving inner header is a Not-ECN-PDU it implies the L4
transport will not understand explicit congestion markings. transport will not understand explicit congestion markings.
Then: Then:
* If the outer header carries an explicit congestion marking, * If the outer header carries an explicit congestion marking,
the packet SHOULD be dropped--the only indication of drop is the only indication of congestion that the L4
congestion that the L4 transport will understand. transport will understand. If the congestion marking is the
most severe possible, the packet MUST be dropped. However, if
congestion can be marked with multiple levels severity and the
packet's marking is not the most severe, the packet MAY be
forwarded, but it SHOULD be dropped.
* If the outer is an ECN-PDU that carries no indication of * If the outer is an ECN-PDU that carries no indication of
congestion or a Not-ECN-PDU the PDU SHOULD be forwarded, but congestion or a Not-ECN-PDU the PDU SHOULD be forwarded, but
still as a Not-ECN-PDU. still as a Not-ECN-PDU.
2. If the outer header does not support explicit congestion 2. If the outer header does not support explicit congestion
notification (a Not-ECN-PDU), but the inner header does (an ECN- notification (a Not-ECN-PDU), but the inner header does (an ECN-
PDU), the inner header SHOULD be forwarded unchanged. PDU), the inner header SHOULD be forwarded unchanged.
3. In some lower layer protocols congestion may be signalled as a 3. In some lower layer protocols congestion may be signalled as a
skipping to change at page 20, line 8 skipping to change at page 20, line 50
For instance, an algorithm for marking departing frames could For instance, an algorithm for marking departing frames could
maintain a counter representing the balance of arriving marked octets maintain a counter representing the balance of arriving marked octets
minus departing marked octets. It adds the size of every marked minus departing marked octets. It adds the size of every marked
frame that arrives and if the counter is positive it marks the next frame that arrives and if the counter is positive it marks the next
frame to depart and subtracts its size from the counter. This will frame to depart and subtracts its size from the counter. This will
often leave a negative remainder in the counter, which is deliberate. often leave a negative remainder in the counter, which is deliberate.
6. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion 6. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion
Notification Notification
The guidance in this section is applicable when IP packets: The guidance in this section is applicable, for example, when IP
packets:
o are encapsulated in Ethernet headers; o are encapsulated in Ethernet headers, which have no support for
ECN;
o are forwarded by the eNode-B (base station) of a 3GPP radio access o are forwarded by the eNode-B (base station) of a 3GPP radio access
network, which is required to apply ECN marking during congestion network, which is required to apply ECN marking during congestion,
[LTE-RA]. [LTE-RA], [UTRAN], but the Packet Data Convergence Protocol (PDCP)
that encapsulates the IP header over the radio access has no
support for ECN.
This guidance also generalises to encapsulation by other subnet This guidance also generalises to encapsulation by other subnet
technologies with no native support for explicit congestion technologies with no native support for explicit congestion
notification at the lower layer, but with support for finding and notification at the lower layer, but with support for finding and
processing an IP header. It is unlikely to be applicable or processing an IP header. It is unlikely to be applicable or
necessary for IP-in-IP encapsulation, where feed-forward-and-up mode necessary for IP-in-IP encapsulation, where feed-forward-and-up mode
based on [RFC6040] would be more appropriate. based on [RFC6040] would be more appropriate.
Marking the IP header while switching at layer-2 (by using a layer-3 Marking the IP header while switching at layer-2 (by using a layer-3
switch) or while forwarding in a radio access network seems to switch) or while forwarding in a radio access network seems to
skipping to change at page 25, line 16 skipping to change at page 26, line 16
interface", Technical Specification TS 29.060. interface", Technical Specification TS 29.060.
[GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", Technical Specification TS Protocol User Plane (GTPv1-U)", Technical Specification TS
29.281. 29.281.
[GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS) [GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS)
Tunnelling Protocol for Control plane (GTPv2-C)", Tunnelling Protocol for Control plane (GTPv2-C)",
Technical Specification TS 29.274. Technical Specification TS 29.274.
[I-D.briscoe-tsvwg-rfc6040bis]
Briscoe, B., "Propagating Explicit Congestion Notification
Across IP Tunnel Headers Separated by a Shim", draft-
briscoe-tsvwg-rfc6040bis-00 (work in progress), July 2016.
[I-D.eastlake-trill-ecn-support] [I-D.eastlake-trill-ecn-support]
Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit
Congestion Notification) Support", draft-eastlake-trill- Congestion Notification) Support", draft-eastlake-trill-
ecn-support-00 (work in progress), March 2016. ecn-support-00 (work in progress), March 2016.
[I-D.ietf-nvo3-geneve]
Gross, J. and I. Ganga, "Geneve: Generic Network
Virtualization Encapsulation", draft-ietf-nvo3-geneve-01
(work in progress), January 2016.
[I-D.ietf-nvo3-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-ietf-nvo3-gue-04 (work in progress),
July 2016.
[I-D.ietf-tsvwg-circuit-breaker] [I-D.ietf-tsvwg-circuit-breaker]
Fairhurst, G., "Network Transport Circuit Breakers", Fairhurst, G., "Network Transport Circuit Breakers",
draft-ietf-tsvwg-circuit-breaker-13 (work in progress), draft-ietf-tsvwg-circuit-breaker-15 (work in progress),
February 2016. April 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 28, line 5 skipping to change at page 29, line 16
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>.
[UTRAN] 3GPP, "UTRAN Overall Description", Technical
Specification TS 25.401.
Appendix A. Outstanding Document Issues Appendix A. Outstanding Document Issues
1. [GF] Concern that certain guidelines warrant a MUST (NOT) rather 1. [GF] Concern that certain guidelines warrant a MUST (NOT) rather
than a SHOULD (NOT). Given the guidelines say that if any SHOULD than a SHOULD (NOT). Given the guidelines say that if any SHOULD
(NOT)s are not followed, a strong justification will be needed, (NOT)s are not followed, a strong justification will be needed,
they have been left as SHOULD (NOT) pending further list they have been left as SHOULD (NOT) pending further list
discussion. In particular: discussion. In particular:
* If inner is a Not-ECN-PDU and Outer is CE (or highest severity * If inner is a Not-ECN-PDU and Outer is CE (or highest severity
congestion level), MUST (not SHOULD) drop? congestion level), MUST (not SHOULD) drop?
This issue has been addressed by explaining when SHOULD or
MUST is appropriate.
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
[I-D.briscoe-tsvwg-rfc6040bis], but this text is left 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-05 to ietf-06:
* Introduction: Added GUE and Geneve as examples of tightly
coupled shims between IP headers that cite RFC 6040. And added
VXLAN to list of those that do not.
* Replaced normative text about tightly coupled shims between IP
headers, with reference to new draft-briscoe-tsvwg-rfc6040bis
* Wire Protocol Design: Indication of ECN Support: Added TRILL as
an example of a well-design protocol that does not need an
indication of ECN support in the wire protocol.
* Encapsulation Guidelines: In the case of a Not-ECN-PDU with a
CE outer, replaced SHOULD be dropped, with explanations of when
SHOULD or MUST are appropriate.
* Feed-Up-and-Forward Mode: Explained examples more carefully,
referred to PDCP and cited UTRAN spec as well as E-UTRAN.
* Updated references.
* Marked open issues as resolved, but did not delete Open Issues
Appendix (yet).
From ietf-04 to ietf-05:
* Explained why tightly coupled shim headers only "SHOULD" comply
with RFC 6040, not "MUST".
* Updated references
From ietf-03 to ietf-04: From ietf-03 to ietf-04:
* Addressed Richard Scheffenegger's review comments: primarily * Addressed Richard Scheffenegger's review comments: primarily
editorial corrections, and addition of examples for clarity. editorial corrections, and addition of examples for clarity.
From ietf-02 to ietf-03: From ietf-02 to ietf-03:
* Updated references, ad cited RFC4774. * Updated references, ad cited RFC4774.
From ietf-01 to ietf-02: From ietf-01 to ietf-02:
 End of changes. 26 change blocks. 
60 lines changed or deleted 131 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/