<?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-08"
     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>lizhenbin@huawei.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="Yanhe Fan" initials="Y" surname="Fan">
      <organization>Casa Systems</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

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

        <email>yfan@casa-systems.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="Lei Liu" initials="L" surname="Liu">
      <organization>Fujitsu</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

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

        <email>liulei.kddi@gmail.com</email>
      </address>
    </author>

    <author fullname="Xufeng Liu" initials="X" surname="Liu">
      <organization>Volta Networks</organization>

      <address>
        <postal>
          <street/>

          <city>McLean</city>

          <region>VA</region>

          <code/>

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

        <email>xufeng.liu.ietf@gmail.com</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="25" month="November" year="2025"/>

    <workgroup>IDR Working Group</workgroup>

    <!---->

    <abstract>
      <t>This document proposes extensions to BGP Flow Specification for SRv6
      for filtering packets with a SRv6 SID that matches a sequence of
      conditions.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD 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"/> describes in details about a new BGP NLRI to
      distribute a flow specification, which is an n-tuple comprising a
      sequence of matching criteria that can be applied to IP traffic. <xref
      target="RFC8956"/> extends <xref target="RFC8955"/> to make it also
      usable and applicable to IPv6 data packets. <xref
      target="I-D.ietf-idr-flowspec-l2vpn"/> extends the flow-spec rules for
      layer 2 Ethernet packets. <xref target="I-D.ietf-idr-flowspec-v2"/>
      specifies BGP Flow Specification Version 2.</t>

      <t>Segment Routing (SR) for unicast traffic has been proposed to cope
      with the usecases in traffic engineering, fast re-reroute, service
      chain, etc. SR architecture can be implemented over an IPv6 data plane
      using a new type of IPv6 extension header called Segment Routing Header
      (SRH) <xref target="RFC8754"/>. SRv6 Network Programming <xref
      target="RFC8986"/> defines the SRv6 network programming concept and its
      most basic functions. An SRv6 SID may have the form of
      LOC:FUNCT:ARG::.</t>

      <t>LOC: Each operator is free to use the locator length it chooses. Most
      often the LOC part of the SID is routable and leads to the node which
      instantiates that SID.</t>

      <t>FUNCT: The FUNCT part of the SID is an opaque identification of a
      local function bound to the SID. E.g., End.X, End.T, End.DX2, etc.</t>

      <t>ARG: A function may require additional arguments that would be placed
      immediately after the FUNCT.</t>

      <t>This document specifies one new BGP Flow Specification (FS) component
      type to support Segment Routing over IPv6 data plane (SRv6) filtering
      for BGP Flow Specification Version 2. The match field is destination
      address of IPv6 header, but it's a SRv6 SID from SRH rather than a
      traditional IPv6 address (refer to <xref target="matchSID"/>). To
      support these features, a Flowspec version that is IPv6 capable (i.e.,
      AFI = 2) MUST be used. These match capabilities of the features MAY be
      permitted to match when there is an accompanying SRH.</t>

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

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

          <t>BGP-FS: Border Gateway Protocol (BGP) Flow Specification (FS)</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>The Flow Specification NLRI-type consists of several optional
      components, each of which begins with a type field (1 octet) followed by
      a variable length parameter. 13 component types are defined in <xref
      target="RFC8955"/> and <xref target="RFC8956"/> for IPv4 and IPv6. This
      document defines one component type for SRv6.</t>

      <!--
    <section title="Type TBD1 - Whole SID"
             anchor="type-tbd1">

      <t>Encoding: &lt;type (1 octet), [op, value]+&gt;</t>

      <t>Contains a list of {operator, value} pairs that are used to match the
      SID/binding SID or a range of whole SID. </t>

      <t>The operator byte is encoded as:</t>

      <t><figure>
          <artwork><![CDATA[                       0   1   2   3   4   5   6   7
                     +===+===+===+===+===+===+===+===+
                     | e | a | 0 | 0 | 0 |lt |gt |eq |
                     +===+===+===+===+===+===+===+===+]]></artwork>
        </figure>Where
         the behavior of each operator bit has clear symmetry with that of 
         <xref target = "RFC8955"/>'s
         Numeric Operator field.</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>0 - MUST be set to 0 on NLRI encoding,
      and MUST be ignored during decoding.</t>

      <t>lt - less than comparison between data and value.</t>

      <t>gt - greater than comparison between data and value.</t>

      <t>eq - equality between data and value.</t>

      <t>The bits lt, gt, and eq can be combined to match the SID or a
      range of SID (e.g. less than SID1 and greater than SID2).</t>

      <t>The value field is encoded as:</t>

      <t><figure anchor="value-field" 
           title="Format of Value Field">
          <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  LOC Length   | FUNCT Length  |  ARG Length |    SID          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                        SID(continue)                          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure></t>

     <t>
      <list style="hanging" hangIndent="6">
       <t hangText="o LOC Length:">1-octet field indicating the length in bits of LOC in SID.</t>
       <t hangText="o FUNCT Length:">1-octet field indicating the length in bits of FUNCT in SID.</t>
       <t hangText="o ARG Length:">1-octet field indicating the length in bits of ARG in SID.</t>
       <t hangText="o SID:">the SID containing LOC, FUNCT and ARG, and rounding up to bytes.</t>
      </list></t>

      <t>The total of three lengths 
         (i.e., LOC length + FUNCT length + ARG length)
         MUST NOT be greater than 128. 
         If it is greater than 128, an error occurs and 
         Error Handling is applied according to
         <xref target = "RFC7606"/> and <xref target = "RFC4760"/>.</t>
    </section>
