<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
 <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
 <!ENTITY RFC3168 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"> zwsp   "&#8203;">
 <!ENTITY RFC4774 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4774.xml"> nbhy   "&#8209;">
 <!ENTITY RFC6325 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6325.xml">
<!ENTITY RFC7179 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7179.xml">
<!ENTITY RFC7567 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7567.xml">
<!ENTITY RFC7780 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7780.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8311 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8311.xml">
<!ENTITY I-D.ietf-tsvwg-ecn-encap-guidelines SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-ecn-encap-guidelines.xml">
<!ENTITY I-D.ietf-tsvwg-ecn-encap-guidelines SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-ecn-encap-guidelines.xml">
<!ENTITY I-D.ietf-tsvwg-ecn-l4s-id SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-ecn-l4s-id.xml">
<!ENTITY I-D.ietf-tsvwg-ecn-l4s-id SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-ecn-l4s-id.xml">
<!ENTITY RFC6040 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml">
<!ENTITY RFC6660 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml"> wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-trill-ecn-support-07"
     category="std" ipr="trust200902">
	<!-- Generated by id2xml 1.5.0 on 2020-06-08T19:55:39Z -->
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc text-list-symbols="o+*-"?>
	<?rfc toc="yes"?> consensus="true" docName="draft-ietf-trill-ecn-support-07"
     number="9600" ipr="trust200902" obsoletes="" updates="" xml:lang="en"
     symRefs="true" sortRefs="true" tocInclude="true" version="3">

	<front>
    <title abbrev="TRILL ECN Support">TRILL (TRansparent Support">TRansparent Interconnection of Lots of Links): ECN (Explicit Links (TRILL): Explicit Congestion Notification) Notification (ECN) Support</title>
<seriesInfo name="RFC" value="9600"/>
    <author initials="D." surname="Eastlake" surname="Eastlake 3rd" fullname="Donald E. Eastlake, 3rd">
	<organization abbrev="Huawei">Huawei Technologies</organization>
	<address><postal><street>155 Beaver Street</street>
	<city>Milford</city><region>MA</region><code>01757</code><country>USA</country>
      <organization>Independent</organization>
      <address>
        <postal>
          <street>2386 Panoramic Circle</street>
          <city>Apopka</city>
          <region>FL</region>
          <code>32703</code>
          <country>United States of America</country>
        </postal>
        <phone>+1-508-333-2270</phone>
        <email>d3e3e3@gmail.com</email>
	<email>donald.eastlake@futurewei.com</email>
      </address>
    </author>
    <author initials="B." surname="Briscoe" fullname="Bob Briscoe">
	<organization>CableLabs</organization>
	<address><postal>
	<street></street><city></city> <region></region><code></code>
	<country>UK</country>
      <organization>Independent</organization>
      <address>
        <postal>
          <country>United Kingdom</country>
        </postal>
        <email>ietf@bobbriscoe.net</email>
        <uri>http://bobbriscoe.net/</uri>
      </address>
    </author>
    <date year="2020" year="2024" month="June"/>
	<workgroup>TRILL Working Group</workgroup>
	<abstract><t>
    <area>RTG</area>
    <workgroup>TRILL</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>
   Explicit congestion notification 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 TRILL (TRansparent TRansparent Interconnection of
   Lots of Links) Links (TRILL) switches, including integration with IP ECN, and
   provides for ECN marking in the TRILL Header Extension Flags Word
   (see RFC header extension flags word
   (RFC 7179).</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   Explicit congestion notification (ECN Congestion Notification (ECN) <xref target="RFC3168"/> target="RFC3168"
   format="default"/> <xref
   target="RFC8311"/>) target="RFC8311" format="default"/> 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 the packet. For example, a two-bit 2-bit field is
   available for ECN marking in IP headers.</t>
      <figure title="Example Path Forwarding Nodes" anchor="fig-1">

	<artwork><![CDATA[
        <name>Example Path-Forwarding Nodes</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                  .............................
                  .                           .
              +---------+                     .
 +------+     | Ingress |                     .
 |Source|  +->| RBridge |                     .   +----------+
 +---+--+  |  |   RB1   |                     .   |Forwarding|
     |     |  +------+--+  +----------+       .   | Element  |
     v     |      .  |     | Transit  |       .   |    Y     |
   +-------+--+   .  +---->| RBridges |       .   +--------+-+
   |Forwarding|   .        |   RBn    |       .      ^     |
   | Element  |   .        +-------+--+  +---------+ |     v
   |    X     |   .                |     | Egress  | |  +-----------+
   +----------+   .                +---->| RBridge +-+  |Destination|
                  .                      |   RB9   |    +-----------+
                  .  TRILL               +---------+
                  .  campus                   .
                  .............................
]]></artwork>
      </figure>
      <t>
   In <xref target="RFC3168"/>, target="RFC3168" format="default"/>, it was recognized that tunnels and lower layer lower-layer
   protocols would need to support ECN, and ECN markings would need to
   be propagated, as headers were encapsulated and decapsulated.
   <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines"/> target="RFC9599" format="default"/> gives guidelines on the addition of ECN to protocols
   like TRILL (TRansparent Interconnection of Lots of Links) that often
   encapsulate IP packets, including propagation of ECN from and to IP.</t>
      <t>
   In the figure above, <xref target="fig-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 header <xref target="RFC6325"/>.</t> target="RFC6325" format="default"/>.</t>
      <t>
   This document specifies how ECN marking in traffic at the ingress is
   copied into the TRILL Extension Header Flags Word extension header flags word and requires such
   copying for IP traffic. It also enables congestion marking by a
   congested RBridge such (such as RBn or RB1 above above) in the TRILL Header
   Extension Flags Word header
   extension flags word <xref target="RFC7179"/>.</t> target="RFC7179" format="default"/>.</t>
      <t>
   At RB9, the TRILL egress, it specifies how any ECN markings in the
   TRILL Header Flags Word 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 Source.</t>
      <t>
   A large part of the guidelines for adding ECN to lower layer lower-layer
   protocols <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines"/> target="RFC9599" format="default"/> 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 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 packet, and this drop will
   itself indicate congestion to end stations.</t>
      <section title="Conventions used anchor="sect-1.1" numbered="true" toc="default">
        <name>Conventions Used in this document" anchor="sect-1.1"><t> This Document</name>
        <t>
   The terminology and acronyms defined in <xref target="RFC6325"/> target="RFC6325"
   format="default"/> are used herein with the same meaning.</t>
        <t>
   In this documents, "IP" refers to both IPv4 and IPv6.</t>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>

	<t>Acronyms:
	<list>
	<t>AQM - Active here.
        </t>

        <t>Abbreviations:</t>
<dl>
          <dt>AQM:</dt><dd>Active Queue Management</t>
	<t>CCE - Critical Management</dd>
          <dt>CCE:</dt><dd>Critical Congestion Experienced</t>
	<t>CE - Congestion Experienced</t>
	<t>CItE - Critical Ingress-to-Egress</t>
	<t>ECN - Explicit Experienced</dd>
          <dt>CE:</dt><dd>Congestion Experienced</dd>
          <dt>CItE:</dt><dd>Critical Ingress-to-Egress</dd>
          <dt>ECN:</dt><dd>Explicit Congestion Notification</t>
	<t>ECT - ECN Capable Transport</t>
	<t>L4S - Low Notification</dd>
          <dt>ECT:</dt><dd>ECN-Capable Transport</dd>
          <dt>L4S:</dt><dd>Low Latency, Low Loss, and Scalable throughput</t>
	<t>NCHbH - Non-Critical Hop-by-Hop</t>
	<t>NCCE - Non-Critical throughput</dd>
          <dt>NCHbH:</dt><dd>Non-Critical Hop-by-Hop</dd>
          <dt>NCCE:</dt><dd>Non-Critical Congestion Experienced</t>
	<t>Not-ECT - Not Experienced</dd>
          <dt>Not-ECT:</dt><dd>Not ECN-Capable Transport</t>
	<t>PCN - Pre-Congestion Notification</t>
	</list>
	</t> Transport</dd>
          <dt>PCN:</dt><dd>Pre-Congestion Notification</dd>
        </dl>
      </section>
    </section>
    <section title="The ECN Specific anchor="sect-2" numbered="true" toc="default">
      <name>The ECN-Specific Extended Header Flags" anchor="sect-2"><t> Flags</name>
      <t>
   The extension header fields for explicit congestion notification
   (ECN) ECN in TRILL are defined as a two-bit 2-bit TRILL-ECN field and a one-bit
   Critical Congestion Experienced (CCE) CCE field in the 32-bit TRILL
   Header Extension Flags Word
   header extension flags word <xref target="RFC7780"/>.</t> target="RFC7780" format="default"/>.</t>
      <t>
   These fields are shown in Figure 2 <xref target="fig-2"/> as "ECN" and "CCE". The
   TRILL-ECN field consists of bits 12 and 13, which are in the range reserved
   for
   non-critical hop-by-hop (NCHbH) NCHbH bits. The CCE field consists of bit 26,
   which is in the range reserved for Critical Ingress-to-Egress (CItE) CItE bits. The CRItE CItE bit is the critical
   Ingress-to-Egress summary bit and will be one if if, and only if 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 header after the Extension Flags Word. extension
   flags word.  The other bits and fields shown in
   Figure 2 <xref target="fig-2"/> are
   not relevant to ECN.  See <xref target="RFC7780"/>, target="RFC7780" format="default"/>, <xref
   target="RFC7179"/>,
   target="RFC7179" format="default"/>, and <xref target="IANAthFlags"/> target="IANAthFlags"
   format="default"/> for the meaning of these other bits and fields.</t>
      <figure title="The anchor="fig-2">
        <name>The TRILL-ECN and CCE TRILL Header Extension Flags Word Fields"
		anchor="fig-2">

<artwork><![CDATA[ Fields</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 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|     |   |     |       |         | |   |     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>
   Table 1
   <xref target="codepoints"/> 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 header, as defined in [RFC3168]. <xref
   target="RFC3168"/>. However, codepoint 0b11 is called Non-Critical Congestion Experienced (NCCE) NCEE to distinguish
   it from Congestion Experienced CE in IP.</t>

<!-- [rfced] Please review the figure below. It is a table in the original draft -->

<figure title="TRILL-ECN

<table anchor="codepoints">
  <name>TRILL-ECN Field Codepoints" anchor="fig-3">

<artwork><![CDATA[
       Binary  Name     Meaning
       ------  -------  -----------------------------------
         00     Not-ECT Not Codepoints</name>
  <thead>
    <tr>
      <th>Binary</th>
      <th>Name</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="center">00</td>
      <td>Not-ECT</td>
      <td>Not ECN-Capable Transport
         01     ECT(1)  ECN-Capable </td>
    </tr>
    <tr>
      <td align="center">01</td>
      <td>ECT(1)</td>
      <td>ECN-Capable Transport (1)
         10     ECT(0)  ECN-Capable (1)</td>
    </tr>
    <tr>
      <td align="center">10</td>
      <td>ECT(0)</td>
      <td>ECN-Capable Transport (0)
         11     NCCE    Non-Critical (0)</td>
    </tr>
    <tr>
      <td align="center">11</td>
      <td>NCCE</td>
      <td>Non-Critical Congestion Experienced
]]></artwork>
	</figure> Experienced</td>
    </tr>

  </tbody>
</table>

    </section>
    <section title="ECN Support" anchor="sect-3"><t> anchor="sect-3" numbered="true" toc="default">
      <name>ECN Support</name>
      <t>
   This section specifies interworking between TRILL and the original
   standardized form of ECN in IP <xref target="RFC3168"/>.</t> target="RFC3168" format="default"/>.</t>
      <t>
   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 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.  The egress
   behavior occurs where a TRILL Data packet is decapsulated and output
   as a native frame through an RBridge port.</t>
      <t>

<!-- [rfced] What sections were intended by "Sections 5.1-5.4 of
[ECNencapGuide]"? We note that Sections 5.1 through 5.4 do not exist
in draft-ietf-tsvwg-ecn-encap-guidelines (RFC-to-be 9599 - please see
https://www.rfc-editor.org/authors/rfc9599.html).

Did you intend Sections 4.1 through 4.4 of that document, or otherwise?

Original:
An RBridge that supports ECN MUST behave as described in the relevant
subsections below, which correspond to the recommended provisions in
   <xref target="sect-3"/>
Section 3 and Sections 5.1-5.4 of [ECNencapGuide].
-->

   An RBridge that supports ECN <bcp14>MUST</bcp14> behave as described in the relevant
   subsections below, which correspond to the recommended provisions in
   <xref target="sect-3" format="default"/> of this document and Sections <xref
   target="RFC9599" sectionFormat="bare"
   section="5.1"/> through <xref target="RFC9599"
   sectionFormat="bare" section="5.4"/> of <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines"/>.
   target="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.</t>
      <section title="Ingress anchor="sect-3.1" numbered="true" toc="default">
        <name>Ingress ECN Support" anchor="sect-3.1"><t> Support</name>
        <t>
   The behavior at an ingress RBridge is as follows:</t>

	<t><list style="symbols"><t>When
        <ul spacing="normal">
          <li>
            <t>When encapsulating an IP frame, the ingress RBridge MUST:<list style="symbols"><?rfc subcompact="yes"?>
	<t>set <bcp14>MUST</bcp14>:</t>
            <ul spacing="normal">
              <li>set the F flag in the main TRILL header <xref target="RFC7780"/>;</t>

	<t>create target="RFC7780" format="default"/>;</li>
              <li>create a Flags Word flags word as part of the TRILL Header;</t>

	<t>copy header;</li>
              <li>copy the two ECN bits from the IP header into the TRILL-ECN
         field (Flags Word (flags word bits 12 and 13)</t>

	<t>ensure 13); and</li>
              <li>ensure the CCE flag is set to zero (Flags Word (flags word bit 26).</t>

	<?rfc subcompact="no"?>
	</list>
	</t>

	<t>When 26).</li>
            </ul>
          </li>
<!--[rfced] In this sentence, does "it" refer to the ingress RBridge?
We note that this would be similar to the preceding item, which
includes "ingress RBridge" even though the lead-in text makes it clear.

Additionally, did you intend to refer to Section 4.3
(Encapsulation Guidelines) of [RFC9599] because there is
no Section 5.3 in that document?

Original:
   The behavior at an ingress RBridge is as follows:

[...]
   o  When encapsulating a frame for a non-IP protocol, where that
      protocol has a means of indicating ECN that is understood by the
      ingress RBridge, it MUST follow the guidelines in Section 5.3 of
      <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines"/>
      [ECNencapGuide] to add a Flags Word to the TRILL Header.

Perhaps:
   The behavior at an ingress RBridge is as follows:

[...]
   *  When encapsulating a frame for a non-IP protocol (where the
      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.
-->
          <li>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, it <bcp14>MUST</bcp14> follow the guidelines in
          <xref target="RFC9599" sectionFormat="of" section="5.3"/> to add a
          flags word to the TRILL header. For a non-IP protocol with a similar an ECN
          field similar to IP, this would be achieved by copying into the
          TRILL-ECN field from the encapsulated native frame.</t>

	</list>
	</t> frame.</li>
        </ul>
      </section>
      <section title="Transit anchor="sect-3.2" numbered="true" toc="default">
        <name>Transit ECN Support" anchor="sect-3.2"><t> Support</name>
        <t>
   The transit behavior, shown below, is required at all RBridges where
   TRILL Data packets are queued, usually at the output port.</t>

	<t><list style="symbols"><t>An
        <ul spacing="normal">
          <li>An RBridge that supports ECN MUST <bcp14>MUST</bcp14> implement some form of active
      queue management (AQM) AQM according to the guidelines of <xref target="RFC7567"/>. target="RFC7567" format="default"/>.
      The RBridge detects congestion either by monitoring its own queue
      depth or by participating in a link-specific protocol.</t>

	<t>If protocol.</li>
          <li>If the TRILL Header Flags Word header flags word is present, whenever the AQM
      algorithm decides to indicate congestion on a TRILL Data packet packet, it
      MUST
      <bcp14>MUST</bcp14> set the CCE flag (Flags Word (flags word bit 26).</t> 26).</li>
          <li>
            <t>If the TRILL header Flags Word flags word is not present, to indicate
      congestion the RBridge will
            either drop the packet or it MAY <bcp14>MAY</bcp14> do all of the
            following instead:<list style="symbols"><t>set instead to indicate congestion:</t>
            <ul spacing="normal">
              <li>set the F flag in the main TRILL header;</t>

	<t>add header;</li>
              <li>add a Flags Word flags word to the TRILL Header;</t>

	<t>set header;</li>
              <li>set the TRILL-ECN field to Not-ECT (00);</t>

	<t>and set (00); and</li>
              <li>set the CCE flag and the Ingress-to-Egress critical summary bit (CRIbE).</t>

	</list>
	</t>

	</list>
	</t> (CRIbE).</li>
            </ul>
          </li>
        </ul>
        <t>
   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. ECN
   capable. The egress/decapsulation behavior (described next) ensures that a CCE indication is
   converted to a drop if the transport is not ECN-capable.</t> ECN capable.</t>
      </section>
      <section title="Egress anchor="sect-3.3" numbered="true" toc="default">
        <name>Egress ECN Support" anchor="sect-3.3"><section title="Non-ECN Support</name>
        <section anchor="sect-3.3.1" numbered="true" toc="default">
          <name>Non-ECN Egress RBridges" anchor="sect-3.3.1"><t> RBridges</name>
          <t>
   If the egress RBridge does not support ECN, that RBridge will ignore
   bits 12 and 13 of any Flags Word flags word that is present, 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 Critical
   Ingress-to-Egress CIte flag when it has no specific logic to understand
   it.
Drop is the intended behavior for such a packet, as required by
   Section 5.4 of
   <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines"/>.</t> target="RFC9599"
   sectionFormat="of" section="4.4"/>.</t>
        </section>
        <section title="ECN anchor="sect-3.3.2" numbered="true" toc="default">
          <name>ECN Egress RBridges" anchor="sect-3.3.2"><t> RBridges</name>
          <t>
   If an RBridge supports ECN, for the two cases of an IP and a non-IP
   inner packet, the egress behavior is as follows:

      <list style="hanging" hangIndent="3">
      <t hangText="Decapsulating

          </t>
          <dl newline="false" spacing="normal" indent="3">
            <dt>Decapsulating an inner IP packet:"> The packet:</dt>
            <dd><t>The RBridge sets the
      ECN field of the outgoing native IP packet using Table 3. <xref
      target="egress-ecn"/>. It MUST <bcp14>MUST</bcp14> 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. header. If no TRILL Header Extension Flags Word header extension flags word is present, the
      3-bit ECN codepoint is assumed to be all zero bits.</t>
            <t>The name of the TRILL 3-bit ECN codepoint is defined using the
      combination of the TRILL-ECN and CCE fields in Table 2. <xref target="mapping"/>.  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 header extension flags word. Otherwise, it has the same name
      as the 2-bit TRILL-ECN codepoint.</t>

      <t>In
            <t>
            In the case where the TRILL 3-bit ECN codepoint indicates congestion
      experienced (CE) CE but
            the encapsulated native IP frame indicates a not
      ECN-capable transport (Not-ECT), Not-ECT, it can be
            seen that the RBridge MUST <bcp14>MUST</bcp14> drop the packet.  Such
            packet dropping is necessary because a transport above the IP
            layer that is not ECN-capable ECN capable will have no ECN logic, so it will
            only understand dropped packets as an indication of congestion.</t>

	</list>

        <list style="hanging" hangIndent="3">
	<t hangText="Decapsulating
            congestion.</t></dd>
          </dl>
          <dl newline="false" spacing="normal" indent="3">
            <dt>Decapsulating a non-IP protocol frame:"> frame:</dt>
<!-- [rfced] Should Section 5.4 of [RFC9599] be updated to
Section 4.4 (Decapsulation Guidelines), as 5.4 does not exist?

Original:
If the frame has a means of indicating ECN that is understood by the RBridge,
it MUST follow the guidelines in Section 5.4 of [ECNencapGuide] when setting
the ECN information in the decapsulated native frame.

Perhaps:
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.
-->
            <dd>If the frame has
	a means of indicating ECN that is understood by the RBridge, it <bcp14>MUST</bcp14>
	follow the guidelines in <xref
	target="I-D.ietf-tsvwg-ecn-encap-guidelines"/>
	target="RFC9599" sectionFormat="of" section="5.4"/> when
	setting the ECN
	information in the decapsulated native frame.  For a non-IP protocol
	with a similar an ECN field similar to IP, this would be achieved by combining
	the information in the TRILL Header Flags Word header flags word with the encapsulated
	non-IP native frame, as specified in <xref target="egress-ecn"/>.</dd>
          </dl>
<!--[rfced] In Table 3.</t>

	</list>
	</t>

	<texttable anchor="tab-2" title="Mapping 2, regarding alignment of TRILL-ECN and CCE Fields the first column (TRILL-ECN),
we have used right alignment to get the right-hand values to line up.
Is the TRILL 3-bit ECN Codepoint Name" style="full">
	<ttcol> TRILL-ECN </ttcol>
	<ttcol> CCE </ttcol>
	<ttcol> Arriving TRILL 3-bit ECN codepoint name</ttcol>
	<c>Not-ECT 00</c>
	<c>0</c>
	<c>Not-ECT</c>
	<c>ECT(1)  01</c>
	<c>0</c>
	<c>ECT(1)</c>
	<c>ECT(0)  10</c>
	<c>0</c>
	<c>ECT(0)</c>
	<c>NCCE    11</c>
	<c>0</c>
	<c>CE</c>
	<c>Not-ECT 00</c>
	<c>1</c>
	<c>CE</c>
	<c>ECT(1)  01</c>
	<c>1</c>
	<c>CE</c>
	<c>ECT(0)  10</c>
	<c>1</c>
	<c>CE</c>
	<c>NCCE    11</c>
	<c>1</c>
	<c>CE</c>
	</texttable>

<!-- [rfced] Please review current appearance of the figure below. It is a table in first column acceptable, or do you want
the RPC to pursue another option to more closely match the original draft -->

<figure title="Egress ECN Behavior" anchor="fig-4">
<artwork><![CDATA[
     +---------+----------------------------------------------+ I-D?

Original:
       | Inner TRILL-ECN  |  Arriving TRILL 3-bit ECN Codepoint Name

       | Not-ECT 00 | Native  +---------+------------+------------+----------+
       | Header ECT(1)  01 | Not-ECT
       | ECT(0)  10 | ECT(1)
       |     CE NCCE    11 |
     +---------+---------+------------+------------+----------+
       | Not-ECT 00 | Not-ECT
       | Not-ECT(*) ECT(1)  01 | Not-ECT(*)
       |  <drop> ECT(0)  10 |
       |  ECT(0) NCCE    11 |

Current (with horizontal lines removed):
      +============+
      | TRILL-ECN  |
      +============+
      | Not-ECT 00 |
      |  ECT(1) 01 |  ECT(0)
      |  ECT(0) 10 |
      |    NCCE 11 |
      | Not-ECT 00 |
      |  ECT(1) 01 |
      |  ECT(0) 10 |
      |    NCCE 11 |

Alternatively, you could decide to restructure the table. Example below
(where "-" has been replaced by "=" for the sake of putting this into
the XML as a comment).

      +============+=====+=========================================+
      | TRILL-ECN  | CCE | Arriving TRILL 3-Bit ECN Codepoint Name |
      +============+=====+=========================================+
      | Not-ECT    | 0   | Not-ECT                                 |
      +            +=====+=========================================+
      |            | 1   | CE                                      |
      +============+=====+=========================================+
      | ECT(1)     | 0   | ECT(1)                                  |  ECT(1)(*)
      +            +=====+=========================================+
      |  ECT(1)            | 1   | CE                                      |
      +============+=====+=========================================+
      |    CE ECT(0)     | 0   | ECT(0)                                  |
      +            +=====+=========================================+
      |            | 1   | CE                                      |
      +============+=====+=========================================+
      | NCCE       | 0   | CE                                      |      CE(*)
      +            +=====+=========================================+
      |            | 1   | CE                                      |
     +---------+---------+------------+------------+----------+
]]></artwork>
	</figure>
      +============+=====+=========================================+
-->

          <table anchor="mapping" align="center">
            <name>OPT A: Mapping of TRILL-ECN and CCE Fields to the TRILL 3-Bit ECN Codepoint Name</name>
            <thead>
              <tr>
                <th align="left">TRILL-ECN</th>
                <th align="left">CCE</th>
                <th align="left">Arriving TRILL 3-Bit ECN Codepoint Name</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="right">Not-ECT 00</td>
                <td align="left">0</td>
                <td align="left">Not-ECT</td>
              </tr>
              <tr>
                <td align="right">ECT(1) 01</td>
                <td align="left">0</td>
                <td align="left">ECT(1)</td>
              </tr>
              <tr>
                <td align="right">ECT(0) 10</td>
                <td align="left">0</td>
                <td align="left">ECT(0)</td>
              </tr>
              <tr>
                <td align="right">NCCE 11</td>
                <td align="left">0</td>
                <td align="left">CE</td>
              </tr>
              <tr>
                <td align="right">Not-ECT 00</td>
                <td align="left">1</td>
                <td align="left">CE</td>
              </tr>
              <tr>
                <td align="right">ECT(1)  01</td>
                <td align="left">1</td>
                <td align="left">CE</td>
              </tr>
              <tr>
                <td align="right">ECT(0)  10</td>
                <td align="left">1</td>
                <td align="left">CE</td>
              </tr>
              <tr>
                <td align="right">NCCE    11</td>
                <td align="left">1</td>
                <td align="left">CE</td>
              </tr>
            </tbody>
          </table>

<table anchor="egress-ecn">
  <name>Egress ECN Behavior</name>
  <thead>
    <tr>
      <th rowspan="2" align="center">Inner Native Header</th>
      <th colspan="4" align="center">Arriving TRILL 3-bit ECN Codepoint Name</th>
    </tr>
    <tr>
      <th align="center">Not-ECT</th>
      <th align="center">ECT(0)</th>
      <th align="center">ECT(1)</th>
      <th align="center">CE</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="center">Not-ECT</td>
      <td align="center">Not-ECT</td>
      <td align="center">Not-ECT(*)</td>
      <td align="center">Not-ECT(*)</td>
      <td align="center">&lt;drop&gt;</td>
    </tr>
    <tr>
      <td align="center">ECT(0)</td>
      <td align="center">ECT(0)</td>
      <td align="center">ECT(0)</td>
      <td align="center">ECT(1)</td>
      <td align="center">CE</td>
    </tr>
    <tr>
      <td align="center">ECT(1)</td>
      <td align="center">ECT(1)</td>
      <td align="center">ECT(1)(*)</td>
      <td align="center">ECT(1)</td>
      <td align="center">CE</td>
    </tr>
    <tr>
      <td align="center">CE</td>
      <td align="center">CE</td>
      <td align="center">CE</td>
      <td align="center">CE(*)</td>
      <td align="center">CE</td>
    </tr>
  </tbody>
</table>

          <t>
   An asterisk in the above table <xref target="egress-ecn"/> indicates a combination that is
   currently unused in all variants of ECN marking (see <xref target="sect-4"/>) target="sect-4" format="default"/>) and
   therefore SHOULD <bcp14>SHOULD</bcp14> be logged.</t>
          <t>
   With one exception, the mappings in Table 3 <xref target="egress-ecn"/> are consistent with those for
   IP-in-IP tunnels <xref target="RFC6040"/>, target="RFC6040" format="default"/>, which ensures backward
   compatibility with all current and past variants of ECN marking (see <xref
   target="sect-4"/>). target="sect-4" format="default"/>). It also ensures forward compatibility with any future
   form of ECN marking that complies with the guidelines in <xref
   target="I-D.ietf-tsvwg-ecn-encap-guidelines"/>, target="RFC9599" format="default"/>, including cases where
   ECT(1) represents a second level of marking severity below CE.</t>
          <t>
   The one exception is that the drop condition in Table 3 <xref target="egress-ecn"/> need not be
   logged because, with TRILL, it is the result of a valid combination
   of events.</t>
        </section>
      </section>
    </section>
    <section title="TRILL anchor="sect-4" numbered="true" toc="default">
      <name>TRILL Support for ECN Variants" anchor="sect-4"><t> Variants</name>
      <t>
   This section is informative, not normative; it discusses interworking
   between TRILL and variants of the standardized form of ECN in IP
   <xref target="RFC3168"/>. target="RFC3168" format="default"/>. See also <xref target="RFC8311"/>.</t> target="RFC8311" format="default"/>.</t>
      <t>
   The ECN wire protocol for TRILL (<xref target="sect-2"/>) target="sect-2" format="default"/>)
   and the ingress (<xref target="sect-3.1"/>) target="sect-3.1" format="default"/>) and egress
   (<xref target="sect-3.3"/>) target="sect-3.3" format="default"/>) ECN behaviors have been
   designed to
   support the other known variants of ECN, ECN as detailed below. New
   variants of ECN will have to comply with the guidelines for defining
   alternative ECN semantics <xref target="RFC4774"/>. target="RFC4774" format="default"/>. It is expected that the TRILL
   ECN wire protocol is generic enough to support such potential future
   variants.</t>
      <section title="Pre-Congestion anchor="sect-4.1" numbered="true" toc="default">
        <name>Pre-Congestion Notification (PCN)" anchor="sect-4.1"><t> (PCN)</name>
        <t>
   The PCN wire protocol <xref target="RFC6660"/> target="RFC6660" format="default"/> is
   recognized by the use of a
   PCN-compatible Diffserv codepoint in the IP header and a non-zero nonzero IP-ECN
   field. For TRILL or any lower layer lower-layer protocol, equivalent traffic
   classification
   traffic-classification codepoints would have to be defined, but that is
   outside the
   scope of the current this document.</t>
        <t>
   The PCN wire protocol is similar to ECN, except it indicates
   congestion with two levels of severity. It uses:</t>

	<t><list style="symbols"><t>11
        <ul spacing="normal">
          <li>11 (CE) as the most severe, termed the Excess-traffic-marked Excess-Traffic-Marked (ETM)
     codepoint</t>

	<t>01
     codepoint</li>
          <li>01 ECT(1) as a lesser severity level, termed the Threshold-Marked
     (ThM) codepoint. (This 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 <xref target="sect-4"/>.)</t>

	</list>
	</t> target="sect-4" format="default"/>.</li>
        </ul>
        <t>
   To implement PCN on a transit RBridge would require a detailed
   specification. But in In brief:</t>

	<t><list style="symbols"><t>the
        <ul spacing="normal">
          <li>the TRILL Critical Congestion Experienced (CCE) CCE flag would be used
     for the Excess-Traffic-Marked (ETM) codepoint;</t>

	<t>ECT(1) codepoint;</li>
          <li>ECT(1) in the TRILL-ECN field would be used for the Threshold-Marked
     codepoint.</t>

	</list>
	</t>
     codepoint.</li>
        </ul>
        <t>
   Then
   Then, the ingress and egress behaviors defined in <xref target="sect-3"/> target="sect-3" format="default"/> would not
   need to be altered to ensure support for PCN as well as ECN.</t>
      </section>
      <section title="Low anchor="sect-4.2" numbered="true" toc="default">
        <name>Low Latency, Low Loss, and Scalable Throughput (L4S)" anchor="sect-4.2"><t> (L4S)</name>
        <t>
   L4S is currently on the IETF's experimental track. An outline of how
   a transit TRILL RBridge would support L4S <xref target="I-D.ietf-tsvwg-ecn-l4s-id"/> target="RFC9331" format="default"/> is given in
   Appendix A.</t>
   <xref target="sect-a"/>.</t>
      </section>
    </section>
    <section title="IANA Considerations" anchor="sect-5"><t> anchor="sect-5" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   IANA is requested to update has updated the TRILL "TRILL Extended Header Flags Flags" registry
   by replacing the lines for bits 9-13 and for bits 21-26 with the
   following:</t>

	<figure><artwork><![CDATA[
   Bits   Purpose                                       Reference
   -----  -------                                       ---------
    9-11  available

<table anchor="iana">
  <name>Updated "TRILL Extended Header Flags" Registry</name>
  <thead>
    <tr>
      <th>Bits</th>
      <th>Purpose</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>9-11</td>
      <td>available non-critical hop-by-hop flags
   12-13  TRILL-ECN flags</td>
      <td><xref target="RFC7179"/></td>
    </tr>
    <tr>
      <td>12-13</td>
      <td>TRILL-ECN (Explicit Congestion Notification)  [this doc]

   21-25  available Notification)</td>
      <td>RFC 9600</td>
    </tr>
    <tr>
      <td>21-25</td>
      <td>available critical ingress-to-egress flags
      26  Critical flags</td>
      <td><xref target="RFC7179"/></td>
    </tr>
    <tr>
      <td>26</td>
      <td>Critical Congestion Experienced (CCE)         [this doc]
]]></artwork>
	</figure> (CCE)</td>
      <td>RFC 9600</td>
    </tr>
  </tbody>
