draft-ietf-tsvwg-ecn-encap-guidelines-09.txt   draft-ietf-tsvwg-ecn-encap-guidelines-10.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: January 21, 2018 P. Thaler Expires: September 19, 2018 P. Thaler
Broadcom Corporation Broadcom Corporation
July 20, 2017 March 18, 2018
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-09 draft-ietf-tsvwg-ecn-encap-guidelines-10
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 35 skipping to change at page 1, line 35
mechanisms, whether specified by the IETF or other standards bodies. mechanisms, whether specified by the IETF or other standards bodies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 January 21, 2018. This Internet-Draft will expire on September 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
7. Feed-Backward Mode: Guidelines for Adding Congestion 7. Feed-Backward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 23 Notification . . . . . . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations (to be removed by RFC Editor) . . . . . . 24 8. IANA Considerations (to be removed by RFC Editor) . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 25 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . 26 13.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Outstanding Document Issues . . . . . . . . . . . . 31 Appendix A. Changes in This Version (to be removed by RFC
Appendix B. Changes in This Version (to be removed by RFC
Editor) . . . . . . . . . . . . . . . . . . . . . . 31 Editor) . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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 14, line 50 skipping to change at page 14, line 50
between IP headers separated by shim header(s) and/or a L2 header. 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 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 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 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 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 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 case of the feed-up-and-forward mode (Section 4.2), so the guidelines
for this mode apply (Section 6). for this mode apply (Section 6).
Numerous shim protocols have been defined for IP tunnelling. More Numerous shim protocols have been defined for IP tunnelling. More
recent ones e.g. Generic UDP Encapsulation (GUE) [I-D.ietf-nvo3-gue] recent ones e.g. Generic UDP Encapsulation (GUE)
and Geneve [I-D.ietf-nvo3-geneve] cite RFC 6040. And some earlier [I-D.ietf-intarea-gue] and Geneve [I-D.ietf-nvo3-geneve] cite and
ones, e.g. CAPWAP [RFC5415] and LISP [RFC6830], cite RFC 3168, which follow RFC 6040. And some earlier ones, e.g. CAPWAP [RFC5415] and
is compatible with RFC 6040. LISP [RFC6830], cite RFC 3168, which is compatible with RFC 6040.
However, as Section 9.3 of RFC3168 pointed out, ECN support needs to However, as Section 9.3 of RFC 3168 pointed out, ECN support needs to
be defined for many earlier shim-based tunnelling protocols, e.g. be defined for many earlier shim-based tunnelling protocols, e.g.
L2TPv2 [RFC2661], L2TPv3 [RFC3931], GRE [RFC2784], PPTP [RFC2637], L2TPv2 [RFC2661], L2TPv3 [RFC3931], GRE [RFC2784], PPTP [RFC2637],
GTP [GTPv1], [GTPv1-U], [GTPv2-C] and Teredo [RFC4380] as well as GTP [GTPv1], [GTPv1-U], [GTPv2-C] and Teredo [RFC4380] as well as
some recent ones, e.g. VXLAN [RFC7348] and NVGRE [RFC7637]. some recent ones, e.g. VXLAN [RFC7348], NVGRE [RFC7637] and NSH
[RFC8300].
All these IP-based encapsulations can be updated in one shot by All these IP-based encapsulations can be updated in one shot by
simple reference to RFC 6040. However, it would not be appropriate simple reference to RFC 6040. However, it would not be appropriate
to update all these protocols from within the present guidance to update all these protocols from within the present guidance
document. Instead a companion specification document. Instead a companion specification
[I-D.ietf-tsvwg-rfc6040update-shim] has been prepared that has [I-D.ietf-tsvwg-rfc6040update-shim] has been prepared that has
sufficient standards track status to update standards track sufficient standards track status to update standards track
protocols. For those that are not under IETF change control protocols. For those that are not under IETF change control
[I-D.ietf-tsvwg-rfc6040update-shim] can only recommend that the [I-D.ietf-tsvwg-rfc6040update-shim] can only recommend that the
relevant body updates them. relevant body updates them.
skipping to change at page 17, line 24 skipping to change at page 17, line 24
on careful and consistent operator configuration. TRILL provides an on careful and consistent operator configuration. TRILL provides an
extension header word with space for flags of different categories extension header word with space for flags of different categories
depending on whether logic to understand the extension is critical. depending on whether logic to understand the extension is critical.
The congestion experienced marking has been defined as a 'critical The congestion experienced marking has been defined as a 'critical
ingress-to-egress' flag. So if a transit RBridge sets this flag and 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 an egress RBridge does not have any logic to process it, it will drop
it; which is the desired default action anyway. Therefore TRILL it; which is the desired default action anyway. Therefore TRILL
RBridges can be updated with support for ECN in no particular order RBridges can be updated with support for ECN in no particular order
and, at the egress of the TRILL campus, congestion notification will and, at the egress of the TRILL campus, congestion notification will
be propagated to IP as ECN whenever ECN logic has been implemented, be propagated to IP as ECN whenever ECN logic has been implemented,
and as drop otherwise. or 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
skipping to change at page 24, line 30 skipping to change at page 24, line 30
congestion signals between layers raises potential signal integrity congestion signals between layers raises potential signal integrity
concerns. Experimental or proposed approaches exist for assuring the concerns. Experimental or proposed approaches exist for assuring the
end-to-end integrity of in-band congestion signals, e.g.: end-to-end integrity of in-band congestion signals, e.g.:
o Congestion exposure (ConEx ) for networks to audit that their o Congestion exposure (ConEx ) for networks to audit that their
congestion signals are not being suppressed by other networks or congestion signals are not being suppressed by other networks or
by receivers, and for networks to police that senders are by receivers, and for networks to police that senders are
responding sufficiently to the signals, irrespective of the responding sufficiently to the signals, irrespective of the
transport protocol used [RFC7713]. transport protocol used [RFC7713].
o The ECN nonce [RFC3540] for a TCP sender to detect whether a o A test for a sender to detect whether a network or the receiver is
network or the receiver is suppressing congestion signals. suppressing congestion signals (for example see
[I-D.moncaster-tcpm-rcv-cheat]).
o A test with the same goals as the ECN nonce, but without the need
for the receiver to co-operate with the protocol
[I-D.moncaster-tcpm-rcv-cheat].
Given these end-to-end approaches are already being specified, it Given these end-to-end approaches are already being specified, it
would make little sense to attempt to design hop-by-hop congestion would make little sense to attempt to design hop-by-hop congestion
signal integrity into a new lower layer protocol, because end-to-end signal integrity into a new lower layer protocol, because end-to-end
integrity inherently achieves hop-by-hop integrity. integrity inherently achieves hop-by-hop integrity.
10. Conclusions 10. Conclusions
Following the guidance in the document enables ECN support to be Following the guidance in the document enables ECN support to be
extended to numerous protocols that encapsulate IP (v4 & v6) in a extended to numerous protocols that encapsulate IP (v4 & v6) in a
consistent way, so that IP continues to fulfil its role as an end-to- consistent way, so that IP continues to fulfil its role as an end-to-
end interoperability layer. This includes: end interoperability layer. This includes:
o A wide range of tunnelling protocols with various forms of shim o A wide range of tunnelling protocols including those with various
header between two IP headers; forms of shim header between two IP headers, possibly also
separated by a L2 header;
o A wide range of subnet technologies, particularly those that work o A wide range of subnet technologies, particularly those that work
in the same 'feed-forward-and-up' mode that is used to support ECN in the same 'feed-forward-and-up' mode that is used to support ECN
in IP and MPLS. in IP and MPLS.
Guidelines have been defined for supporting propagation of ECN Guidelines have been defined for supporting propagation of ECN
between Ethernet and IP on so-called Layer-3 Ethernet switches, using between Ethernet and IP on so-called Layer-3 Ethernet switches, using
a 'feed-up-an-forward' mode. This approach could enable other subnet a 'feed-up-an-forward' mode. This approach could enable other subnet
technologies to pass ECN signals into the IP layer, even if they do technologies to pass ECN signals into the IP layer, even if they do
not support ECN natively. not support ECN natively.
skipping to change at page 25, line 51 skipping to change at page 25, line 47
addressed to the IETF Transport Area working group mailing list addressed to the IETF Transport Area working group mailing list
<tsvwg@ietf.org>, and/or to the authors. <tsvwg@ietf.org>, and/or to the authors.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, DOI 10.17487/RFC3819, July 2004, RFC 3819, DOI 10.17487/RFC3819, July 2004,
<http://www.rfc-editor.org/info/rfc3819>. <https://www.rfc-editor.org/info/rfc3819>.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the [RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field", BCP 124, Explicit Congestion Notification (ECN) Field", BCP 124,
RFC 4774, DOI 10.17487/RFC4774, November 2006, RFC 4774, DOI 10.17487/RFC4774, November 2006,
<http://www.rfc-editor.org/info/rfc4774>. <https://www.rfc-editor.org/info/rfc4774>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <http://www.rfc-editor.org/info/rfc5129>. 2008, <https://www.rfc-editor.org/info/rfc5129>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <http://www.rfc-editor.org/info/rfc6040>. 2010, <https://www.rfc-editor.org/info/rfc6040>.
13.2. Informative References 13.2. Informative References
[ATM-TM-ABR] [ATM-TM-ABR]
Cisco, "Understanding the Available Bit Rate (ABR) Service Cisco, "Understanding the Available Bit Rate (ABR) Service
Category for ATM VCs", Design Technote 10415, June 2005. Category for ATM VCs", Design Technote 10415, June 2005.
[Buck00] Buckwalter, J., "Frame Relay: Technology and Practice", [Buck00] Buckwalter, J., "Frame Relay: Technology and Practice",
Pub. Addison Wesley ISBN-13: 978-0201485240, 2000. Pub. Addison Wesley ISBN-13: 978-0201485240, 2000.
skipping to change at page 27, line 5 skipping to change at page 26, line 49
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.ietf-intarea-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-ietf-intarea-gue-05 (work in
progress), December 2017.
[I-D.ietf-nvo3-geneve] [I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf- Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-04 (work in progress), March 2017. nvo3-geneve-06 (work in progress), March 2018.
[I-D.ietf-nvo3-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-ietf-nvo3-gue-05 (work in progress),
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 (TRansparent
Interconnection of Lots of Links): ECN (Explicit
Congestion Notification) Support", draft-ietf-trill-ecn- Congestion Notification) Support", draft-ietf-trill-ecn-
support-03 (work in progress), May 2017. support-07 (work in progress), February 2018.
[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-04 (work in progress), July 2017. tsvwg-rfc6040update-shim-05 (work in progress), November
2017.
[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 12 skipping to change at page 28, line 12
<http://ieeexplore.ieee.org/xpl/ <http://ieeexplore.ieee.org/xpl/
mostRecentIssue.jsp?punumber=5454061>. mostRecentIssue.jsp?punumber=5454061>.
[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, <https://www.rfc-editor.org/info/rfc1323>.
[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>. <https://www.rfc-editor.org/info/rfc2003>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <http://www.rfc-editor.org/info/rfc2473>. December 1998, <https://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>. <https://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>. <https://www.rfc-editor.org/info/rfc2661>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<http://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
Explicit Congestion Notification (ECN) in IP Networks", Explicit Congestion Notification (ECN) in IP Networks",
RFC 2884, DOI 10.17487/RFC2884, July 2000, RFC 2884, DOI 10.17487/RFC2884, July 2000,
<http://www.rfc-editor.org/info/rfc2884>. <https://www.rfc-editor.org/info/rfc2884>.
[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>. <https://www.rfc-editor.org/info/rfc2983>.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, DOI 10.17487/RFC3540, June 2003,
<http://www.rfc-editor.org/info/rfc3540>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)", "Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005, RFC 3931, DOI 10.17487/RFC3931, March 2005,
<http://www.rfc-editor.org/info/rfc3931>. <https://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, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006, DOI 10.17487/RFC4380, February 2006,
<http://www.rfc-editor.org/info/rfc4380>. <https://www.rfc-editor.org/info/rfc4380>.
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Ed., "Control And Provisioning of Wireless Access Points Ed., "Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification", RFC 5415, (CAPWAP) Protocol Specification", RFC 5415,
DOI 10.17487/RFC5415, March 2009, DOI 10.17487/RFC5415, March 2009,
<http://www.rfc-editor.org/info/rfc5415>. <https://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>. <https://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>. <https://www.rfc-editor.org/info/rfc6660>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>. <https://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>. <https://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>. <https://www.rfc-editor.org/info/rfc7567>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation", Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015, RFC 7637, DOI 10.17487/RFC7637, September 2015,
<http://www.rfc-editor.org/info/rfc7637>. <https://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>. <https://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>. <https://www.rfc-editor.org/info/rfc7780>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<http://www.rfc-editor.org/info/rfc8084>. <https://www.rfc-editor.org/info/rfc8084>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[UTRAN] 3GPP, "UTRAN Overall Description", Technical [UTRAN] 3GPP, "UTRAN Overall Description", Technical
Specification TS 25.401. Specification TS 25.401.
Appendix A. Outstanding Document Issues Appendix A. Changes in This Version (to be removed by RFC Editor)
1. [GF] Concern that certain guidelines warrant a MUST (NOT) rather
than a SHOULD (NOT). Given the guidelines say that if any SHOULD
(NOT)s are not followed, a strong justification will be needed,
they have been left as SHOULD (NOT) pending further list
discussion. In particular:
* If inner is a Not-ECN-PDU and Outer is CE (or highest severity
congestion level), MUST (not SHOULD) drop?
This issue has been addressed by explaining when SHOULD or From ietf-09 to ietf-10
MUST is appropriate.
2. Consider whether an IETF Standard Track doc will be needed to * Updated section 5.1 on "IP-in-IP tunnels with Shim Headers" to
Update the IP-in-IP protocols listed in Section 5.1--at least be consistent with updates to draft-ietf-tsvwg-rfc6040update-
those that the IETF controls--and which Area it should sit under. shim.
This issue has been addressed by the production of * Removed reference to the ECN nonce, which has been made
[I-D.ietf-tsvwg-rfc6040update-shim], but this text is left historic by RFC 8311
outstanding until that draft is adopted.
Appendix B. Changes in This Version (to be removed by RFC Editor) * Removed "Open Issues" Appendix, given all have been addressed.
From ietf-08 to ietf-09 From ietf-08 to ietf-09
* Updated para in Intro that listed all the IP-in-IP tunnelling * Updated para in Intro that listed all the IP-in-IP tunnelling
protocols, to instead refer to draft-ietf-tsvwg-rfc6040update- protocols, to instead refer to draft-ietf-tsvwg-rfc6040update-
shim shim
* Updated section 5.1 on "IP-in-IP tunnels with Shim Headers" to * Updated section 5.1 on "IP-in-IP tunnels with Shim Headers" to
summarize guidance that has evolved as rfc6040update-shim has summarize guidance that has evolved as rfc6040update-shim has
developed. developed.
 End of changes. 52 change blocks. 
85 lines changed or deleted 74 lines changed or added

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