-->

      <section title="Type TBD1 - Some Parts of SID">
        <t><xref target="RFC8986"/> defines the format of SID is
        LOC:FUNCT:ARG::. In some scenarios, traffic packets can just match
        Locator, Function ID, Arguments or some combinations of these
        different fields. In order to match a part of SID, its prior parts
        need to be examined and matched first. For example, in order to match
        the Function ID (FUNCT), the Locator (LOC) needs to be examined and
        matched first. The new component type TBD1 defined below is for
        matching some parts of SID.</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):">This indicates the new component
            type (TBD1, which is to be assigned by IANA).</t>

            <t hangText="o LOC-Len (1 octet):">This indicates the length in
            bits of LOC in SID.</t>

            <t hangText="o FUNCT-Len (1 octet):">This indicates the length in
            bits of FUNCT in SID.</t>

            <t hangText="o ARG-Len (1 octet):">This indicates the length in
            bits of ARG in SID.</t>

            <t hangText="o [op, value]+:">This contains a list of {operator,
            value} pairs that are used to match some parts of SID.</t>
          </list></t>

        <t>The total of three lengths (i.e., LOC length + FUNCT length + ARG
        length) MUST NOT be greater than 128. If it is greater than 128, an
        error occurs and Error Handling is applied according to <xref
        target="RFC7606"/> and <xref target="RFC4760"/>.</t>

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

        <t><figure>
            <artwork align="center"><![CDATA[
   0   1   2   3   4   5   6   7
 +---+---+---+---+---+---+---+---+
 | e | a | field type|lt |gt |eq |
 +---+---+---+---+---+---+---+---+]]></artwork>
          </figure> where the behavior of each operator bit has clear symmetry
        with that of <xref target="RFC8955"/>'s Numeric Operator field.</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: <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></t>

        <t>For an unknown type, Error Handling is applied according to <xref
        target="RFC7606"/> and <xref target="RFC4760"/>.</t>

        <t>lt - less than comparison between data' and value'.</t>

        <t>gt - greater than comparison between data' and value'.</t>

        <t>eq - equality between data' and value'.</t>

        <t>The data' and value' used in lt, gt and eq are indicated by the
        field type in a operator and the value field following the
        operator.</t>

        <t>The value field depends on the field type and has the value of
        SID's some parts rounding up to bytes (refer to the table below).</t>

        <t><figure>
            <artwork align="center"><![CDATA[
 +-----------------------+------------------------------+
 | Field Type            | Value                        |
 +=======================+==============================+
 | SID's LOC             | value of LOC bits            |
 +-----------------------+------------------------------+
 | SID's FUNCT           | value of FUNCT bits          |
 +-----------------------+------------------------------+
 | SID's ARG             | value of ARG bits            |
 +-----------------------+------------------------------+
 | SID's LOC:FUNCT       | value of LOC:FUNCT bits      |
 +-----------------------+------------------------------+
 | SID's FUNCT:ARG       | value of FUNCT:ARG bits      |
 +-----------------------+------------------------------+
 | SID's LOC:FUNCT:ARG   | value of LOC:FUNCT:ARG bits  |
 +-----------------------+------------------------------+]]></artwork>
          </figure></t>
      </section>

      <section anchor="examples" title="Encoding Examples">
        <section anchor="example1" title="Example 1">
          <t>An example of a Flow Specification NLRI encoding for: all SRv6
          packets to LOC 2001:db8:3::/48 and FUNCT {range [0100, 0300]}.</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><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>No new security issues are introduced to the BGP protocol by this
      specification over the security considerations in <xref
      target="RFC8955"/> and <xref target="RFC8956"/>.</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 | Some Parts of SID | This Document  |
+-----------+------------+-------------------+----------------+
]]></artwork>
        </figure></t>
    </section>

    <!--
    <section anchor="Contributors" title="Contributors">
      <t>TBD</t>
    </section>
-->

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

    <section title="Contributors ">
      <t><figure>
          <artwork align="left"><![CDATA[
   Lei Li
   Huawei
   156 Beiqing Road
   Beijing
   100095
   P.R. China
   Email: lily.lilei@huawei.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>
