<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
     docName="draft-shen-idr-flowspec-traffic-compress-action-05"
     ipr="trust200902">
  <front>
    <title abbrev="Traffic Compression Action">BGP Flow-Spec Traffic Compress
    Action</title>

    <author fullname="Ming Shen" initials="M" surname="Shen">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Road</street>

          <city>Beijing</city>

          <code>100095</code>

          <region/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>shenming2@huawei.com</email>
      </address>
    </author>

    <author fullname="Wenyan Li" initials="W" surname="Li">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Road</street>

          <city>Beijing</city>

          <code>100095</code>

          <region/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>liwenyan@huawei.com</email>
      </address>
    </author>

    <author fullname="Lili Wang" initials="L" surname="Wang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Road</street>

          <city>Beijing</city>

          <code>100095</code>

          <region/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>lily.wong@huawei.com</email>
      </address>
    </author>

    <author fullname="Guoqiang Wang" initials="G" surname="Wang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Road</street>

          <city>Beijing</city>

          <code>100095</code>

          <region/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>wangguoqiang5@huawei.com</email>
      </address>
    </author>

    <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Road</street>

          <city>Beijing</city>

          <code>100095</code>

          <region/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhuangshunwan@huawei.com</email>
      </address>
    </author>

    <date day="13" month="October" year="2026"/>

    <area>Routing</area>
    
    <workgroup>IDR Working Group</workgroup>

    <abstract>
      <t>BGP Flow Specification Version 2 (FSv2) provides an extensible
      framework for disseminating traffic flow specification rules and
      associated actions. While traditional Flow-spec actions cover
      rate-limiting, redirecting, and marking, emerging applications require
      dynamic bandwidth optimization. This document specifies a new traffic
      filtering action to support selective, on-demand traffic compression
      across network domains using BGP Extended Communities aligned with the
      FSv2 architecture.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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
      <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
      they appear in all capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>BGP <xref target="RFC4271"/> Flow Specification <xref
      target="RFC8955"/> <xref target="RFC8956"/> and its evolution to Version
      2 (FSv2) specified in <xref target="I-D.ietf-idr-fsv2-ip-basic"/> allow
      for the dissemination of traffic flow specification rules and traffic
      filtering actions. Traditional Flow-spec actions define widely-used
      filtering behaviors such as discard, rate limit, and traffic
      marking.</t>

      <t>Data transmitted across enterprise networks, data centers, and
      external connections varies widely in nature (e.g., database payloads,
      bulk text, multimedia, and signaling). Certain traffic aggregates
      present significant redundancy and high compression ratios, whereas
      other data streams have little to no compression potential or require
      dedicated processing hardware.</t>

      <t>While BGP Flow-spec enables network-wide policy distribution, static
      configurations lack the agility required for dynamic data-center
      interconnect (DCI) traffic engineering. Therefore, this document
      introduces a new BGP Flow-spec action that enables network operators to
      dynamically apply traffic compression based on granular traffic filters,
      saving core transport bandwidth and improving overall network
      utilization.</t>

      <t/>
    </section>

    <section title="Traffic Compress Extended Community">
      <t>This document proposes a new BGP extended community called the "flow-
      spec traffic compress action". It operates as a Generic Transitive
      Extended Community type ("0x80"). The sub-type value [to be assigned by
      IANA] indicates that the global administrator and local administrator
      fields encode a flow-spec traffic compress action aligned with FSv2
      action guidelines.</t>

      <t>In this extended community, the 2-byte global administrator field
      encodes compression algorithms referred to as Compression Parameter
      Index (CPI) [RFC3173]. The 4-byte local administrator field carries
      compression parameters (CPV).</t>

      <t>The new BGP extended community is encoded as follows:</t>

      <t><figure>
          <artwork><![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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    0x80       |    Sub-Type   |             CPI               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             CPV                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure><list style="symbols">
          <t>Sub-Type: TBD.</t>

          <t>CPI (2 octets): The values 0-63 designate well-known compression
          algorithms. The values 64-255 are reserved for future use. The
          values 256-61439 are negotiated between the endpoints in the
          definition of an IPComp Association <xref target="RFC3173"/>.</t>

          <t>CPV (4 octets): Parameters associated with the selected CPI.
          Depending on the CPI, the CPV can be divided into distinct segments
          (e.g., algorithm tuning flags, window sizes, or application IDs).
          Unused bits MUST be set to zero by the originating BGP speaker and
          ignored upon receipt.<t>For instance, when utilizing the zstd
          compression algorithm, the CPV can be structured as: &lt;trainAppId
          (1 octet), CRC (2 octets), appId (1 octet)&gt;.</t></t>
        </list></t>

      <t/>
    </section>

    <section title="Operational and Processing Considerations">
      <t/>

      <section title="Role Assignment and Directionality">
        <t>Generally, the ingress node receiving the Flow-spec Traffic
        Compress Extended Community acts as the compression controller or
        enforcement point, directing matching packets through hardware or
        software compression pipelines before forwarding them across
        bandwidth-constrained WAN/DCI links.</t>
      </section>

      <section title="Hardware Offload and Capability Negotiation">
        <t>Because compression and decompression introduce processing
        overhead, transit nodes receiving this action MUST verify that they
        possess the hardware or software capabilities corresponding to the
        requested CPI. If a node lacks the requested compression capability,
        it MUST fall back to standard uncompressed forwarding or report a
        local policy exception, preventing packet dropping due to processing
        failures.</t>
      </section>
    </section>

    <section title="Error Handling">
      <t>If multiple traffic compression extended communities exist in a BGP
      route attribute, the value of the first traffic compression extended
      community MUST take precedence.</t>

      <t>The validation of the TLVs and extended community structures
      introduced in this document MUST be performed to verify formatting
      correctness. In case of any malformed attributes detected, error
      handling MUST comply with <xref target="RFC7606"/> and the error
      policies defined in <xref target="I-D.ietf-idr-fsv2-ip-basic"/>.</t>

      <t/>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>IANA is requested to create a new entry/registry under the "Extended
      Community" registries:</t>

      <t><figure align="left">
          <artwork><![CDATA[   SubType   Description
   -------   ---------------------------------------------
   TBD       Traffic Compress Extended Community
]]></artwork>
        </figure></t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Traffic compression introduces potential vector risks, such as CPU
      exhaustion (Denial-of-Service) attacks caused by malformed or highly
      inefficient payload structures designed to trigger worst-case
      compression cycles. Operators SHOULD implement rate-limiting or resource
      quotas on compression-enabled forwarding engines.</t>

      <t>Furthermore, standard BGP security mechanisms (such as RPKI and BGP
      session authentication) MUST be deployed to prevent unauthorized
      injection of compression action extended communities.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to acknowledge the review and inputs from
      Haibo Wang, Gang Yan, Linda Dunbar, Zhenbin Li, Rainbow Wu, Jie Dong and
      Ziqing Cao.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.8174"?>

      <?rfc include="reference.RFC.8955"?>

      <?rfc include="reference.RFC.8956"?>

      <?rfc include="reference.RFC.3173"?>

      <?rfc include="reference.RFC.7606"?>

      <?rfc include='reference.I-D.ietf-idr-fsv2-ip-basic'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.4271'?>
    </references>
  </back>
</rfc>
