<?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-03" 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="Lei Li" initials="L." surname="Li">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>156 Beiqing Road</street>
          <city>Beijing</city>
          <code>100095</code>
          <country>P.R. China</country>
        </postal>
        <email>lily.lilei@huawei.com</email>
      </address>
    </author>

    <author initials="H" surname="Chen" fullname="Huaimo Chen">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street></street>
          <city>Boston, MA</city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>Huaimo.chen@futurewei.com</email>
      </address>
    </author>

   <author initials="C" fullname="Christoph Loibl" 
            surname="Loibl">
      <organization>Next Layer Communications</organization>
      <address>
        <postal>
          <street>Mariahilfer Guertel 37/7</street>
          <city>Vienna</city>
          <region></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 initials="Y" fullname="Yanhe Fan" 
            surname="Fan">
      <organization>Casa Systems</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></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 initials="L" fullname="Lei Liu" 
            surname="Liu">
      <organization>Fujitsu</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>liulei.kddi@gmail.com</email>
      </address>
    </author>

    <author initials="X" fullname="Xufeng Liu" 
            surname="Liu">
      <organization>Volta Networks</organization>
      <address>
        <postal>
          <street> </street>
          <city>McLean</city>
          <region>VA</region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2023"/>

    <!---->

    <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.hares-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="I-D.ietf-6man-segment-routing-header"/>. 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 style="hanging" hangIndent="6">
       <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 style="hanging" hangIndent="6">
          <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
0x12        0f  30 10 40   01 2001 0db8 0003  4b 0100   bd 0300
                ^  ^   ^
                |  |   |
    Length of LOC FUN ARG]]></artwork>
          </figure>
        </t>

        <t> 
          <figure>
          <artwork><![CDATA[ 
Decoded:
         Value 
         0x12     length       18 octets (if len<240, 1 octet)
    TBD1(0x0f)    type         type TBD1(0x0f) - 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
         0xbd     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>
  </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.hares-idr-flowspec-v2'?>
    </references>
    <references title="Informative References">
      <?rfc include='reference.RFC.8986'?>
      <?rfc include='reference.I-D.ietf-idr-flowspec-l2vpn'?>
      <?rfc include='reference.I-D.ietf-6man-segment-routing-header'?>
    </references>
  </back>
</rfc>
