<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-idr-flowspec-srv6-10"
     ipr="trust200902">
  <front>
    <title abbrev="BGP Flow Specification for SRv6 ">BGP Flow Specification
    for SRv6</title>

    <author fullname="Zhenbin Li" initials="Z." surname="Li">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Road</street>

          <city>Beijing, 100095</city>

          <country>P.R. China</country>
        </postal>

        <email>robinli314@163.com</email>
      </address>
    </author>

    <author fullname="Huaimo Chen" initials="H" surname="Chen">
      <organization>Futurewei</organization>

      <address>
        <postal>
          <street/>

          <city>Boston, MA</city>

          <region/>

          <code/>

          <country>USA</country>
        </postal>

        <email>hchen.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Christoph Loibl" initials="C" surname="Loibl">
      <organization>Next Layer Communications</organization>

      <address>
        <postal>
          <street>Mariahilfer Guertel 37/7</street>

          <city>Vienna</city>

          <region/>

          <code>1150</code>

          <country>AT</country>
        </postal>

        <email>cl@tix.at</email>
      </address>
    </author>

    <author fullname="Gyan S. Mishra" initials="G" surname="Mishra">
      <organization>Verizon Inc.</organization>

      <address>
        <postal>
          <street>13101 Columbia Pike</street>

          <city>Silver Spring</city>

          <code>MD 20904</code>

          <country>USA</country>
        </postal>

        <phone>301 502-1347</phone>

        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>

    <author fullname="Yongqing Zhu" initials="Y. " surname="Zhu">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>109, West Zhongshan Road, Tianhe District</street>

          <city>Guangzhou</city>

          <code>510000</code>

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

        <email>zhuyq8@chinatelecom.cn</email>
      </address>
    </author>

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

      <address>
        <postal>
          <street>156 Beiqing Road</street>

          <city>Beijing</city>

          <code>100095</code>

          <country>P.R. China</country>
        </postal>

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

    <date day="17" month="September" year="2026"/>

    <workgroup>IDR Working Group</workgroup>

    <!---->

    <abstract>
      <t>This document specifies extensions to BGP Flow Specification (BGP-FS)
      to enable filtering of IPv6 packets based on the structural components
      of an SRv6 Segment Identifier (SID) present in the IPv6 Destination
      Address (representing the active segment of an SRv6 path).</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><xref target="RFC8955"/> defines the BGP Flow Specification (BGP-FS)
      Network Layer Reachability Information (NLRI) to distribute traffic
      filtering rules, which consist of an n-tuple of matching criteria
      applied to IP packets. <xref target="RFC8956"/> extends this framework
      to IPv6 data packets. Additionally, <xref
      target="I-D.ietf-idr-flowspec-l2vpn"/> extends Flowspec rules for Layer
      2 Ethernet frames, and <xref target="I-D.ietf-idr-flowspec-v2"/>
      specifies BGP Flow Specification Version 2.</t>

      <t>Segment Routing over IPv6 (SRv6) <xref target="RFC8754"/> leverages
      the IPv6 data plane using a Segment Routing Header (SRH) to instantiate
      Segment Routing policy paths. The SRv6 Network Programming architecture
      <xref target="RFC8986"/> defines the structure of an SRv6 Segment
      Identifier (SID), typically formatted as LOC:FUNCT:ARG::, where:</t>

      <t><list style="symbols">
          <t>LOC (Locator): A routable prefix assigned to an SRv6 node that
          instantiates the SID. Operators may choose variable locator
          lengths.</t>

          <t>FUNCT (Function): An opaque identifier bound to a local function
          executed on the node (e.g., End, End.X, End.DT4).</t>

          <t>ARG (Argument): Optional arguments appended immediately following
          the FUNCT field for specialized local processing.</t>
        </list>Existing IPv6 BGP-FS components <xref target="RFC8956"/> allow
      matching against the entire 128-bit IPv6 Destination Address (DA).
      However, SRv6 SIDs embed structured sub-fields (Locator, Function, and
      Argument) within the IPv6 DA. Filtering traffic based solely on a full
      128-bit mask lacks the flexibility needed to apply policy rules to
      specific SRv6 functions or argument ranges across different
      locators.</t>

      <t>This document defines a new BGP Flow Specification component type to
      support sub-field matching for SRv6 SIDs. The matching field is
      evaluated against the IPv6 Destination Address (or active SID within an
      SRH when present, as shown in <xref target="matchSID"/>). To support
      this feature, a BGP-FS NLRI with AFI = 2 (IPv6) MUST be used.</t>

      <t><figure anchor="matchSID" title="Match Field">
          <artwork><![CDATA[
            +-----------------------------+
 IPv6 Header|     SA      |     DA        |<-- Match Field
            +--------------------^--------+
                                 |
            +--------------------|--------+
            |             +-------------+ |     +-------------------+
            |             | Segment[0]  +-------> Loc | Func | Arg  |
            |             +-------------+ |     +-------------------+
            |             | Segment[1]  | |
            |             +-------------+ |
            |             |    ...      | |
   SR Header|             +-------------+ |
  (RFC 8754)|             | Segment[n]  | |
            |             +-------------+ |
            |             +-------------+ |
            |             ~  Option TLV ~ |
            |             +-------------+ |
            +-----------------------------+]]></artwork>
        </figure></t>
    </section>

    <section title="Definitions and Acronyms">
      <t><list style="symbols">
          <t>BGP FS: BGP Flow Specification</t>

          <t>FS: Flow Specification</t>

          <t>SR: Segment Routing</t>

          <t>SRH: SR Header.</t>

          <t>SRv6: IPv6 Segment Routing, SRv6 is a method of forwarding IPv6
          packets on the network based on the concept of source routing.</t>

          <t>SID: Segment Identifier</t>

          <t>BSID: Binding SID</t>
        </list></t>
    </section>

    <section title="The Flow Specification Encoding for SRv6">
      <t>A Flow Specification NLRI consists of zero or more matching
      components. Components Type 1 through 13 are defined in <xref
      target="RFC8955"/> and <xref target="RFC8956"/>. This document defines a
      new component type for SRv6 SID sub-field filtering.</t>

      <!---->

      <section title="Component Type TBD1 - SRv6 SID Structure Match">
        <t>An SRv6 SID consists of Locator, Function, and Argument fields as
        defined in <xref target="RFC8986"/>. In operational scenarios,
        operators may need to filter traffic matching specific locators,
        functions, or arguments, or combinations thereof.</t>

        <t>The new component type TBD1 (SRv6 SID Structure Match) allows
        fine-grained matching on these individual fields or aggregated field
        combinations.</t>

        <t>Encoding: &lt;type, LOC-Len, FUNCT-Len, ARG-Len, [op,
        value]+&gt;</t>

        <t><list hangIndent="6" style="hanging">
            <t hangText="o type (1 octet):">Indicates the new component type
            (TBD1, to be assigned by IANA).</t>

            <t hangText="o LOC-Len (1 octet):">Length of the Locator field in
            bits.</t>

            <t hangText="o FUNCT-Len (1 octet):">Length of the Function field
            in bits.</t>

            <t hangText="o ARG-Len (1 octet):">Length of the Argument field in
            bits.</t>

            <t hangText="o [op, value]+:">A sequence of one or more {operator,
            value} pairs specifying the matching logic applied to the SID
            sub-fields.</t>
          </list>Validation Constraint:</t>

        <t>The sum of LOC-Len, FUNCT-Len, and ARG-Len MUST NOT exceed 128
        bits. If (LOC-Len + FUNCT-Len + ARG-Len) &gt; 128, the NLRI is
        considered malformed, and BGP Error Handling MUST be applied according
        to <xref target="RFC7606"/> and <xref target="RFC4760"/>.</t>

        <t>The Operator byte (op) is encoded as follows:</t>

        <t><figure>
            <artwork align="center"><![CDATA[
   0   1   2   3   4   5   6   7
 +---+---+---+---+---+---+---+---+
 | e | a | field type|lt |gt |eq |
 +---+---+---+---+---+---+---+---+]]></artwork>
          </figure>The operator semantics follow the Numeric Operator
        definition in <xref target="RFC8955"/>:</t>

        <t>e - end-of-list bit. Set in the last {op, value} pair in the
        sequence.</t>

        <t>a - AND bit. If unset, the previous term is logically ORed with the
        current one. If set, the operation is a logical AND. It should be
        unset in the first operator byte of a sequence. The AND operator has
        higher priority than OR for the purposes of evaluating logical
        expressions.</t>

        <t>field type: </t>

        <t><list hangIndent="6" style="hanging">
            <t hangText="  000:">SID's LOC</t>

            <t hangText="  001:">SID's FUNCT</t>

            <t hangText="  010:">SID's ARG</t>

            <t hangText="  011:">SID's LOC:FUNCT</t>

            <t hangText="  100:">SID's FUNCT:ARG</t>

            <t hangText="  101:">SID's LOC:FUNCT:ARG</t>
          </list>lt, gt, eq - Less-than, Greater-than, and Equal-to comparison
        operators, evaluated bitwise or numerically between the extracted SID
        sub-field and the provided value.</t>

        <t>The length of the Value field following the operator byte is
        determined by the selected field type, rounded up to the nearest byte
        boundary (i.e., ceil(bits / 8)).</t>

        <t><figure>
            <artwork align="center"><![CDATA[+----------------------+-------------------------------------------+
| Field Type           | Value Field Length & Contents             |
+======================+===========================================+
| SID's LOC            | ceil(LOC-Len / 8) octets                  |
+----------------------+-------------------------------------------+
| SID's FUNCT          | ceil(FUNCT-Len / 8) octets                |
+----------------------+-------------------------------------------+
| SID's ARG            | ceil(ARG-Len / 8) octets                  |
+----------------------+-------------------------------------------+
| SID's LOC:FUNCT      | ceil((LOC-Len + FUNCT-Len) / 8) octets    |
+----------------------+-------------------------------------------+
| SID's FUNCT:ARG      | ceil((FUNCT-Len + ARG-Len) / 8) octets    |
+----------------------+-------------------------------------------+
| SID's LOC:FUNCT:ARG  | ceil((LOC-Len+FUNCT-Len+ARG-Len)/8) octets|
+----------------------+-------------------------------------------+
]]></artwork>
          </figure></t>
      </section>

      <section anchor="examples" title="Encoding Examples">
        <section anchor="example1"
                 title="Example 1: Matching Locator and Function Range">
          <t>Consider a rule targeting all SRv6 traffic directed to Locator
          2001:db8:3::/48 with a Function ID within the range [0x0100,
          0x0300].</t>

          <t>Given:</t>

          <t><list style="symbols">
              <t>LOC-Len = 48 bits (6 octets) </t>

              <t>FUNCT-Len = 16 bits (2 octets) </t>

              <t>ARG-Len = 64 bits (8 octets)</t>
            </list>Hexadecimal Encoding Sequence:</t>

          <t><figure>
              <artwork><![CDATA[
       Some Parts of SID
             |
length       v             LOC==20010db80003  FUN>=100  FUN<=300
0x11       TBD1 30 10 40   01 2001 0db8 0003  4b 0100   8d 0300
                ^  ^   ^
                |  |   |
    Length of LOC FUN ARG]]></artwork>
            </figure></t>

          <t>Detailed Field Breakdown:<figure>
              <artwork><![CDATA[ 
Decoded:
         Value 
         0x11     length       17 octets (if len<240, 1 octet)
         TBD1     type         type TBD1 - Some Parts of SID
         0x30     LOC Length   = 48 (bits)
         0x10     FUNCT Length = 16 (bits)
         0x40     ARG Length   = 64 (bits)
         0x01     op           LOC  ==
         0x2001   value        LOC's value = 2001:db8:3
         0x0db8
         0x0003
         0x4b     op           "AND", FUNCT >=
         0x0100   value        FUNCT's value = 0100
         0x8d     op           end-of-list, "AND", FUNCT <=
         0x0300   value        FUNCT's value = 0300      
]]></artwork>
            </figure></t>
        </section>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document introduces no new security vulnerabilities beyond those
      already documented in <xref target="RFC8955"/> and <xref
      target="RFC8956"/>. Because Flowspec rules can result in packet dropping
      or rate-limiting, implementations MUST verify the authorization of BGP
      peers sending SRv6 Flowspec rules to prevent potential Denial-of-Service
      (DoS) attacks or traffic hijacking.</t>

      <t/>
    </section>

    <section title="IANA Considerations">
      <t>Under "Flow Spec Component Types" registry, IANA is requested to
      assign the following values:</t>

      <t><figure>
          <artwork align="center"><![CDATA[
+-------+------------+---------------------------+---------------+
| Value | IPv4 Name  | IPv6 Name                 | Reference     |
+-------+------------+---------------------------+---------------+
| TBD1  | Unassigned | SRv6 SID Structure Match  | This Document |
+-------+------------+---------------------------+---------------+
]]></artwork>
        </figure></t>
    </section>

    <!--
-->

    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>The authors would like to thank Joel Halpern, Jeffrey Haas, Ketan
      Talaulikar, Aijun Wang, Dhruv Dhody, Ming Shen and Rainsword Wang for
      their valuable suggestions and comments.</t>
    </section>

    <section title="Contributors ">
      <t><figure>
          <artwork align="left"><![CDATA[
   Lei Li
   Huawei
   P.R. China
   Email: lily.lilei@huawei.com

   Yanhe Fan
   Casa Systems
   United States of America
   Email: yfan@casa-systems.com
   
   Lei Liu
   Fujitsu
   United States of America
   Email: liulei.kddi@gmail.com

   Xufeng Liu
   Volta Networks
   United States of America
   Email: xufeng.liu.ietf@gmail.com

]]></artwork>
        </figure></t>
    </section>
  </middle>

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

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

      <?rfc include='reference.RFC.7153'?>

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

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

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

      <?rfc include='reference.RFC.4760'?>

      <?rfc include='reference.I-D.ietf-idr-flowspec-v2'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.8754'?>

      <?rfc include='reference.RFC.8986'?>

      <?rfc include='reference.I-D.ietf-idr-flowspec-l2vpn'?>
    </references>
  </back>
</rfc>