</table>
    </section>

    <section title="Security Considerations" anchor="sect-6"><t> anchor="sect-6" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   TRILL support of ECN is a straightforward combination of previously
   specified ECN and TRILL with no significant new security
   considerations.</t>
      <t>
   For ECN tunneling security considerations, see <xref target="RFC6040"/>.</t> target="RFC6040" format="default"/>.</t>
      <t>
   For general TRILL protocol security considerations, see <xref target="RFC6325"/>.</t>

	</section>

	<section title="Acknowledgements" anchor="sect-7"><t>
   The helpful comments of Loa Andersson and Adam Roach are hereby
   acknowledged.</t>

	<t>
   This document was prepared with basic NROFF. All macros used were
   defined in the source file.</t> target="RFC6325" format="default"/>.</t>
    </section>
  </middle>
  <back>
	<references title="Normative References">
	&RFC2119;
	&RFC3168;
	&RFC4774;
	&RFC6325;
	&RFC7179;
	&RFC7567;
	&RFC7780;
	&RFC8174;
	&RFC8311;
	&I-D.ietf-tsvwg-ecn-encap-guidelines;

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4774.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6325.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7179.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7567.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7780.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8311.xml"/>

<!-- [I-D.ietf-tsvwg-ecn-encap-guidelines] in REF as of 5/1/2024, companion doc RFC9599 -->

