doc: Add RFC documents

1 files changed, 673 insertions, 0 deletions

diff --git a/doc/rfc/rfc9600.txt b/doc/rfc/rfc9600.txt
new file mode 100644
index 0000000..12bce5c
--- /dev/null
+++ b/doc/rfc/rfc9600.txt
@@ -0,0 +1,673 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
+Request for Comments: 9600                                    B. Briscoe
+Category: Standards Track                                    Independent
+ISSN: 2070-1721                                              August 2024
+
+
+     TRansparent Interconnection of Lots of Links (TRILL): Explicit
+                 Congestion Notification (ECN) Support
+
+Abstract
+
+   Explicit Congestion Notification (ECN) allows a forwarding element to
+   notify downstream devices, including the destination, of the onset of
+   congestion without having to drop packets.  This can improve network
+   efficiency through better congestion control without packet drops.
+   This document extends ECN to TRansparent Interconnection of Lots of
+   Links (TRILL) switches, including integration with IP ECN, and
+   provides for ECN marking in the TRILL header extension flags word
+   (RFC 7179).
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (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.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9600.
+
+Copyright Notice
+
+   Copyright (c) 2024 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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
+
+   1.  Introduction
+     1.1.  Conventions Used in This Document
+   2.  The ECN-Specific Extended Header Flags
+   3.  ECN Support
+     3.1.  Ingress ECN Support
+     3.2.  Transit ECN Support
+     3.3.  Egress ECN Support
+       3.3.1.  Non-ECN Egress RBridges
+       3.3.2.  ECN Egress RBridges
+   4.  TRILL Support for ECN Variants
+     4.1.  Pre-Congestion Notification (PCN)
+     4.2.  Low Latency, Low Loss, and Scalable Throughput (L4S)
+   5.  IANA Considerations
+   6.  Security Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Appendix A.  TRILL Transit RBridge Behavior to Support L4S
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   Explicit Congestion Notification (ECN) [RFC3168] [RFC8311] allows a
+   forwarding element (such as a router) to notify downstream devices,
+   including the destination, of the onset of congestion without having
+   to drop packets.  This can improve network efficiency through better
+   congestion control without packet drops.  The forwarding element can
+   explicitly mark a proportion of packets in an ECN field instead of
+   dropping packets.  For example, a 2-bit field is available for ECN
+   marking in IP headers.
+
+                     .............................
+                     .                           .
+                 +---------+                     .
+    +------+     | Ingress |                     .
+    |Source|  +->| RBridge |                     .   +----------+
+    +---+--+  |  |   RB1   |                     .   |Forwarding|
+        |     |  +------+--+  +----------+       .   | Element  |
+        v     |      .  |     | Transit  |       .   |    Y     |
+      +-------+--+   .  +---->| RBridges |       .   +--------+-+
+      |Forwarding|   .        |   RBn    |       .      ^     |
+      | Element  |   .        +-------+--+  +---------+ |     v
+      |    X     |   .                |     | Egress  | |  +-----------+
+      +----------+   .                +---->| RBridge +-+  |Destination|
+                     .                      |   RB9   |    +-----------+
+                     .  TRILL               +---------+
+                     .  campus                   .
+                     .............................
+
+                  Figure 1: Example Path-Forwarding Nodes
+
+   In [RFC3168], it was recognized that tunnels and lower-layer
+   protocols would need to support ECN, and ECN markings would need to
+   be propagated, as headers were encapsulated and decapsulated.
+   [RFC9599] gives guidelines on the addition of ECN to protocols like
+   TRILL that often encapsulate IP packets, including propagation of ECN
+   from and to IP.
+
+   In Figure 1, assuming IP traffic, RB1 is an encapsulator and RB9 is a
+   decapsulator.  Traffic from Source to RB1 might or might not get
+   marked as having experienced congestion in forwarding elements, such
+   as X, before being encapsulated at ingress RB1.  Any such ECN marking
+   is encapsulated with a TRILL header [RFC6325].
+
+   This document specifies how ECN marking in traffic at the ingress is
+   copied into the TRILL extension header flags word and requires such
+   copying for IP traffic.  It also enables congestion marking by a
+   congested RBridge (such as RBn or RB1 above) in the TRILL header
+   extension flags word [RFC7179].
+
+   At RB9, the TRILL egress, it specifies how any ECN markings in the
+   TRILL header flags word and in the encapsulated traffic are combined
+   so that subsequent forwarding elements, such as Y and the
+   Destination, can see if congestion was experienced at any previous
+   point in the path from the Source.
+
+   A large part of the guidelines for adding ECN to lower-layer
+   protocols [RFC9599] concerns safe propagation of congestion
+   notifications in scenarios where some of the nodes do not support or
+   understand ECN.  Such ECN ignorance is not a major problem with
+   RBridges using this specification, because the method specified
+   assures that, if an egress RBridge is ECN ignorant (so it cannot
+   further propagate ECN) and congestion has been encountered, the
+   egress RBridge will at least drop the packet, and this drop will
+   itself indicate congestion to end stations.
+
+1.1.  Conventions Used in This Document
+
+   The terminology and acronyms defined in [RFC6325] are used herein
+   with the same meaning.
+
+   In this documents, "IP" refers to both IPv4 and IPv6.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   Abbreviations:
+
+   AQM:  Active Queue Management
+
+   CCE:  Critical Congestion Experienced
+
+   CE:  Congestion Experienced
+
+   CItE:  Critical Ingress-to-Egress
+
+   ECN:  Explicit Congestion Notification
+
+   ECT:  ECN-Capable Transport
+
+   L4S:  Low Latency, Low Loss, and Scalable throughput
+
+   NCHbH:  Non-Critical Hop-by-Hop
+
+   NCCE:  Non-Critical Congestion Experienced
+
+   Not-ECT:  Not ECN-Capable Transport
+
+   PCN:  Pre-Congestion Notification
+
+2.  The ECN-Specific Extended Header Flags
+
+   The extension header fields for ECN in TRILL are defined as a 2-bit
+   TRILL-ECN field and a one-bit CCE field in the 32-bit TRILL header
+   extension flags word [RFC7780].
+
+   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
+   NCHbH bits.  The CCE field consists of bit 26, which is in the range
+   reserved for CItE bits.  The CRItE bit is the critical Ingress-to-
+   Egress summary bit and will be one if, and only if, any of the bits
+   in the CItE range (21-26) are one or there is a critical feature
+   invoked in some further extension of the TRILL header after the
+   extension flags word.  The other bits and fields shown in Figure 2
+   are not relevant to ECN.  See [RFC7780], [RFC7179], and [IANAthFlags]
+   for the meaning of these other bits and fields.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Crit.|  CHbH   |   NCHbH   |CRSV | NCRSV |   CItE    |  NCItE  |
+   |.....|.........|...........|.....|.......|...........|.........|
+   |C|C|C|       |C|N|     |   |     |       |         | |   |     |
+   |R|R|R|       |R|C|     |ECN| Ext |       |         |C|Ext|     |
+   |H|I|R|       |C|C|     |   | Hop |       |         |C|Clr|     |
+   |b|t|s|       |A|A|     |   | Cnt |       |         |E|   |     |
+   |H|E|v|       |F|F|     |   |     |       |         | |   |     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+     Figure 2: The TRILL-ECN and CCE TRILL Header Extension Flags Word
+                                   Fields
+
+   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
+   codepoints in the IP header, as defined in [RFC3168].  However,
+   codepoint 0b11 is called NCEE to distinguish it from CE 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
+
+3.  ECN Support
+
+   This section specifies interworking between TRILL and the original
+   standardized form of ECN in IP [RFC3168].
+
+   The subsections below describe the required behavior to support ECN
+   at TRILL ingress, transit, and egress.  The ingress behavior occurs
+   as a native frame is encapsulated with a TRILL header to produce a
+   TRILL Data packet.  The transit behavior occurs in all RBridges where
+   TRILL Data packets are queued, usually at the output port (including
+   the output port of the TRILL ingress).  The egress behavior occurs
+   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
+   subsections below, which correspond to the recommended provisions in
+   Section 3 of this document and Sections 4.2 through 4.4 of [RFC9599].
+   Nonetheless, the scheme is designed to safely propagate some form of
+   congestion notification even if some RBridges in the path followed by
+   a TRILL Data packet support ECN and others do not.
+
+3.1.  Ingress ECN Support
+
+   The behavior at an ingress RBridge is as follows:
+
+   *  When encapsulating an IP frame, the ingress RBridge MUST:
+
+      -  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); 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
+   TRILL Data packets are queued, usually at the output port.
+
+   *  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.
+
+   *  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.
+
+   *  If the TRILL header flags word is not present, the RBridge will
+      either drop the packet or it MAY do all of the following instead
+      to indicate congestion:
+
+      -  set the F flag in the main TRILL header;
+
+      -  add a flags word to the TRILL header;
+
+      -  set the TRILL-ECN field to Not-ECT (00); and
+
+      -  set the CCE flag and the critical Ingress-to-Egress summary bit
+         (CRItE).
+
+   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
+   irrespective of whether the packet indicates that the transport is
+   ECN capable.  The egress/decapsulation behavior ensures that a CCE
+   indication is converted to a drop if the transport is not ECN
+   capable.
+
+3.3.  Egress ECN Support
+
+3.3.1.  Non-ECN Egress RBridges
+
+   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
+   contain any special ECN logic.  Nonetheless, if a transit RBridge has
+   set the CCE flag, the egress will drop the packet.  This is because
+   drop is the default behavior for an RBridge decapsulating a CItE flag
+   when it has no specific logic to understand it.  Drop is the intended
+   behavior for such a packet, as required by Section 4.4 of [RFC9599].
+
+3.3.2.  ECN Egress RBridges
+
+   If an RBridge supports ECN, for the two cases of an IP and a non-IP
+   inner packet, the egress behavior is as follows:
+
+   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
+      field of the outgoing IP packet to the codepoint at the
+      intersection of the row for the arriving encapsulated IP packet
+      and the column for 3-bit ECN codepoint in the arriving outer 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 used in Table 3 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 CE but
+      the encapsulated native IP frame indicates a Not-ECT, it can be
+      seen that the RBridge MUST drop the packet.  Such packet dropping
+      is necessary because a transport above the IP layer that is not
+      ECN capable will have no ECN logic, so it will only understand
+      dropped packets as an indication of congestion.
+
+   Decapsulating a non-IP protocol frame:  If the frame has a means of
+      indicating ECN that is understood by the RBridge, it MUST follow
+      the guidelines in Section 4.4 of [RFC9599] when setting the ECN
+      information in the decapsulated native frame.  For a non-IP
+      protocol with an ECN field similar to IP, this would be achieved
+      by combining the information in the TRILL header flags word with
+      the encapsulated non-IP native frame, as specified in Table 3.
+
+    +================+=====+=========================================+
+    | 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                                      |
+    +---------+------+-----+-----------------------------------------+
+
+        Table 2: Mapping of TRILL-ECN and CCE Fields to the TRILL
+                         3-Bit ECN Codepoint Name
+
+   +=====================+============================================+
+   | Inner Native Header |  Arriving TRILL 3-Bit ECN Codepoint Name   |
+   |                     +=========+============+============+========+
+   |                     | Not-ECT |   ECT(0)   |   ECT(1)   |   CE   |
+   +=====================+=========+============+============+========+
+   |       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   |
+   +---------------------+---------+------------+------------+--------+
+   |          CE         |    CE   |     CE     |   CE(*)    |   CE   |
+   +---------------------+---------+------------+------------+--------+
+
+                       Table 3: Egress ECN Behavior
+
+   An asterisk in Table 3 indicates a combination that is currently
+   unused in all variants of ECN marking (see Section 4) and therefore
+   SHOULD be logged.
+
+   With one exception, the mappings in Table 3 are consistent with those
+   for IP-in-IP tunnels [RFC6040], which ensures backward compatibility
+   with all current and past variants of ECN marking (see Section 4).
+   It also ensures forward compatibility with any future form of ECN
+   marking that complies with the guidelines in [RFC9599], including
+   cases where ECT(1) represents a second level of marking severity
+   below CE.
+
+   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
+   of events.
+
+4.  TRILL Support for ECN Variants
+
+   This section is informative, not normative; it discusses interworking
+   between TRILL and variants of the standardized form of ECN in IP
+   [RFC3168].  See also [RFC8311].
+
+   The ECN wire protocol for TRILL (Section 2) and the ingress
+   (Section 3.1) and egress (Section 3.3) ECN behaviors have been
+   designed to support the other known variants of ECN as detailed
+   below.  New variants of ECN will have to comply with the guidelines
+   for defining alternative ECN semantics [RFC4774].  It is expected
+   that the TRILL ECN wire protocol is generic enough to support such
+   potential future variants.
+
+4.1.  Pre-Congestion Notification (PCN)
+
+   The PCN wire protocol [RFC6660] is recognized by the use of a PCN-
+   compatible Diffserv codepoint in the IP header and a nonzero IP-ECN
+   field.  For TRILL or any lower-layer protocol, equivalent traffic-
+   classification codepoints would have to be defined, but that is
+   outside the scope of this document.
+
+   The PCN wire protocol is similar to ECN, except it indicates
+   congestion with two levels of severity.  It uses:
+
+   *  11 (CE) as the most severe, termed the Excess-Traffic-Marked (ETM)
+      codepoint
+
+   *  01 ECT(1) as a lesser severity level, termed the Threshold-Marked
+      (ThM) codepoint.  This difference between ECT(1) and ECT(0) only
+      applies to PCN, not to the classic ECN support specified for TRILL
+      in this document before Section 4.
+
+   To implement PCN on a transit RBridge would require a detailed
+   specification.  In brief:
+
+   *  the TRILL CCE flag would be used for the Excess-Traffic-Marked
+      (ETM) codepoint;
+
+   *  ECT(1) in the TRILL-ECN field would be used for the Threshold-
+      Marked codepoint.
+
+   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.
+
+4.2.  Low Latency, Low Loss, and Scalable Throughput (L4S)
+
+   L4S is currently on the IETF's experimental track.  An outline of how
+   a transit TRILL RBridge would support L4S [RFC9331] is given in
+   Appendix A.
+
+5.  IANA Considerations
+
+   IANA has updated the "TRILL Extended Header Flags" registry by
+   replacing the lines for bits 9-13 and 21-26 with the following:
+
+   +=======+==============================================+===========+
+   | 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  |
+   +-------+----------------------------------------------+-----------+
+
+         Table 4: Updated "TRILL Extended Header Flags" Registry
+
+6.  Security Considerations
+
+   TRILL support of ECN is a straightforward combination of previously
+   specified ECN and TRILL with no significant new security
+   considerations.
+
+   For general security considerations regarding adding ECN to lower
+   layer protocols, see [RFC9599] and [RFC6040].
+
+   For general TRILL protocol security considerations, see [RFC6325].
+
+7.  References
+
+7.1.  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,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+              of Explicit Congestion Notification (ECN) to IP",
+              RFC 3168, DOI 10.17487/RFC3168, September 2001,
+              <https://www.rfc-editor.org/info/rfc3168>.
+
+   [RFC4774]  Floyd, S., "Specifying Alternate Semantics for the
+              Explicit Congestion Notification (ECN) Field", BCP 124,
+              RFC 4774, DOI 10.17487/RFC4774, November 2006,
+              <https://www.rfc-editor.org/info/rfc4774>.
+
+   [RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
+              Ghanwani, "Routing Bridges (RBridges): Base Protocol
+              Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
+              <https://www.rfc-editor.org/info/rfc6325>.
+
+   [RFC7179]  Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C.
+              Bestler, "Transparent Interconnection of Lots of Links
+              (TRILL): Header Extension", RFC 7179,
+              DOI 10.17487/RFC7179, May 2014,
+              <https://www.rfc-editor.org/info/rfc7179>.
+
+   [RFC7567]  Baker, F., Ed. and G. Fairhurst, Ed., "IETF
+              Recommendations Regarding Active Queue Management",
+              BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
+              <https://www.rfc-editor.org/info/rfc7567>.
+
+   [RFC7780]  Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
+              Ghanwani, A., and S. Gupta, "Transparent Interconnection
+              of Lots of Links (TRILL): Clarifications, Corrections, and
+              Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
+              <https://www.rfc-editor.org/info/rfc7780>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [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>.
+
+   [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>.
+
+7.2.  Informative References
+
+   [IANAthFlags]
+              IANA, "TRILL Extended Header Flags",
+              <http://www.iana.org/assignments/trill-parameters/>.
+
+   [RFC6040]  Briscoe, B., "Tunnelling of Explicit Congestion
+              Notification", RFC 6040, DOI 10.17487/RFC6040, November
+              2010, <https://www.rfc-editor.org/info/rfc6040>.
+
+   [RFC6660]  Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
+              Pre-Congestion Notification (PCN) States in the IP Header
+              Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
+              DOI 10.17487/RFC6660, July 2012,
+              <https://www.rfc-editor.org/info/rfc6660>.
+
+   [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
+
+   The specification of the Low Latency, Low Loss, and Scalable
+   throughput (L4S) wire protocol for IP is given in [RFC9331].  L4S is
+   one example of the ways TRILL ECN handling may evolve [RFC8311].  It
+   is similar to the original ECN wire protocol for IP [RFC3168],
+   except:
+
+   *  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 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
+      original requirement for ECN [RFC3168]).  Instead, the likelihood
+      that the Classic queue drops packets is defined as the square of
+      the likelihood that the L4S queue marks packets -- e.g., when
+      there is a drop probability of 0.0009 (0.09%), the L4S marking
+      probability will be 0.03 (3%).
+
+   This seems to present a problem for the way that a transit TRILL
+   RBridge defers the choice between marking and dropping to the egress.
+   Nonetheless, the following pseudocode outlines how a transit TRILL
+   RBridge can implement L4S marking in such a way that the egress
+   behavior already described in Section 3.3 for Classic ECN [RFC3168]
+   will produce the desired outcome.
+
+      /* p is an internal variable calculated by any L4S AQM
+       *  dependent on the delay being experienced in the Classic queue.
+       * bit13 is the least significant bit of the TRILL-ECN field
+       */
+
+      % On TRILL transit
+      if (bit13 == 0 ) {
+            % Classic Queue
+            if (p > max(random(), random()) )
+               mark(CCE)                         % likelihood: p^2
+
+      } else {
+            % L4S Queue
+            if (p > random() ) {
+               if (p > random() )
+                  mark(CCE)                      % likelihood: p^2
+               else
+                  mark(NCCE)                     % likelihood: p - p^2
+            }
+      }
+
+   With the above transit behavior, an egress that supports ECN
+   (Section 3.3) will drop packets or propagate their ECN markings
+   depending on whether the arriving inner header is from an ECN-capable
+   or not ECN-capable transport.
+
+   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
+   did support ECN, for the following reasons:
+
+   *  Egress with ECN support:
+
+      -  L4S: Propagates both the Critical and Non-Critical CE marks
+         (CCE and NCCE) as a CE mark.
+
+         Likelihood: p^2 + p - p^2 = p
+
+      -  Classic: Propagates CCE marks as CE or drop, depending on the
+         inner header.
+
+         Likelihood: p^2
+
+   *  Egress without ECN support:
+
+      -  L4S: Does not propagate NCCE as a CE mark, but drops CCE marks.
+
+         Likelihood: p^2
+
+      -  Classic: Drops CCE marks.
+
+         Likelihood: p^2
+
+Acknowledgements
+
+   The helpful comments of Loa Andersson and Adam Roach are hereby
+   acknowledged.
+
+Authors' Addresses
+
+   Donald E. Eastlake, 3rd
+   Independent
+   2386 Panoramic Circle
+   Apopka, FL 32703
+   United States of America
+   Phone: +1-508-333-2270
+   Email: d3e3e3@gmail.com
+
+
+   Bob Briscoe
+   Independent
+   United Kingdom
+   Email: ietf@bobbriscoe.net
+   URI:   http://bobbriscoe.net/