rfc9600.original   rfc9600.txt 
TRILL Working Group Donald Eastlake Internet Engineering Task Force (IETF) D. Eastlake 3rd
INTERNET-DRAFT Huawei Request for Comments: 9600 B. Briscoe
Intended status: Proposed Standard Bob Briscoe Category: Standards Track Independent
CableLabs ISSN: 2070-1721 August 2024
Expires: August 24, 2018 February 25, 2018
TRILL (TRansparent Interconnection of Lots of Links): TRansparent Interconnection of Lots of Links (TRILL): Explicit
ECN (Explicit Congestion Notification) Support Congestion Notification (ECN) Support
<draft-ietf-trill-ecn-support-07.txt>
Abstract Abstract
Explicit congestion notification (ECN) allows a forwarding element to Explicit Congestion Notification (ECN) allows a forwarding element to
notify downstream devices, including the destination, of the onset of notify downstream devices, including the destination, of the onset of
congestion without having to drop packets. This can improve network congestion without having to drop packets. This can improve network
efficiency through better congestion control without packet drops. efficiency through better congestion control without packet drops.
This document extends ECN to TRILL (TRansparent Interconnection of This document extends ECN to TRansparent Interconnection of Lots of
Lots of Links) switches, including integration with IP ECN, and Links (TRILL) switches, including integration with IP ECN, and
provides for ECN marking in the TRILL Header Extension Flags Word provides for ECN marking in the TRILL header extension flags word
(see RFC 7179). (RFC 7179).
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent This document is a product of the Internet Engineering Task Force
to the TRILL working group mailing list <trill@ietf.org>. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are working documents of the Internet Engineering Information about the current status of this document, any errata,
Task Force (IETF), its areas, and its working groups. Note that and how to provide feedback on it may be obtained at
other groups may also distribute working documents as Internet- https://www.rfc-editor.org/info/rfc9600.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright (c) 2024 IETF Trust and the persons identified as the
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft document authors. All rights reserved.
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
INTERNET-DRAFT TRILL ECN Support This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction............................................3 1. Introduction
1.1 Conventions used in this document......................4 1.1. Conventions Used in This Document
2. The ECN-Specific Extended Header Flags
2. The ECN Specific Extended Header Flags..................6 3. ECN Support
3.1. Ingress ECN Support
3. ECN Support.............................................7 3.2. Transit ECN Support
3.1 Ingress ECN Support....................................7 3.3. Egress ECN Support
3.2 Transit ECN Support....................................7 3.3.1. Non-ECN Egress RBridges
3.3 Egress ECN Support.....................................8 3.3.2. ECN Egress RBridges
3.3.1 Non-ECN Egress RBridges..............................8 4. TRILL Support for ECN Variants
3.3.2 ECN Egress RBridges..................................8 4.1. Pre-Congestion Notification (PCN)
4.2. Low Latency, Low Loss, and Scalable Throughput (L4S)
4. TRILL Support for ECN Variants.........................11 5. IANA Considerations
4.1 Pre-Congestion Notification (PCN).....................11 6. Security Considerations
4.2 Low Latency, Low Loss, Scalable Throughput (L4S)......12 7. References
7.1. Normative References
5. IANA Considerations....................................13 7.2. Informative References
6. Security Considerations................................14 Appendix A. TRILL Transit RBridge Behavior to Support L4S
Acknowledgements
7. Acknowledgements.......................................14 Authors' Addresses
Normative References......................................15
Informative References....................................16
Appendix A. TRILL Transit RBridge Behavior to Support L4S.17
Authors' Addresses........................................19
INTERNET-DRAFT TRILL ECN Support
1. Introduction 1. Introduction
Explicit congestion notification (ECN [RFC3168] [RFC8311]) allows a Explicit Congestion Notification (ECN) [RFC3168] [RFC8311] allows a
forwarding element (such as a router) to notify downstream devices, forwarding element (such as a router) to notify downstream devices,
including the destination, of the onset of congestion without having including the destination, of the onset of congestion without having
to drop packets. This can improve network efficiency through better to drop packets. This can improve network efficiency through better
congestion control without packet drops. The forwarding element can congestion control without packet drops. The forwarding element can
explicitly mark a proportion of packets in an ECN field instead of explicitly mark a proportion of packets in an ECN field instead of
dropping the packet. For example, a two-bit field is available for dropping packets. For example, a 2-bit field is available for ECN
ECN marking in IP headers. marking in IP headers.
............................. .............................
. . . .
+---------+ . +---------+ .
+------+ | Ingress | . +------+ | Ingress | .
|Source| +->| RBridge | . +----------+ |Source| +->| RBridge | . +----------+
+---+--+ | | RB1 | . |Forwarding| +---+--+ | | RB1 | . |Forwarding|
| | +------+--+ +----------+ . | Element | | | +------+--+ +----------+ . | Element |
v | . | | Transit | . | Y | v | . | | Transit | . | Y |
+-------+--+ . +---->| RBridges | . +--------+-+ +-------+--+ . +---->| RBridges | . +--------+-+
|Forwarding| . | RBn | . ^ | |Forwarding| . | RBn | . ^ |
| Element | . +-------+--+ +---------+ | v | Element | . +-------+--+ +---------+ | v
| X | . | | Egress | | +-----------+ | X | . | | Egress | | +-----------+
+----------+ . +---->| RBridge +-+ |Destination| +----------+ . +---->| RBridge +-+ |Destination|
. | RB9 | +-----------+ . | RB9 | +-----------+
. TRILL +---------+ . TRILL +---------+
. campus . . campus .
............................. .............................
Figure 1. Example Path Forwarding Nodes Figure 1: Example Path-Forwarding Nodes
In [RFC3168], it was recognized that tunnels and lower layer In [RFC3168], it was recognized that tunnels and lower-layer
protocols would need to support ECN, and ECN markings would need to protocols would need to support ECN, and ECN markings would need to
be propagated, as headers were encapsulated and decapsulated. be propagated, as headers were encapsulated and decapsulated.
[ECNencapGuide] gives guidelines on the addition of ECN to protocols [RFC9599] gives guidelines on the addition of ECN to protocols like
like TRILL (TRansparent Interconnection of Lots of Links) that often TRILL that often encapsulate IP packets, including propagation of ECN
encapsulate IP packets, including propagation of ECN from and to IP. from and to IP.
In the figure above, assuming IP traffic, RB1 is an encapsulator and In Figure 1, assuming IP traffic, RB1 is an encapsulator and RB9 is a
RB9 a decapsulator. Traffic from Source to RB1 might or might not get decapsulator. Traffic from Source to RB1 might or might not get
marked as having experienced congestion in forwarding elements, such marked as having experienced congestion in forwarding elements, such
as X, before being encapsulated at ingress RB1. Any such ECN marking as X, before being encapsulated at ingress RB1. Any such ECN marking
is encapsulated with a TRILL Header [RFC6325]. is encapsulated with a TRILL header [RFC6325].
This document specifies how ECN marking in traffic at the ingress is This document specifies how ECN marking in traffic at the ingress is
copied into the TRILL Extension Header Flags Word and requires such copied into the TRILL extension header flags word and requires such
copying for IP traffic. It also enables congestion marking by a copying for IP traffic. It also enables congestion marking by a
congested RBridge such as RBn or RB1 above in the TRILL Header congested RBridge (such as RBn or RB1 above) in the TRILL header
Extension Flags Word [RFC7179]. extension flags word [RFC7179].
INTERNET-DRAFT TRILL ECN Support
At RB9, the TRILL egress, it specifies how any ECN markings in the At RB9, the TRILL egress, it specifies how any ECN markings in the
TRILL Header Flags Word and in the encapsulated traffic are combined TRILL header flags word and in the encapsulated traffic are combined
so that subsequent forwarding elements, such as Y and the so that subsequent forwarding elements, such as Y and the
Destination, can see if congestion was experienced at any previous Destination, can see if congestion was experienced at any previous
point in the path from Source. point in the path from the Source.
A large part of the guidelines for adding ECN to lower layer A large part of the guidelines for adding ECN to lower-layer
protocols [ECNencapGuide] concerns safe propagation of congestion protocols [RFC9599] concerns safe propagation of congestion
notifications in scenarios where some of the nodes do not support or notifications in scenarios where some of the nodes do not support or
understand ECN. Such ECN ignorance is not a major problem with understand ECN. Such ECN ignorance is not a major problem with
RBridges using this specification because the method specified RBridges using this specification, because the method specified
assures that, if an egress RBridge is ECN ignorant (so it cannot assures that, if an egress RBridge is ECN ignorant (so it cannot
further propagate ECN) and congestion has been encountered, the further propagate ECN) and congestion has been encountered, the
egress RBridge will at least drop the packet and this drop will egress RBridge will at least drop the packet, and this drop will
itself indicate congestion to end stations. itself indicate congestion to end stations.
1.1 Conventions used in this document 1.1. Conventions Used in This Document
The terminology and acronyms defined in [RFC6325] are used herein The terminology and acronyms defined in [RFC6325] are used herein
with the same meaning. with the same meaning.
In this documents, "IP" refers to both IPv4 and IPv6. In this documents, "IP" refers to both IPv4 and IPv6.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119] [RFC8174] "OPTIONAL" in this document are to be interpreted as described in
when, and only when, they appear in all capitals, as shown here. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Acronyms:
AQM - Active Queue Management
CCE - Critical Congestion Experienced Abbreviations:
CE - Congestion Experienced AQM: Active Queue Management
CItE - Critical Ingress-to-Egress CCE: Critical Congestion Experienced
ECN - Explicit Congestion Notification CE: Congestion Experienced
ECT - ECN Capable Transport CItE: Critical Ingress-to-Egress
L4S - Low Latency, Low Loss, Scalable throughput ECN: Explicit Congestion Notification
NCHbH - Non-Critical Hop-by-Hop ECT: ECN-Capable Transport
NCCE - Non-Critical Congestion Experienced L4S: Low Latency, Low Loss, and Scalable throughput
INTERNET-DRAFT TRILL ECN Support NCHbH: Non-Critical Hop-by-Hop
Not-ECT - Not ECN-Capable Transport NCCE: Non-Critical Congestion Experienced
PCN - Pre-Congestion Notification Not-ECT: Not ECN-Capable Transport
INTERNET-DRAFT TRILL ECN Support PCN: Pre-Congestion Notification
2. The ECN Specific Extended Header Flags 2. The ECN-Specific Extended Header Flags
The extension header fields for explicit congestion notification The extension header fields for ECN in TRILL are defined as a 2-bit
(ECN) in TRILL are defined as a two-bit TRILL-ECN field and a one-bit TRILL-ECN field and a one-bit CCE field in the 32-bit TRILL header
Critical Congestion Experienced (CCE) field in the 32-bit TRILL extension flags word [RFC7780].
Header Extension Flags Word [RFC7780].
These fields are shown in Figure 2 as "ECN" and "CCE". The TRILL-ECN These fields are shown in Figure 2 as "ECN" and "CCE". The TRILL-ECN
field consists of bits 12 and 13, which are in the range reserved for field consists of bits 12 and 13, which are in the range reserved for
non-critical hop-by-hop (NCHbH) bits. The CCE field consists of bit NCHbH bits. The CCE field consists of bit 26, which is in the range
26, which is in the range reserved for Critical Ingress-to-Egress reserved for CItE bits. The CRItE bit is the critical Ingress-to-
(CItE) bits. The CRItE bit is the critical Ingress-to-Egress summary Egress summary bit and will be one if, and only if, any of the bits
bit and will be one if and only if any of the bits in the CItE range in the CItE range (21-26) are one or there is a critical feature
(21-26) are one or there is a critical feature invoked in some invoked in some further extension of the TRILL header after the
further extension of the TRILL Header after the Extension Flags Word. extension flags word. The other bits and fields shown in Figure 2
The other bits and fields shown in Figure 2 are not relevant to ECN. are not relevant to ECN. See [RFC7780], [RFC7179], and [IANAthFlags]
See [RFC7780], [RFC7179], and [IANAthFlags] for the meaning of these for the meaning of these other bits and fields.
other bits and fields.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE |
|.....|.........|...........|.....|.......|...........|.........| |.....|.........|...........|.....|.......|...........|.........|
|C|C|C| |C|N| | | | | | | | | |C|C|C| |C|N| | | | | | | | |
|R|R|R| |R|C| |ECN| Ext | | |C|Ext| | |R|R|R| |R|C| |ECN| Ext | | |C|Ext| |
|H|I|R| |C|C| | | Hop | | |C|Clr| | |H|I|R| |C|C| | | Hop | | |C|Clr| |
|b|t|s| |A|A| | | Cnt | | |E| | | |b|t|s| |A|A| | | Cnt | | |E| | |
|H|E|v| |F|F| | | | | | | | | |H|E|v| |F|F| | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. The TRILL-ECN and CCE Figure 2: The TRILL-ECN and CCE TRILL Header Extension Flags Word
TRILL Header Extension Flags Word Fields Fields
Table 1 shows the meaning of the codepoints in the TRILL-ECN field. Table 1 shows the meaning of the codepoints in the TRILL-ECN field.
The first three have the same meaning as the corresponding ECN field The first three have the same meaning as the corresponding ECN field
codepoints in the IP header as defined in [RFC3168]. However, codepoints in the IP header, as defined in [RFC3168]. However,
codepoint 0b11 is called Non-Critical Congestion Experienced (NCCE) codepoint 0b11 is called NCEE to distinguish it from CE in IP.
to distinguish it from Congestion Experienced in IP.
Binary Name Meaning
------ ------- -----------------------------------
00 Not-ECT Not ECN-Capable Transport
01 ECT(1) ECN-Capable Transport (1)
10 ECT(0) ECN-Capable Transport (0)
11 NCCE Non-Critical Congestion Experienced
Table 1. TRILL-ECN Field Codepoints +========+=========+=====================================+
| Binary | Name | Meaning |
+========+=========+=====================================+
| 00 | Not-ECT | Not ECN-Capable Transport |
+--------+---------+-------------------------------------+
| 01 | ECT(1) | ECN-Capable Transport (1) |
+--------+---------+-------------------------------------+
| 10 | ECT(0) | ECN-Capable Transport (0) |
+--------+---------+-------------------------------------+
| 11 | NCCE | Non-Critical Congestion Experienced |
+--------+---------+-------------------------------------+
INTERNET-DRAFT TRILL ECN Support Table 1: TRILL-ECN Field Codepoints
3. ECN Support 3. ECN Support
This section specifies interworking between TRILL and the original This section specifies interworking between TRILL and the original
standardized form of ECN in IP [RFC3168]. standardized form of ECN in IP [RFC3168].
The subsections below describe the required behavior to support ECN The subsections below describe the required behavior to support ECN
at TRILL ingress, transit, and egress. The ingress behavior occurs as at TRILL ingress, transit, and egress. The ingress behavior occurs
a native frame is encapsulated with a TRILL Header to produce a TRILL as a native frame is encapsulated with a TRILL header to produce a
Data packet. The transit behavior occurs in all RBridges where TRILL TRILL Data packet. The transit behavior occurs in all RBridges where
Data packets are queued, usually at the output port. The egress TRILL Data packets are queued, usually at the output port (including
behavior occurs where a TRILL Data packet is decapsulated and output the output port of the TRILL ingress). The egress behavior occurs
as a native frame through an RBridge port. where a TRILL Data packet is decapsulated and output as a native
frame through an RBridge port.
An RBridge that supports ECN MUST behave as described in the relevant An RBridge that supports ECN MUST behave as described in the relevant
subsections below, which correspond to the recommended provisions in subsections below, which correspond to the recommended provisions in
Section 3 and Sections 5.1-5.4 of [ECNencapGuide]. Nonetheless, the Section 3 of this document and Sections 4.2 through 4.4 of [RFC9599].
scheme is designed to safely propagate some form of congestion Nonetheless, the scheme is designed to safely propagate some form of
notification even if some RBridges in the path followed by a TRILL congestion notification even if some RBridges in the path followed by
Data packet support ECN and others do not. a TRILL Data packet support ECN and others do not.
3.1 Ingress ECN Support 3.1. Ingress ECN Support
The behavior at an ingress RBridge is as follows: The behavior at an ingress RBridge is as follows:
o When encapsulating an IP frame, the ingress RBridge MUST: * When encapsulating an IP frame, the ingress RBridge MUST:
+ set the F flag in the main TRILL header [RFC7780]; - set the F flag in the main TRILL header [RFC7780];
+ create a Flags Word as part of the TRILL Header;
+ copy the two ECN bits from the IP header into the TRILL-ECN
field (Flags Word bits 12 and 13)
+ ensure the CCE flag is set to zero (Flags Word bit 26).
o When encapsulating a frame for a non-IP protocol, where that - create a flags word as part of the TRILL header;
protocol has a means of indicating ECN that is understood by the
ingress RBridge, it MUST follow the guidelines in Section 5.3 of
[ECNencapGuide] to add a Flags Word to the TRILL Header. For a
non-IP protocol with a similar ECN field to IP, this would be
achieved by copying into the TRILL-ECN field from the encapsulated
native frame.
3.2 Transit ECN Support - copy the two ECN bits from the IP header into the TRILL-ECN
field (flags word bits 12 and 13); and
- ensure the CCE flag is set to zero (flags word bit 26).
* When encapsulating a frame for a non-IP protocol (where that
protocol has a means of indicating that ECN is understood by the
ingress RBridge), the ingress RBridge MUST follow the guidelines
in Section 4.3 of [RFC9599] to add a flags word to the TRILL
header. For a non-IP protocol with an ECN field similar to IP,
this would be achieved by copying into the TRILL-ECN field from
the encapsulated native frame.
3.2. Transit ECN Support
The transit behavior, shown below, is required at all RBridges where The transit behavior, shown below, is required at all RBridges where
TRILL Data packets are queued, usually at the output port. TRILL Data packets are queued, usually at the output port.
o An RBridge that supports ECN MUST implement some form of active * An RBridge that supports ECN MUST implement some form of AQM
according to the guidelines of [RFC7567]. The RBridge detects
congestion either by monitoring its own queue depth or by
participating in a link-specific protocol.
INTERNET-DRAFT TRILL ECN Support * If the TRILL header flags word is present, whenever the AQM
algorithm decides to indicate critical congestion on a TRILL Data
packet, it MUST set the CCE flag (flags word bit 26). Note that
Classic ECN marking [RFC3168] only uses critical congestion
indications, but the two variants in Section 4.1 use a combination
of critical and non-critical congestion indications.
queue management (AQM) according to the guidelines of [RFC7567]. * If the TRILL header flags word is not present, the RBridge will
The RBridge detects congestion either by monitoring its own queue either drop the packet or it MAY do all of the following instead
depth or by participating in a link-specific protocol. to indicate congestion:
o If the TRILL Header Flags Word is present, whenever the AQM - set the F flag in the main TRILL header;
algorithm decides to indicate congestion on a TRILL Data packet it
MUST set the CCE flag (Flags Word bit 26).
o If the TRILL header Flags Word is not present, to indicate - add a flags word to the TRILL header;
congestion the RBridge will either drop the packet or it MAY do
all of the following instead:
+ set the F flag in the main TRILL header; - set the TRILL-ECN field to Not-ECT (00); and
+ add a Flags Word to the TRILL Header;
+ set the TRILL-ECN field to Not-ECT (00); - set the CCE flag and the critical Ingress-to-Egress summary bit
+ and set the CCE flag and the Ingress-to-Egress critical summary (CRItE).
bit (CRIbE).
Note that a transit RBridge that supports ECN does not refer to the Note that a transit RBridge that supports ECN does not refer to the
TRILL-ECN field before signaling CCE in a packet. It signals CCE TRILL-ECN field before signaling CCE in a packet. It signals CCE
irrespective of whether the packet indicates that the transport is irrespective of whether the packet indicates that the transport is
ECN-capable. The egress/decapsulation behavior (described next) ECN capable. The egress/decapsulation behavior ensures that a CCE
ensures that a CCE indication is converted to a drop if the transport indication is converted to a drop if the transport is not ECN
is not ECN-capable. capable.
3.3 Egress ECN Support 3.3. Egress ECN Support
3.3.1 Non-ECN Egress RBridges 3.3.1. Non-ECN Egress RBridges
If the egress RBridge does not support ECN, that RBridge will ignore If the egress RBridge does not support ECN, that RBridge will ignore
bits 12 and 13 of any Flags Word that is present, because it does not bits 12 and 13 of any flags word that is present because it does not
contain any special ECN logic. Nonetheless, if a transit RBridge has contain any special ECN logic. Nonetheless, if a transit RBridge has
set the CCE flag, the egress will drop the packet. This is because set the CCE flag, the egress will drop the packet. This is because
drop is the default behavior for an RBridge decapsulating a Critical drop is the default behavior for an RBridge decapsulating a CItE flag
Ingress-to-Egress flag when it has no specific logic to understand when it has no specific logic to understand it. Drop is the intended
it. Drop is the intended behavior for such a packet, as required by behavior for such a packet, as required by Section 4.4 of [RFC9599].
Section 5.4 of [ECNencapGuide].
3.3.2 ECN Egress RBridges 3.3.2. ECN Egress RBridges
If an RBridge supports ECN, for the two cases of an IP and a non-IP If an RBridge supports ECN, for the two cases of an IP and a non-IP
inner packet, the egress behavior is as follows: inner packet, the egress behavior is as follows:
Decapsulating an inner IP packet: The RBridge sets the ECN field Decapsulating an inner IP packet: The RBridge sets the ECN field of
the outgoing native IP packet using Table 3. It MUST set the ECN
INTERNET-DRAFT TRILL ECN Support field of the outgoing IP packet to the codepoint at the
intersection of the row for the arriving encapsulated IP packet
of the outgoing native IP packet using Table 3. It MUST set the and the column for 3-bit ECN codepoint in the arriving outer TRILL
ECN field of the outgoing IP packet to the codepoint at the Data packet TRILL header. If no TRILL header extension flags word
intersection of the row for the arriving encapsulated IP packet is present, the 3-bit ECN codepoint is assumed to be all zero
and the column for 3-bit ECN codepoint in the arriving outer bits.
TRILL Data packet TRILL Header. If no TRILL Header Extension
Flags Word is present, the 3-bit ECN codepoint is assumed to be
all zero bits.
The name of the TRILL 3-bit ECN codepoint is defined using the
combination of the TRILL-ECN and CCE fields in Table 2.
Specifically, the TRILL 3-bit ECN codepoint is called CE if
either NCCE or CCE is set in the TRILL Header Extension Flags
Word. Otherwise it has the same name as the 2-bit TRILL-ECN
codepoint.
In the case where the TRILL 3-bit ECN codepoint indicates The name of the TRILL 3-bit ECN codepoint used in Table 3 is
congestion experienced (CE) but the encapsulated native IP defined using the combination of the TRILL-ECN and CCE fields in
frame indicates a not ECN-capable transport (Not-ECT), it can Table 2. Specifically, the TRILL 3-bit ECN codepoint is called CE
be seen that the RBridge MUST drop the packet. Such packet if either NCCE or CCE is set in the TRILL header extension flags
dropping is necessary because a transport above the IP layer word. Otherwise, it has the same name as the 2-bit TRILL-ECN
that is not ECN-capable will have no ECN logic, so it will only codepoint.
understand dropped packets as an indication of congestion.
Decapsulating a non-IP protocol frame: If the frame has a means of In the case where the TRILL 3-bit ECN codepoint indicates CE but
indicating ECN that is understood by the RBridge, it MUST the encapsulated native IP frame indicates a Not-ECT, it can be
follow the guidelines in Section 5.4 of [ECNencapGuide] when seen that the RBridge MUST drop the packet. Such packet dropping
setting the ECN information in the decapsulated native frame. is necessary because a transport above the IP layer that is not
For a non-IP protocol with a similar ECN field to IP, this ECN capable will have no ECN logic, so it will only understand
would be achieved by combining the information in the TRILL dropped packets as an indication of congestion.
Header Flags Word with the encapsulated non-IP native frame, as
specified in Table 3.
+------------+-----+---------------------+ Decapsulating a non-IP protocol frame: If the frame has a means of
| TRILL-ECN | CCE | Arriving TRILL 3-bit| indicating ECN that is understood by the RBridge, it MUST follow
| | | ECN codepoint name | the guidelines in Section 4.4 of [RFC9599] when setting the ECN
+------------+-----+---------------------+ information in the decapsulated native frame. For a non-IP
| Not-ECT 00 | 0 | Not-ECT | protocol with an ECN field similar to IP, this would be achieved
| ECT(1) 01 | 0 | ECT(1) | by combining the information in the TRILL header flags word with
| ECT(0) 10 | 0 | ECT(0) | the encapsulated non-IP native frame, as specified in Table 3.
| NCCE 11 | 0 | CE |
| Not-ECT 00 | 1 | CE |
| ECT(1) 01 | 1 | CE |
| ECT(0) 10 | 1 | CE |
| NCCE 11 | 1 | CE |
+------------+-----+---------------------+
Table 2. Mapping of TRILL-ECN and CCE Fields to +================+=====+=========================================+
the TRILL 3-bit ECN Codepoint Name | TRILL-ECN | CCE | Arriving TRILL 3-Bit ECN Codepoint Name |
+=========+======+ | |
| Name | Bits | | |
+=========+======+=====+=========================================+
| Not-ECT | 00 | 0 | Not-ECT |
+---------+------+-----+-----------------------------------------+
| ECT(1) | 01 | 0 | ECT(1) |
+---------+------+-----+-----------------------------------------+
| ECT(0) | 10 | 0 | ECT(0) |
+---------+------+-----+-----------------------------------------+
| NCCE | 11 | 0 | CE |
+---------+------+-----+-----------------------------------------+
| Not-ECT | 00 | 1 | CE |
+---------+------+-----+-----------------------------------------+
| ECT(1) | 01 | 1 | CE |
+---------+------+-----+-----------------------------------------+
| ECT(0) | 10 | 1 | CE |
+---------+------+-----+-----------------------------------------+
| NCCE | 11 | 1 | CE |
+---------+------+-----+-----------------------------------------+
INTERNET-DRAFT TRILL ECN Support Table 2: Mapping of TRILL-ECN and CCE Fields to the TRILL
3-Bit ECN Codepoint Name
+---------+----------------------------------------------+ +=====================+============================================+
| Inner | Arriving TRILL 3-bit ECN Codepoint Name | | Inner Native Header | Arriving TRILL 3-Bit ECN Codepoint Name |
| Native +---------+------------+------------+----------+ | +=========+============+============+========+
| Header | Not-ECT | ECT(0) | ECT(1) | CE | | | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+----------+ +=====================+=========+============+============+========+
| Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | <drop> | | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | <drop> |
| ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | +---------------------+---------+------------+------------+--------+
| ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE |
| CE | CE | CE | CE(*) | CE | +---------------------+---------+------------+------------+--------+
+---------+---------+------------+------------+----------+ | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE |
+---------------------+---------+------------+------------+--------+
| CE | CE | CE | CE(*) | CE |
+---------------------+---------+------------+------------+--------+
Table 3. Egress ECN Behavior Table 3: Egress ECN Behavior
An asterisk in the above table indicates a combination that is An asterisk in Table 3 indicates a combination that is currently
currently unused in all variants of ECN marking (see Section 4) and unused in all variants of ECN marking (see Section 4) and therefore
therefore SHOULD be logged. SHOULD be logged.
With one exception, the mappings in Table 3 are consistent with those With one exception, the mappings in Table 3 are consistent with those
for IP-in-IP tunnels [RFC6040], which ensures backward compatibility for IP-in-IP tunnels [RFC6040], which ensures backward compatibility
with all current and past variants of ECN marking (see Section 4). It with all current and past variants of ECN marking (see Section 4).
also ensures forward compatibility with any future form of ECN It also ensures forward compatibility with any future form of ECN
marking that complies with the guidelines in [ECNencapGuide], marking that complies with the guidelines in [RFC9599], including
including cases where ECT(1) represents a second level of marking cases where ECT(1) represents a second level of marking severity
severity below CE. below CE.
The one exception is that the drop condition in Table 3 need not be The one exception is that the drop condition in Table 3 need not be
logged because, with TRILL, it is the result of a valid combination logged because, with TRILL, it is the result of a valid combination
of events. of events.
INTERNET-DRAFT TRILL ECN Support 4. TRILL Support for ECN Variants
4. TRILL Support for ECN Variants
This section is informative, not normative; it discusses interworking This section is informative, not normative; it discusses interworking
between TRILL and variants of the standardized form of ECN in IP between TRILL and variants of the standardized form of ECN in IP
[RFC3168]. See also [RFC8311]. [RFC3168]. See also [RFC8311].
The ECN wire protocol for TRILL (Section 2) and the ingress (Section The ECN wire protocol for TRILL (Section 2) and the ingress
3.1) and egress (Section 3.3) ECN behaviors have been designed to (Section 3.1) and egress (Section 3.3) ECN behaviors have been
support the other known variants of ECN, as detailed below. New designed to support the other known variants of ECN as detailed
variants of ECN will have to comply with the guidelines for defining below. New variants of ECN will have to comply with the guidelines
alternative ECN semantics [RFC4774]. It is expected that the TRILL for defining alternative ECN semantics [RFC4774]. It is expected
ECN wire protocol is generic enough to support such potential future that the TRILL ECN wire protocol is generic enough to support such
variants. potential future variants.
4.1 Pre-Congestion Notification (PCN) 4.1. Pre-Congestion Notification (PCN)
The PCN wire protocol [RFC6660] is recognized by the use of a PCN- The PCN wire protocol [RFC6660] is recognized by the use of a PCN-
compatible Diffserv codepoint in the IP header and a non-zero IP-ECN compatible Diffserv codepoint in the IP header and a nonzero IP-ECN
field. For TRILL or any lower layer protocol, equivalent traffic field. For TRILL or any lower-layer protocol, equivalent traffic-
classification codepoints would have to be defined, but that is classification codepoints would have to be defined, but that is
outside the scope of the current document. outside the scope of this document.
The PCN wire protocol is similar to ECN, except it indicates The PCN wire protocol is similar to ECN, except it indicates
congestion with two levels of severity. It uses: congestion with two levels of severity. It uses:
o 11 (CE) as the most severe, termed the Excess-traffic-marked (ETM) * 11 (CE) as the most severe, termed the Excess-Traffic-Marked (ETM)
codepoint codepoint
o 01 ECT(1) as a lesser severity level, termed the Threshold-Marked * 01 ECT(1) as a lesser severity level, termed the Threshold-Marked
(ThM) codepoint. (This difference between ECT(1) and ECT(0) only (ThM) codepoint. This difference between ECT(1) and ECT(0) only
applies to PCN, not to the classic ECN support specified for TRILL applies to PCN, not to the classic ECN support specified for TRILL
in this document before Section 4.) in this document before Section 4.
To implement PCN on a transit RBridge would require a detailed To implement PCN on a transit RBridge would require a detailed
specification. But in brief: specification. In brief:
o the TRILL Critical Congestion Experienced (CCE) flag would be used * the TRILL CCE flag would be used for the Excess-Traffic-Marked
for the Excess-Traffic-Marked (ETM) codepoint; (ETM) codepoint;
o ECT(1) in the TRILL-ECN field would be used for the Threshold- * ECT(1) in the TRILL-ECN field would be used for the Threshold-
Marked codepoint. Marked codepoint.
Then the ingress and egress behaviors defined in Section 3 would not Then, the ingress and egress behaviors defined in Section 3 would not
need to be altered to ensure support for PCN as well as ECN. need to be altered to ensure support for PCN as well as ECN.
INTERNET-DRAFT TRILL ECN Support 4.2. Low Latency, Low Loss, and Scalable Throughput (L4S)
4.2 Low Latency, Low Loss, Scalable Throughput (L4S)
L4S is currently on the IETF's experimental track. An outline of how L4S is currently on the IETF's experimental track. An outline of how
a transit TRILL RBridge would support L4S [ECNL4S] is given in a transit TRILL RBridge would support L4S [RFC9331] is given in
Appendix A. Appendix A.
INTERNET-DRAFT TRILL ECN Support 5. IANA Considerations
5. IANA Considerations
IANA is requested to update the TRILL Extended Header Flags registry
by replacing the lines for bits 9-13 and for bits 21-26 with the
following:
Bits Purpose Reference IANA has updated the "TRILL Extended Header Flags" registry by
----- ------- --------- replacing the lines for bits 9-13 and 21-26 with the following:
9-11 available non-critical hop-by-hop flags
12-13 TRILL-ECN (Explicit Congestion Notification) [this doc]
21-25 available critical ingress-to-egress flags +=======+==============================================+===========+
26 Critical Congestion Experienced (CCE) [this doc] | Bits | Purpose | Reference |
+=======+==============================================+===========+
| 9-11 | available non-critical hop-by-hop flags | [RFC7179] |
+-------+----------------------------------------------+-----------+
| 12-13 | TRILL-ECN (Explicit Congestion Notification) | RFC 9600 |
+-------+----------------------------------------------+-----------+
| 21-25 | available critical ingress-to-egress flags | [RFC7179] |
+-------+----------------------------------------------+-----------+
| 26 | Critical Congestion Experienced (CCE) | RFC 9600 |
+-------+----------------------------------------------+-----------+
INTERNET-DRAFT TRILL ECN Support Table 4: Updated "TRILL Extended Header Flags" Registry
6. Security Considerations 6. Security Considerations
TRILL support of ECN is a straightforward combination of previously TRILL support of ECN is a straightforward combination of previously
specified ECN and TRILL with no significant new security specified ECN and TRILL with no significant new security
considerations. considerations.
For ECN tunneling security considerations, see [RFC6040]. For general security considerations regarding adding ECN to lower
layer protocols, see [RFC9599] and [RFC6040].
For general TRILL protocol security considerations, see [RFC6325]. For general TRILL protocol security considerations, see [RFC6325].
7. Acknowledgements 7. References
The helpful comments of Loa Andersson and Adam Roach are hereby
acknowledged.
This document was prepared with basic NROFF. All macros used were
defined in the source file.
INTERNET-DRAFT TRILL ECN Support
Normative References
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119,
March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 7.1. Normative References
of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI
10.17487/RFC3168, September 2001, <http://www.rfc-
editor.org/info/rfc3168>.
[RFC4774] - Floyd, S., "Specifying Alternate Semantics for the [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Explicit Congestion Notification (ECN) Field", BCP 124, RFC Requirement Levels", BCP 14, RFC 2119,
4774, DOI 10.17487/RFC4774, November 2006, <http://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc4774>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
Ghanwani, "Routing Bridges (RBridges): Base Protocol of Explicit Congestion Notification (ECN) to IP",
Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc6325>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and [RFC4774] Floyd, S., "Specifying Alternate Semantics for the
C. Bestler, "Transparent Interconnection of Lots of Links Explicit Congestion Notification (ECN) Field", BCP 124,
(TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May RFC 4774, DOI 10.17487/RFC4774, November 2006,
2014, <http://www.rfc-editor.org/info/rfc7179>. <https://www.rfc-editor.org/info/rfc4774>.
[RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Recommendations Regarding Active Queue Management", BCP 197, Ghanwani, "Routing Bridges (RBridges): Base Protocol
RFC 7567, DOI 10.17487/RFC7567, July 2015, <http://www.rfc- Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
editor.org/info/rfc7567>. <https://www.rfc-editor.org/info/rfc6325>.
[RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., [RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C.
Ghanwani, A., and S. Gupta, "Transparent Interconnection of Bestler, "Transparent Interconnection of Lots of Links
Lots of Links (TRILL): Clarifications, Corrections, and (TRILL): Header Extension", RFC 7179,
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, DOI 10.17487/RFC7179, May 2014,
<http://www.rfc-editor.org/info/rfc7780>. <https://www.rfc-editor.org/info/rfc7179>.
[RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May Recommendations Regarding Active Queue Management",
2017, <http://www.rfc-editor.org/info/rfc8174> BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>.
[RFC8311] - Black, D., "Relaxing Restrictions on Explicit Congestion [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Notification (ECN) Experimentation", RFC 8311, DOI Ghanwani, A., and S. Gupta, "Transparent Interconnection
10.17487/RFC8311, January 2018, <https://www.rfc- of Lots of Links (TRILL): Clarifications, Corrections, and
editor.org/info/rfc8311>. Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<https://www.rfc-editor.org/info/rfc7780>.
[ECNencapGuide] - B. Briscoe, J. Kaippallimalil, P. Thaler, [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
"Guidelines for Adding Congestion Notification to Protocols 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
that Encapsulate IP", draft-ietf-tsvwg-ecn-encap-guidelines, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
work in progress.
INTERNET-DRAFT TRILL ECN Support [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>.
Informative References [RFC9599] Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding
Congestion Notification to Protocols that Encapsulate IP",
RFC 9599, DOI 10.17487/RFC9599, August 2024,
<https://www.rfc-editor.org/info/rfc9599>.
[ECNL4S] - K. De Schepper, B. Briscoe, "Identifying Modified Explicit 7.2. Informative References
Congestion Notification (ECN) Semantics for Ultra-Low Queueing
Delay", draft-ietf-tsvwg-ecn-l4s-id, work in progress.
[IANAthFlags] - IANA TRILL Extended Header word flags: [IANAthFlags]
http://www.iana.org/assignments/trill-parameters/trill- IANA, "TRILL Extended Header Flags",
parameters.xhtml#extended-header-flags <http://www.iana.org/assignments/trill-parameters/>.
[RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, Notification", RFC 6040, DOI 10.17487/RFC6040, November
<http://www.rfc-editor.org/info/rfc6040>. 2010, <https://www.rfc-editor.org/info/rfc6040>.
[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 Using Pre-Congestion Notification (PCN) States in the IP Header
a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
10.17487/RFC6660, July 2012, <http://www.rfc- DOI 10.17487/RFC6660, July 2012,
editor.org/info/rfc6660>. <https://www.rfc-editor.org/info/rfc6660>.
INTERNET-DRAFT TRILL ECN Support [RFC9331] De Schepper, K. and B. Briscoe, Ed., "The Explicit
Congestion Notification (ECN) Protocol for Low Latency,
Low Loss, and Scalable Throughput (L4S)", RFC 9331,
DOI 10.17487/RFC9331, January 2023,
<https://www.rfc-editor.org/info/rfc9331>.
Appendix A. TRILL Transit RBridge Behavior to Support L4S Appendix A. TRILL Transit RBridge Behavior to Support L4S
The specification of the Low Latency, Low Loss, Scalable throughput The specification of the Low Latency, Low Loss, and Scalable
(L4S) wire protocol for IP is given in [ECNL4S]. L4S is one example throughput (L4S) wire protocol for IP is given in [RFC9331]. L4S is
of the ways TRILL ECN handling may evolve [RFC8311]. It is similar to one example of the ways TRILL ECN handling may evolve [RFC8311]. It
the original ECN wire protocol for IP [RFC3168], except: is similar to the original ECN wire protocol for IP [RFC3168],
except:
o An AQM that supports L4S classifies packets with ECT(1) or CE in * An AQM that supports L4S classifies packets with ECT(1) or CE in
the IP header into an L4S queue and a "Classic" queue otherwise. the IP header into an L4S queue and a "Classic" queue otherwise.
o The meaning of CE markings applied by an L4S queue is not the same * The meaning of CE markings applied by an L4S queue is not the same
as the meaning of a drop by a "Classic" queue (contrary to the as the meaning of a drop by a "Classic" queue (contrary to the
original requirement for ECN [RFC3168]). Instead, the likelihood original requirement for ECN [RFC3168]). Instead, the likelihood
that the Classic queue drops packets is defined as the square of that the Classic queue drops packets is defined as the square of
the likelihood that the L4S queue marks packets (e.g., when there the likelihood that the L4S queue marks packets -- e.g., when
is a drop probability of 0.0009 (0.09%) the L4S marking there is a drop probability of 0.0009 (0.09%), the L4S marking
probability will be 0.03 (3%)). probability will be 0.03 (3%).
This seems to present a problem for the way that a transit TRILL This seems to present a problem for the way that a transit TRILL
RBridge defers the choice between marking and dropping to the egress. RBridge defers the choice between marking and dropping to the egress.
Nonetheless, the following pseudocode outlines how a transit TRILL Nonetheless, the following pseudocode outlines how a transit TRILL
RBridge can implement L4S marking in such a way that the egress RBridge can implement L4S marking in such a way that the egress
behavior already described in Section 3.3 for Classic ECN [RFC3168] behavior already described in Section 3.3 for Classic ECN [RFC3168]
will produce the desired outcome. will produce the desired outcome.
/* p is an internal variable calculated by any L4S AQM /* p is an internal variable calculated by any L4S AQM
* dependent on the delay being experienced in the Classic queue. * dependent on the delay being experienced in the Classic queue.
skipping to change at page 17, line 53 skipping to change at line 618
} else { } else {
% L4S Queue % L4S Queue
if (p > random() ) { if (p > random() ) {
if (p > random() ) if (p > random() )
mark(CCE) % likelihood: p^2 mark(CCE) % likelihood: p^2
else else
mark(NCCE) % likelihood: p - p^2 mark(NCCE) % likelihood: p - p^2
} }
} }
With the above transit behavior, an egress that supports ECN (Section With the above transit behavior, an egress that supports ECN
3.3) will drop packets or propagate their ECN markings depending on (Section 3.3) will drop packets or propagate their ECN markings
whether the arriving inner header is from a non-ECN-capable or ECN- depending on whether the arriving inner header is from an ECN-capable
capable transport. or not ECN-capable transport.
INTERNET-DRAFT TRILL ECN Support
Even if an egress has no L4S-specific logic of its own, it will drop Even if an egress has no L4S-specific logic of its own, it will drop
packets with the square of the probability that an egress would if it packets with the square of the probability that an egress would if it
did support ECN, for the following reasons: did support ECN, for the following reasons:
o Egress with ECN support: * Egress with ECN support:
+ L4S: propagates both the Critical and Non-Critical CE marks
(CCE & NCCE) as a CE mark.
Likelihood: p^2 + p - p^2 = p
+ Classic: Propagates CCE marks as CE or drop, depending on
inner.
Likelihood: p^2
o Egress without ECN support:
+ L4S: does not propagate NCCE as a CE mark, but drops CCE marks. - L4S: Propagates both the Critical and Non-Critical CE marks
(CCE and NCCE) as a CE mark.
Likelihood: p^2 Likelihood: p^2 + p - p^2 = p
+ Classic: drops CCE marks. - Classic: Propagates CCE marks as CE or drop, depending on the
inner header.
Likelihood: p^2 Likelihood: p^2
INTERNET-DRAFT TRILL ECN Support * Egress without ECN support:
Authors' Addresses - L4S: Does not propagate NCCE as a CE mark, but drops CCE marks.
Donald E. Eastlake, 3rd Likelihood: p^2
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA
Tel: +1-508-333-2270 - Classic: Drops CCE marks.
Email: d3e3e3@gmail.com
Bob Briscoe Likelihood: p^2
CableLabs
UK
Email: ietf@bobbriscoe.net Acknowledgements
URI: http://bobbriscoe.net/
INTERNET-DRAFT TRILL ECN Support The helpful comments of Loa Andersson and Adam Roach are hereby
acknowledged.
Copyright and IPR Provisions Authors' Addresses
Copyright (c) 2018 IETF Trust and the persons identified as the Donald E. Eastlake, 3rd
document authors. All rights reserved. Independent
2386 Panoramic Circle
Apopka, FL 32703
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
This document is subject to BCP 78 and the IETF Trust's Legal Bob Briscoe
Provisions Relating to IETF Documents Independent
(http://trustee.ietf.org/license-info) in effect on the date of United Kingdom
publication of this document. Please review these documents Email: ietf@bobbriscoe.net
carefully, as they describe your rights and restrictions with respect URI: http://bobbriscoe.net/
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. The definitive version of
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.
 End of changes. 141 change blocks. 
437 lines changed or deleted 413 lines changed or added

This html diff was produced by rfcdiff 1.48.