<reference anchor="RFC9599" target="https://www.rfc-editor.org/info/rfc9599">
<front>
<title>Guidelines for Adding Congestion Notification to Protocols that
Encapsulate IP</title>
<author initials='B.' surname='Briscoe' fullname='Bob Briscoe'>
  <organization>Independent</organization>
</author>
<author initials='J.' surname='Kaippallimalil' fullname='John Kaippallimalil'>
  <organization>Futurewei</organization>
</author>
<date month='June' year='2024'/>
</front>
<seriesInfo name="RFC" value="9599"/>
<seriesInfo name="DOI" value="10.17487/RFC9599"/>
</reference>

      </references>
	<references title="Informative References">
	&I-D.ietf-tsvwg-ecn-l4s-id;
      <references>
        <name>Informative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9331.xml"/>

        <reference anchor="IANAthFlags" target="http://www.iana.org/assignments/trill-parameters/trill-parameters.xhtml#extended-header-flags"><front> target="http://www.iana.org/assignments/trill-parameters/">
          <front>
            <title>TRILL Extended Header word flags</title> Flags</title>
            <author>
              <organization>IANA</organization>
            </author>

	<date/>
          </front>
        </reference>
	&RFC6040;
	&RFC6660;

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml"/>
      </references>
    </references>
    <section title="TRILL anchor="sect-a" numbered="true" toc="default">
      <name>TRILL Transit RBridge Behavior to Support L4S" anchor="sect-a"><t> L4S</name>
      <t>
   The specification of the Low Latency, Low Loss, and Scalable throughput (L4S) wire protocol for IP is given in <xref target="I-D.ietf-tsvwg-ecn-l4s-id"/>. target="RFC9331" format="default"/>. L4S is one example
   of the ways TRILL ECN handling may evolve <xref target="RFC8311"/>. target="RFC8311" format="default"/>. It is similar to
   the original ECN wire protocol for IP <xref target="RFC3168"/>, target="RFC3168" format="default"/>, except:</t>

	<t><list style="symbols"><t>An
      <ul spacing="normal">
        <li>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.</t>

	<t>The otherwise.</li>
        <li>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 <xref target="RFC3168"/>). target="RFC3168" format="default"/>). 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., -- e.g., when there
     is a drop probability of 0.0009 (0.09%) (0.09%), the L4S marking
     probability will be 0.03 (3%)).</t>

	</list>
	</t> (3%).</li>
      </ul>
      <t>
   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
   <xref target="sect-3.3"/> target="sect-3.3" format="default"/> for Classic ECN <xref target="RFC3168"/> target="RFC3168" format="default"/> will
   produce the desired outcome.</t>

	<figure><artwork><![CDATA[
<!-- [rfced] Please review the "type" attribute of each sourcecode element
in the XML file to ensure correctness. If the current list of preferred
values for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt)
does not contain an applicable type, then feel free to let us
know. Also, it is acceptable to leave the "type" attribute not
set.
-->

<sourcecode>
   /* 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
         }
   }
]]></artwork>
	</figure>
</sourcecode>
      <t>
<!--[rfced] May we replace "non-ECN-capable" with "not ECN-capable",
as is used in Section 1.1?  Or, should the abbreviations (as expanded
in Section 1.1) - ECT and Not-ECT - be used?

Original:
   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 a non-ECN-capable or ECN-
   capable transport.

Perhaps:
   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.

Or (using abbreviations):
   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 ECT or Not-ECT.
-->
   With the above transit behavior, an egress that supports ECN (<xref
   target="sect-3.3"/>) target="sect-3.3" format="default"/>) will drop packets or propagate their ECN markings
   depending on whether the arriving inner header is from a non-ECN-capable or
   ECN-capable transport.</t>
      <t>
   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:</t>

	<t><list style="symbols"><t>Egress
      <ul spacing="normal">
        <li>
          <t>Egress with ECN support:<list style="symbols"><t>L4S: propagates support:</t>
          <ul spacing="normal">
            <li>
              <t>L4S: Propagates both the Critical and Non-Critical CE marks
        (CCE &amp; and NCCE) as a CE mark.<vspace blankLines="1"/> mark.</t>
              <t>
	Likelihood: p^2 p<sup>2</sup> + p - p^2 p<sup>2</sup> = p
              </t>
            </li>
            <li>
<!-- [rfced] FYI, we have changed "inner" to "inner header" here for
clarity. Please let us know if this is not accurate.

Original:
   +  Classic: Propagates CCE marks as CE or drop, depending on inner.

Current:
   -  Classic: Propagates CCE marks as CE or drop, depending on
      the inner header.
-->
              <t>Classic: Propagates CCE marks as CE or drop, depending on
        inner.<vspace blankLines="1"/>
        the inner header.</t>
              <t>
	Likelihood: p^2
	</t>

	</list> p<sup>2</sup>
              </t>
            </li>
          </ul>
        </li>
        <li>
          <t>Egress without ECN support:<list style="symbols"><t>L4S: does support:</t>
          <ul spacing="normal">
            <li>
              <t>L4S: Does not propagate NCCE as a CE mark, but drops CCE marks.<vspace blankLines="1"/> marks.</t>
              <t>
	Likelihood: p^2 p<sup>2</sup>
              </t>
            </li>
            <li>
              <t>Classic: drops Drops CCE marks.<vspace blankLines="1"/> marks.</t>
              <t>
	Likelihood: p^2
	</t>

	</list>
	</t>

	</list> p<sup>2</sup>
              </t>
            </li>
          </ul>
        </li>
      </ul>
    </section>
    <section anchor="sect-7" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
   The helpful comments of <contact fullname="Loa Andersson"/> and <contact fullname="Adam Roach"/> are hereby
   acknowledged.</t>
<!--[rfced] In the Acknowledgements, may we remove this text?  Alternatively,
it could be replaced as follows.  (It does not seem accurate in its
current form, as xml2rfc was used to create the publication formats.)

Original:
  This document was prepared with basic NROFF. All macros used were
  defined in the source file.

Perhaps:
   This document was originally produced with basic NROFF. All macros used
   were defined in the source file.
-->
      <t>
   This document was originally produced with basic NROFF. All macros used were
   defined in the source file.</t>
    </section>
<!-- [rfced] We have updated the Authors' Addresses section to reflect the
most current information available in other published RFCs. Please let us
know if any additional revisions are needed.
-->

<!-- [rfced] FYI, we have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. For example, please consider whether the term "native" should be updated. -->
  </back>
</rfc>